Alternate Glyphs in Bloom for language in Nepal

I’m working with some people in Nepal who are using Annapurna SIL. When they (and I) use TypeTuner to get the Jha variant they want, it works for all language except Newar. Does the font “know” what language is being used and force the Newar alternate even if the font is set to the Nepal set? John Hatton provided me with CSS code to choose the stylistic set:

[lang=“new”] {
font-feature-settings: “ss01” 1;
-moz-font-feature-settings: “ss01” 1;

Does this code look right? I’d appreciate any help that you could give.

For Newar you want to use Stylistic set 2 which is “ss02”. You should have:
(note the space in the lang value “new ” for OpenType code)

[lang=“new ”] {
font-feature-settings: “ss02” 1;
-moz-font-feature-settings: “ss02” 1;

If that doesn’t work, you can try the graphite value for the Newar jha
variant: “jhav” and should look like:

[lang=“new”] {
font-feature-settings: “jhav” 2;
-moz-font-feature-settings: “jhav” 2;

To answer your question "Does it “know” what language is used…?, it
should but likely didn’t recognize it because the space was missing in "new

Thanks, John. What ended up working for me was to use “jhav” rather than “ss02” and no space after the language code. Doing it that way Bloom displayed the correct variants in edit mode (but not when creating the PDF).

It is possible to set both settings so that whichever rendering system is used will use the feature. So, you might try setting:

font-feature-settings: "ss02" 1, "jhav" 2;

Doing that may have the effect of allowing Bloom to use Graphite and the pdf rendering engine to use OpenType.

Testing would be needed, but considering experiences with Firefox, the following code may be the best:

:lang(new) {
font-feature-settings: “jhav” 2, ss02 1;

There are significant differences between [lang="new] attribute selector and :lang(new) language pseudo selector.

The attribute only applies to elements that have a matching lang attribute, so if you have a language element on a parent element, child elements will not be selected unless they also have the lang attribute on them.

Whereas the pseudo selector will apply to all elements that resolve to the language specified.

The order of graphite and OpenType features can be significant for some CSS rendering engines, and so far graphite then OpenType rules seems to be the best cross-platform approach. I am not sure if this hold for the PDF subsystem used in Bloom, but is the case across web browsers.


For more information about Andrew’s post, see What is the most appropriate way to associate CSS styles with text in a particular language in a multilingual HTML or XML document? on the website.

As for spaces in the CSS language tags, I’m pretty sure they should not be required nor should they work. The language tags used in HTML, XSL, and CSS are BCP 47 tags, and they do not have spaces.