Open NorbertLindenberg opened 5 years ago
Thanks Norbert. @dscorbett would you have time to look into this by any chance?
A font can currently distinguish between a dotted circle present in the input and a dotted circle inserted by the shaper. If the shaper’s cluster model is wrong, the font can override it. This is only possible because HarfBuzz inserts dotted circles in the middle of GSUB. If it happened between GSUB and GPOS, the font’s options would be quite limited. If it happened before GSUB, the font couldn’t override it at all. It would be a shame to have to remove this capability.
Does DirectWrite apply the language system’s required feature before inserting dotted circles?
A font can currently distinguish between a dotted circle present in the input and a dotted circle inserted by the shaper. If the shaper’s cluster model is wrong, the font can override it. This is only possible because HarfBuzz inserts dotted circles in the middle of GSUB. If it happened between GSUB and GPOS, the font’s options would be quite limited. If it happened before GSUB, the font couldn’t override it at all. It would be a shame to have to remove this capability.
But that would only work on HarfBuzz...
I'm fine adding other ways to detect that. I know before, with MS and others, we talked about possibly applying a specific feature only to inserted dotted-circles. That's not totally straightforward though.
Let's find a way. If it happens to be after the HARF
feature, that would be enough flexibility to keep it like it is currently, no?
I mean.. other than the changing of behavior which would make targeting harder.
If dotted circles are inserted after 'HARF', that would be good enough for HarfBuzz. There’d still be the problem that fonts that need to detect inserted dotted circles would only work in HarfBuzz; it would just be more explicit. I’m instead hoping for a solution compatible across all implementations. That could be a new feature, or inserting after the required feature (I’m not sure how exactly how required features are applied so this might not work), or inserting after reordering.
This is a follow-up to the discussion on MicrosoftDocs/typography-issues#281.
The initial proposal there was to change the USE description parts on handling invalid combining marks to “clarify the 25CC is inserted by the engine after GSUB and before GPOS”. However, as discussed there, there are good reasons to do it earlier so as to make the dotted circle available to GSUB substitutions, and testing shows that CoreText and DirectWrite insert it before any GSUB application.
HarfBuzz currently inserts it before reordering, i.e., after OpenType feature application I. I suggest moving the insertion to before GSUB application.
A test case is available at https://lindenbergsoftware.com/opentype/DottedCircle.html
The test cases includes the following test-specific feature code: