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:
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).
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.
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.