[MPEG-OTSPEC] Some research on TT instructions and cubics

[Jonathan Kew]

On 23/09/2023 17:05, Laurence Penney wrote:
> Is this a serious issue? Surely all binary formats have trillions of potential configurations of bits that do not conform to the spec. If your complaint is about the idea of undefined behaviour in a spec, then there are numerous instances of that would be up for discussion. If you want undefined behaviour to be replaced by insistence that a font should be rejected, then I think that goes against the ethos of many real-world font processors.

IMO: 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.

> 
> - Laurence
> 
>> On 23 Sep 2023, at 15:44, Jonathan Kew <jfkthame at gmail.com> wrote:
>>
>> On 23/09/2023 15:26, Laurence Penney wrote:
>>> Dear Hin-Tak,
>>> Please review the official proposal document (not the .md file I referred to previously), in particular page 3, where the language used may be more to your liking ("must" means no need to speak of "undefined"):
>>
>> But... page 3 there explicitly says: "If any of the conditions below are not met, the behavior is undefined."
>>
>> JK
>>
>>> https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03_otf-improvements.pdf
>>
>>
>