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

[Behdad Esfahbod]

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:
>
>    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.
>
>
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 listmpeg-otspec at lists.aau.athttps://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/af6c5ac0/attachment-0001.html>