Some user using IPA symbols asked me about the following:
the need is to type
t U035C s
and get
U02A6 U035C
where U02A6 is the ts ligature.
Of course if one types t s U035C then the solution is trivial. But the need is to type with this order: t U035C s
since there is a lot of linguistic material already typed in this order. They were "trained" to type in this order since older fonts were placing U035C under t in such a way that was extending to the right, and s was falling at the right place. But those older fonts did not have or provide a ts ligature (U02A6).
Comments
In principle, the OpenType lookup flag "IgnoreMarks" should do what you want if the U035C glyph is classified as a mark.
but wanting the t+s letter sequence to be ligated. So the text is not being encoded as <02A6, 035C>: that’s just a possible glyph outcome:
It could also be something like
if someone really wants this they can manually kern the tie under the ligature, but I don't think a font should reasonably be expected to handle such nonstandard cases.
Having a t s -> t_s rule which skips marks is problematic since you only want this sort of ligation to occur in contexts where ts represents an affricate, and that's not something that OT features can determine.
This is the contextual implementation in the upcoming v2.20 release of STIX Two Text:
In the following graphic, the red version is as interpreted by Core Text and the blue version is what my GPOS code would specify (and what HarfBuzz does):
I managed to get the blue/correct output with Core Text by substituting my normal glyph for U+0361 (as specified by ‘cmap’) by a different but equal glyph, i.e. the following ‘calt’ feature code:
Now, Core Text no longer interferes, and I can freely move /breveinverteddoublecomb.copy using GPOS. Testing two fonts (without the above feature code, Keep.ttf; and with the feature code, Sub.ttf) yields:
So, with HarfBuzz (and Core Text when using the ‘sub’ trick) the mark gets moved down 240 units as specified by my ‘kern’ code. But without the ‘sub’ trick, Core Text moves the mark down by itself by 224 units and also adds 44 units to the advance width (!?)
I think older versions of Apple's Pages caused even more damage if double marks were moved by GPOS and back then, Core Text alone did nothing, I’m not sure anymore. The moral: Few fonts support character, shaper tries to help, shaper messes with the few fonts that support the character.