<div dir="ltr"><div dir="ltr">On Sat, Sep 23, 2023 at 2:01 PM Skef Iterum <<a href="mailto:skef@skef.org" target="_blank">skef@skef.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>I would say this cross-context pattern for "undefined behavior"
is reasonably common across distributed media systems:</p>
<ol>
<li>End-stage processors are "forgiving" -- they try their best to
do something that makes sense</li>
<li>Intermediate sanity-checkers and sanitizers are "unforgiving"
-- they flag undefined behavior for rejection</li>
</ol>
<p>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.)<br>
</p>
<p>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.<br>
</p>
<p>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.</p>
<p>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 <i>could</i> 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. <br>
</p>
<p></p></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div> - We should be able to continue to process one point at a time (keeping a state of course) and calling moveto/lineto/curveto/qcurveto.</div><div><br></div><div> - Reversing the contour points and ends should produce the same shape with opposite winding direction.</div><div><br></div><div>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.</div><div><br></div><div>b</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>Skef<br>
</p>
<div>On 9/23/23 12:02, Laurence Penney
wrote:<br>
</div>
<blockquote type="cite">
<pre>[Moving discussion to its own thread]
In the following document recently posted by Vlad:
<a href="https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03_otf-improvements.pdf" target="_blank">https://github.com/harfbuzz/boring-expansion-spec/blob/main/iso_docs/WG03_otf-improvements.pdf</a>
We have the following:
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>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
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div></div>