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

[Skef Iterum]

I would say this cross-context pattern for "undefined behavior" is 
reasonably common across distributed media systems:

 1. End-stage processors are "forgiving" -- they try their best to do
    something that makes sense
 2. Intermediate sanity-checkers and sanitizers are "unforgiving" --
    they flag undefined behavior for rejection

Most font files go through some context where 2 can be enforced before 
they reach an end-user. OS vendors check the fonts they include. Adobe's 
font marketplace has checks. I believe Google checks the fonts that go 
up on its servers. (Browsers also check fonts before using them, but 
that may be too late for checking subtleties like what we're discussing.)

I would say this a good convention overall. Forcing all behavior to be 
defined can cut off options for defining that behavior in the context of 
future features.

The trickier question is what to do about changes in undefined behavior 
-- either making something undefined that wasn't before, or somehow 
changing the status of behavior that wasn't defined in the spec but that 
all implementers handled in a certain way. I doubt we're doing the 
former but we have to be careful about the latter because fonts that are 
already out there and working will start to break.

I'll also note here that I argued in my initial response doc that there 
is less motivation for interpolated on-curve cubic points than there is 
for quadratics. I suspect you'll mainly see them in circles and other 
symmetric curves (like some "o"s and "O"s), and they will save space, 
but the arguments for them are much weaker than in the quadratic case. 
(I doubt you'll seem them creep up into the UI of design tools like you 
sometimes do for quadratic interpolated points (e.g. in FontForge).) So 
we should consider whether they're worth the confusion they will add. 
There are lots of features one /could/ add that would save two bytes 
here and four bytes there, and it seems like this is being proposed 
mostly because of the precedent with quadratics.

Skef

On 9/23/23 12:02, Laurence Penney wrote:
> [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
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20230923/03b3ec87/attachment.html>