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

[Skef Iterum]

Those two goals seem like good ones, and definitely ones that must be 
met when processing a /conforming/ path. At least off the top of my head 
it seems difficult to meet both of them when rendering an arbitrary, 
potentially /non-conforming/ path.

For example, suppose your path has an odd number > 1 of cubic off-curve 
points between two on-curve points. To render that you're going to have 
to do something strange with the last point, perhaps just treating the 
last one as if it were a quadratic. But of course "last" would then be 
relative to ordering, so if you reverse the path you would wind up with 
the quadratic element at the other end of the sequence.

Are there tricks for this sort of case (currently described as 
"undefined") to meet those two goals?

Skef

On 10/2/23 13:27, Behdad Esfahbod wrote:
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20231002/2fc119b0/attachment.html>