[MPEG-OTSPEC] Rules for cubic bits in glyf flags include undefined behaviour for some configurations

[Laurence Penney]

[Moving discussion to its own thread]

In the following document recently posted by Vlad:
https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03_otf-improvements.pdf

We have the following:

> 3.1. Specification Change
> Add the following flag to the Simple Glyph Description section's Simple Glyph Flags:
> Mask Name Description
> 0x80 CUBIC Bit 7: Off-curve point belongs to a cubic-Bezier segment
> There are several restrictions on how the CUBIC flag can be used. If any of the
> conditions below are not met, the behavior is undefined.
> The number of consecutive cubic off-curve points within a contour (without wrap-
> around) must be even.
> All the off-curve points between two on-curve points (with wrap-around) must either
> have the CUBIC flag clear, or have the CUBIC flag set.
> The CUBIC flag must only be used on off-curve points. It is reserved and must be set
> to zero for on-curve points.


Discussion in another thread between Hin-Tak Young, Jonathan Kew and Laurence Penney has raised issues about the wisdom of the phrase "the behavior is undefined", rather than specifying a behaviour when these bits are in an unsupported configuration.

Hin-Tak notes that if one influential implementation accepts such non-compliant fonts and renders the glyph in a particular way, then other implementations will be tempted to follow it.

Jonathan: "I think the spec should *either* state that if the glyph data violates these "must" requirements, nothing will be rendered for that glyph; *or else* it should clearly specify how "anomalous" cases -- such as the CUBIC flag being set on a single off-curve point -- are to be processed, so that implementations produce a consistent result. One possible way forward, for example, would be to specify that for any contour where the CUBIC flag is used in violation of the rules given, all CUBIC flags must be ignored and the contour processed entirely according to legacy TrueType quadratic behavior. Leaving it explicitly undefined pretty much guarantees that implementations will come up with incompatible results, and fonts will get created that (inadvertently) depend on one implementation's behavior."

I (Laurence) noted that that "undefined behaviour" already appears several times in the OFF spec, and in practice real-world font processor are quite forgiving. If "undefined behaviour" is not permitted here it should probably be reviewed in those other places. Jonathan’s proposal to ignore all cubic bits in any non-conforming contour sounds workable, even though such error-handling behaviour is rare in OFF.

- Laurence