graphicore
commented
6 years ago It seems to me the browsers should be fixed if they are doing something wrong. The fact that Arabic script seems to work well though leaves me with the impression that either Adobe/Glyphs do something wrong or that we use the features the wrong way.
Also note that the features function is tied to their Unicode joining types:
This applies to characters that have one of the following Unicode Joining_Type property values:
- Right_Joining, if the characters are from a left-to-right script.
- Left_Joining, if the characters are from a right-to-left script.
- Dual_Joining.
from (https://docs.microsoft.com/en-us/typography/opentype/spec/features_fj#a-nameinit-idinitatag-init)
And finally, if we hack something, we leave the impression that the fonts work this way in the browsers, which they don't. A hack like this is IMHO rather harmful because it masks how the thing really works.
kontur
I just wanted to document this issue with those positional features and how users expect them to behave.
It's my understanding those features are, per spec, applied to all characters, and as such rendered in the font tester widget when set to be applied (i.e. this is how browsers seem to handle it). However, many apps (Adobe CC, Glyphs) seem to actually do additional layout level substitutions to only apply those features at word boundaries. This creates a dissonance between what users see when activating the feature in the tester (all characters of a word are swapped) to what users might expect from other text apps).
One hack could be using the ::first-letter pseudo selector, but there does not seem to be a last letter equivalent. Other options would be nested spans that dis/en-able the feature only at word boundaries, but this seems to go to quite intricate levels and add unwieldy complexity to the font tester widget.