[MPEG-OTSPEC] comments wrt cubics in GLYF table

[Peter Constable]

I've discussed the Nov 20 draft proposal for adding cubic support in TrueType glyph descriptions with others at Microsoft and we have a few comments to bring up in tomorrow's AHG meeting. I'll summarize them in mail to give a (brief) chance to consider in advance. (I'll send separate mail with comments regarding cubic beziers.)

The proposal: boring-expansion-spec/iso_docs/WG03-beyond-64k-glyphs-2023-11-20.pdf at main * harfbuzz/boring-expansion-spec (github.com)<https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03-beyond-64k-glyphs-2023-11-20.pdf>


The conciseness of the change is nice. We're wondering if the documentation might be just a bit too concise, and whether some additional text should be added to make it clearer how data is interpreted. We also wonder if there should be some additional guidance for certain cases? E.g., what should apps do in case of non-conforming glyphs?

We discussed some interactions with instructions. The proposal states a few constraints on CUBIC off-curve points, but we interpret these as applying to data in a font's GLYF table. It's unclear what should happen if, during glyph processing, states are obtained in which the resulting scaled outline data in memory don't conform to those constraints.

In particular the FLIPPT<https://learn.microsoft.com/en-us/typography/opentype/spec/tt_instructions#flip-point>, FLIPRGON, FLIRGOFF instructions can change on-curve points to be off-curve, and vice versa. If a cubic off-curve point were flipped to be on-curve, then the expectation that the number of consecutive cubic off-curve points is always even would fail to hold. IIRC, it's more likely that a font would flip on-curve to become off-curve, but with the current proposal that could never become a cubic off-curve point. We haven't concluded what we think is the best resolution for this, but we think it's an open issue that needs to be resolved.

Related to this, the proposal constrains the CUBIC flag to be set only on off-curve points (i.e., in font data the ON_CURVE_POINT and CUBIC flags cannot both be set on a given point). The only benefit we can see from this constraint is reserving the option for bit 7 to be given a different definition when applied to on-curve points. We worry about that, particularly given that the FLIP* instructions can change on-curve to off-curve and vice versa, but there are no instructions defined for changing those flags. Unless it can be said that the flags are always ignored in all rasterizers once programs are run, then that can cause problems. We're inclined to remove the constraint wrt conjunction of CUBIC and ON_CURVE_POINT flags and simply say that the CUBIC flag has no effect on on-curve points.



Peter Constable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20231212/f0ac508f/attachment.html>