It looks like you're new here. If you want to get involved, click one of these buttons!
This is very unobvious for software developers who use existing text layout libraries to solve.
Their code needs to itemize the text into runs which have the same font, size, script, language system and direction. Then, they query a text engine using a series of Unicodes, the script+languagesystem+direction and receive back a series of glyph IDs and their positions.
Optionally, the software developer can specify the user-selectable features to be enabled or disabled, but not all layout engines have a mechanism to specify those features for only specific characters.
So in many cases, a change in the set of user-selected features constitutes a run break, i.e. a change not only of the font but also a text color or a set of features is treated the same as change of the font.
This is an aspect that has never been overly-well defined and described by the spec (in fact, the entire process of text layout hasn't).
Even if a layout engine has an API that allows specifying user-selected features on a sub-run level (e.g. using a list-like syntax such as LibreOffice and hb-view do it), it’s still not entirely obvious how those should behave. For example, if I have a word “astra”, and enable a contextual feature only on the 2nd and 3rd character (“st”) and that contextual feature includes lookups that analyze preceding and following context, should the entire word (and beyond) be used for the context matching even though the actual substitutions only apply to the glyphs representing the “st” string?
Or what should happen if I have the word “AVANT” and specify "kern", i.e. that kerning should only be “applied to the 2nd character” (i.e. “V”)? Kerning on which side?
IMO, one conceptual weakness that the current OpenType Layout model has is that the substitutions and positioning steps are typically mushed together in one step, although in fact, they are very very different in their nature.
For GSUB processing, you generally need run itemization, because each script-specific shaping engine does its special thing behind the scenes, automatically applying certain simple GSUB features at certain locations that would otherwise need to be defined as complicated contextual features. For that, the notion of script, languagesystem and directionality is useful.
But once all the characters have been converted to glyph IDs, and all the special GSUB pro creating has been done, we arrive at a simple series of glyphIDs laid out horizontally or vertically (not even in any “direction”, really).
At this point we enter the GPOS processing where, in reality, script, languagesystem and directionality shouldn’t really matter at all. We have some boxes and we just need to shift them around, depending on what they are and what are their surroundings.
The current GPOS model isn't really good for it, it has tons of shortcomings. It disallows positioning across scripts, it makes 2D positioning tedious, so it ends up using different methods for different kinds of positioning: horizontal, verticsl, cursive, math etc. And even defining these relationships is tedious.
At this year's TYPO Labs, the panel discussion on liberating digital type design from the metal rectangle spent some time on this:
I think we should think of this more and propose much better solutions. The GSUB stuff, especially with USE, is probably pretty decent. But we probably should start thinking about an "UPOS" (Universal Positioning) concept that would redo the way the typographic pieces are positioned in the canvas, in a much more flexible way.
This wouldn't necessarily mean a complete change of the paradigm — existing Unicode processing and script-specific, contextual and user-selectable GSUB processing would probably be kept. But once that is done, and the layout engine arrives at collections of typographic pieces to be arranged, instead of using the short-sighted GPOS, a more flexible solution could be used.
This could take into account things that happen across text lines, across different fonts, between the same font but at different sizes, across different instsnces of a variable font etc.
Maybe it would have a way to “re-run” some substitutions (e.g. try different ones from a GSUB Type 3 lookup) to arrive at a result that produces least clashes or best merges.
Either way — I don't think any short-term fix will be much good. The positioning aspect of text layout needs to be revamped comprehensively.