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

Mon Oct 2 23:33:23 CEST 2023

 I'd just like to raise two points: 
- while the rendering system cannot be specified to cope with arbitrary amount or type of font brokenness, the problem with disallowing implied on-curve cubic points, or mandating that off-curve cubic points must be in pairs, is that off-curve points (and implied on-curve points) are very frequently used and beneficial in quadratics. You shouldn't take away capability that is not only allowed, but encouraged.
- suggestions about multiple passes - either as a QA process overall, or as part of the rendering process, sounds a lot like passing the bucket to me. For the former, it definitely sounds like 'let somebody else worry about it and / or fix the font for me' . As for the latter - I think it might be some significant resistance / re-engineering for some of the existing "production" rendering systems. Most of them are designed with doing things quickly, and in case of problems, try to do something not too crazy and move on. Doing multiple passes to figure out what's the font designers' actual intention isn't on the table.
Dropping all cubic bits in case of inconsistency is not a bad idea - for an entirely off-curve set of points, you get double the numbers of points and get probably a rendered contour close to each of those. (That's basically the current quadratics usage).

    On Monday, 2 October 2023 at 21:28:13 BST, Behdad Esfahbod <behdad at behdad.org> wrote:  

 On Sat, Sep 23, 2023 at 2:01 PM Skef Iterum <skef at skef.org> wrote:

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

   - End-stage processors are "forgiving" -- they try their best to do something that makes sense
   - 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. 

Thanks Skef and others. But even if we fully disallow implied on-curves for cubics, we still have the same problem of defining what happens when we encounter such segments.
As for the Jonathan's suggested in the other thread to either NOT render the misbehaving contour or fully describe how to render it, when designing the current model I had two goals in mind:
  - We should be able to continue to process one point at a time (keeping a state of course) and calling moveto/lineto/curveto/qcurveto.
  - Reversing the contour points and ends should produce the same shape with opposite winding direction.
Both of these will be violated by the suggested models. If we can find a way to fully specify the system while retaining these two properties, that's my preference. Otherwise, it looks like NOT rendering the contour at all can be achieved by an extra pass on the points before doing any drawing for the contour.
b 

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

 _______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://lists.aau.at/mailman/listinfo/mpeg-otspec

_______________________________________________
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/20231002/d40e0a05/attachment.html>