Typing alternate glyphs in Bloom; could it be set up in KeyMan?

I’m wondering whether this issue has been addressed yet; I can’t find any posts in the forums.

In Paratext, InDesign, LibreOffice one can specify to use the Graphite alternate glyphs for a style or a project font (PT). For other programs we have been encouraged to use TypeTuner to create custom fonts.

I’m trying to figure out how to propagate a custom font with books placed in Bloom Library or a country-wide book repository, or even between literacy teachers in neighboring languages.

For example, the education curriculum teaches printing of “small-t straight tail”, but Andika’s default is “curved tail”. Our easy reading books should follow the education dept’s standard, so an Andika_Straight derived font was created for the SIL Literacy Dept. But the point of Bloom is to make it “easy” to propagate books freely. How do we make sure that the straight-tail-t gets propagated with ALL appropriate Bloom books, singly or in BloomPacks, especially in a larger entity or country?

I really like the Paratext method of assigning font features for each project via an easy-to-understand dialog. LibreOffice’s method works too, but I end up opening a Paratext Language Properties window as an aid in composing a LO font statement such as this:
Andika:Engs=2&litr=0&apos=1&t_tl=1

I would like to see some sort of per-Collection (Bloom), or per-Language (KeyMan) solution for this issue. In Bloom could it be an Admin Task to set up fonts with font feature specs?

1 Like

Sorry it has taken so long to reply.

Currently, Bloom does not have such a feature.

@darcy, is this something Keyman could help with? i.e. can you set up font features to be used every time you use a particular keyboard in a particular language?

@kblewett,

Can you look in the Bloom documentation under “Font Features”? It tells how to do it. Let us know if that’s not what you’re thinking about.

Yes, this is what I’m thinking about. However, as a regional consultant I want to help users apply certain font features consistently to more than one collection in a language, or even throughout a region or country; i.e., the government Education Department might set a standard style of characters for teaching children to write. From what I can see this looks pretty hard to do in Bloom.

In Paratext the features is set “per language”, and this is propagated by Send/Receive to any project that uses the language.

In LibreOffice it can be set in a paragraph style definition, which can be propagated for users in “templates”, including the LO “default” template per computer.

In Bloom it would be very helpful if one could set a global glyph assignment (in an advanced setting somewhere) per language (for any collection in a language), or for a region, or for graded reading books for a “level”, … A gui setting would be very useful, I think.

Returning to this topic of Font Features…
I see from the Bloom documentation how to add a statement about custom font features to either customCollectionStyles.css or customBookStyles.css. The example statement is per language. I have two questions:

  1. I need to add more than one feature spec to my statement. I assume this is possible, separated by semicolons and with a trailing semicolon.

  2. My source collection contains books to be translated into multiple languages for a region. All of the region’s languages need the same feature specs, and I will not necessarily be starting each new local collection out with customized style.css files. So I need to include all the proposed language ids in my customCollectionStyles.css file. Can I enter multiple language ids in the same field, or does customCollectionStyles.css need separate statements for each language?

  3. If I can add multiple elements to the lang and settings fields, is there an upper limit to the number?

For example, is this statement valid?

[lang="kyx" "hla" "tpz" "sol" "roo" "buo"] 
{
  font-feature-settings: "Engs" 2; "apos"=1; "t_tl" 1;
  -moz-font-feature-settings: "Engs" 2; "apos"=1; "t_tl" 1;
} 

Thank you for any help.

It is really a high hurdle to expect most Bloom users, even “advisor” types who are setting up collections for other users, to be able to enter these complex statements into .css files and ensure that they get propagated correctly. A UI selection screen would be extremely helpful, or barring that a web page where features could be selected and compiled into a correct .css rule.

A further question I have is: Font Features are font-dependent. If I specify features for a collection based on Andika, and someone else changes the font, what happens? Can Bloom simply ignore the features that are missing in a specified font? Does my css statement get deleted if it does not match the current font? Or does Bloom choke if a font does not contain the specified alternate features?

Hi Kim,
that would be
[lang="kyx"], [lang="hla"], [lang="tpz"], (etc.)

is there an upper limit to the number

Conceivably (that would probably count as a bug in the web browser), but I doubt you’ll hit it.

Bloom does not look at these statements at all. CSS rules are read by the web browser that is displaying the book, be that the one built into Bloom, or Bloom Reader, or Reading App Builder, or whatever is being used to look at a website. Just like setting a font size.

OK, I get that. Thanks for clarifying this and the “lang” statements, John.

I think my question applies to whatever web browser or browser embedded into an app is being used to view the book: What happens when a CSS rule is not valid for a font that is specified? Is there a clash or is the rule simply ignored unless there is a matched environment or something?

Yeah, no crash is possible from CSS rules.

I understand that no crash is possible if you mess up the CSS. But it seems that mis-formed CSS will cause the whole thing to not work. :confused:

For example, I tried [lang="eng", "tpi"] instead of [lang="eng"], [lang="tpi"] and nothing worked.

Then I tried this (missing one double-quote):

font-feature-settings: "dig0 1, "dig1" 1, "dig4" 1, "dg69" 1, "dig7" 1, "i_tl" 1, "jser" 1, "litJ" 1, "l_tl" 1, "q_tl" 1, "Qalt" 1, "t_tl" 1, "y_tl" 1;

instead of

font-feature-settings: "dig0" 1, "dig1" 1, "dig4" 1, "dg69" 1, "dig7" 1, "i_tl" 1, "jser" 1, "litJ" 1, "l_tl" 1, "q_tl" 1, "Qalt" 1, "t_tl" 1, "y_tl" 1;

And that failed too. So it’s just hard, especially if you don’t know what you’re doing. I learned as I went, with lots of mistakes

This is a super cool feature! But I agree that having a visual way to generate the CSS code would be super helpful.

Oh, the code I ended up using in the customCollectionStyles.css is this:

[lang="eng"], [lang="tpi"]

{
  font-feature-settings: "dig0" 1, "dig1" 1, "dig4" 1, "dg69" 1, "dig7" 1, "i_tl" 1, "jser" 1, "litJ" 1, "l_tl" 1, "q_tl" 1, "Qalt" 1, "t_tl" 1, "y_tl" 1;
  -moz-font-feature-settings: "dig0" 1, "dig1" 1, "dig4" 1, "dg69" 1, "dig7" 1, "i_tl" 1, "jser" 1, "litJ" 1, "l_tl" 1, "q_tl" 1, "Qalt" 1, "t_tl" 1, "y_tl" 1;
}

This changes the default glyphs in Andika New Basic to be the highlighted characters below (which are preferred for literacy Papua New Guinea):

@JohnHatton Thank you for all your help with this!

Would it be possible to update the Help article for Font Features as well? Here are some comments/suggestions:

There were some helpful single-glyph examples, but it would be helpful to give an example of how to change multiple glyphs.

Could there be an example for multiple languages (or is there an option to work on all languages, so we wouldn’t have to add each individual language for a region?).

I think the link to the font features documentation is old? http://scripts.sil.org/cms/scripts/page.php?item_id=Andika_New_Basic#bef1c519 took me to the home page for Andika, where I was unable to find documentation regarding how to edit the CSS file.

What I ended up stumbling upon was this: https://software.sil.org/wp-content/uploads/sites/19/2015/12/AndikaNewBasic-features5.5.pdf. In the Help, this PDF was referenced as being on my computer, but I didn’t realize it was what I needed. A more clear description of that file and why it’s important would be helpful too.

Thanks again! This IS a really cool feature that I didn’t know existed until today.

James

Thanks, @James_Post.
We’ll take a look at these helpful suggestions and try to improve things.

Thank you so much, Bloom team, for enabling these font features! Your hard work is not taken for granted. We now have our literacy alternates appearing in our regional book collections.

Just in time for a new thing to appear! Sigh…

The new version 6 of the SIL fonts has lost Graphite support in favor of OpenType features (which is understandable). The current solution detailed here still works for Andika New Basic, which has not been updated to v 6 yet, but the full versions of Charis, Andika, Doulos, Gentium Plus require something different to access font features.

I don’t know how this affects non-Roman scripts or alphabets that use more characters than Andika New Basic provides. For us in PNG it’s not a big deal until Andika New Basic either upgrades to v 6 or is abandoned because Andika 6 now includes italic and bold glyphs.

So this is more than an FYI post: Y’all have to prioritize improvements. But I would hate to have font features/alternate glyphs break in Bloom due to font upgrades, now that we have it.

but the full versions of Charis, Andika, Doulos, Gentium Plus require something different to access font features.

Kim thanks for the heads up. I haven’t been able to find information about this, e.g. it is not mentioned in the Andika 6 release notes. Can you point me to the information you have?

On Andika New Basic, right the font folks have told me that was the end of the line, it will not be updated now that Andika has bold and italic.

In Andika New Basic font features were implemented in both Graphite and OpenType. The release note that @JohnHatton mentioned state Graphite has been removed. So you need to use OpenType to specify the font features. In the PDF listing font features for Andika New Basic 5.5 you can see (for example) the features Capital Q alternate. This has a Graphite feature ID of Qalt, and an OpenType feature ID of cv52. I suspect that using cv52 instead of Qalt in the CSS file will work.

Hi John, copying Glenn Pruitt and Mark Penny to ask if this has been addressed in Paratext and PTX Print yet.

I found it hard to find too. I finally found a general statement about the removal of Graphite and availability of OpenType here. Below it is the list of OpenType codes for the available Andika features. Same for Charis and Doulos, I guess.

Thanks!

Oops!
https://software.sil.org/andika/features/

and instructions for using the features here
https://software.sil.org/fonts/features/

Thanks Kim. So I’m still not clear what it is you see that we need to do. Is there an explanation or example in our documentation that is now out of date?

Just to clarify all of this for existing Bloom docs that use v5 or earlier versions of SIL Latin or Cyrillic fonts:

If your Bloom doc turned on special font features by specifying OpenType features - that typically have feature IDs that look like ‘scmp’, ‘cv52’, and ‘ss01’ - then your current doc should work fine with the v6 fonts with no changes. There is only one OT feature that will no longer work (Show Invisibles) as we removed that in v6.

If you specified your features using Graphite features - that typically look like ‘y_tl’, ‘Qalt’, or ‘dig1’ - none of them will work, as Graphite has been removed in v6. The removal of Graphite is noted at the top of the v6 release notes. To reactivate these you need to change the CSS to use the corresponding OpenType ID as found in in the font documentation or on the web site.

Hope that helps!