[MPEG-OTSPEC] Some research on TT instructions and cubics
Jonathan Kew
jfkthame at gmail.com
Fri Sep 22 14:45:43 CEST 2023
On 22/09/2023 13:01, Skef Iterum wrote:
> In the August meeting in Portland (and in some exchanges before that)
> some questions were raised about the feasibility of hinting cubic
> splines in glyf with the existing TT instruction set. One response was
> that this was not likely to be a problem as it is relatively rare in
> practice to move quadratic control points (as opposed to on-curve
> points). The idea being that the fact that a cubic has two control
> points rather than one shouldn't be an issue.
>
> Some folks on our team at Adobe decided to look into this a bit more,
> although not at great depth. From what we can tell, when the convention
> of only moving on-curve points works, that is typically because of a
> subsequent call to of the IUP instruction in one or both dimensions.
> That instruction is described this way
> <https://developer.apple.com/fonts/TrueType-Reference-Manual/RM05/Chap5.html#IUP>:
>
> Interpolates untouched points in the zone referenced by zp2 to
> preserve the original relationship of the untouched points to the
> other points in that zone.
>
> Unfortunately the documentation goes on to say:
>
> Considers the reference glyph outline contour by contour, moving any
> untouched points that fall sequentially between a pair of touched
> points.
>
> If neither cubic control point is hinted, neither will fall sequentially
> between a pair of touched points, and therefore cubic control points
> will typically not move in relation to how their adjacent on-curve
> points move.
I don't think this is correct. It's a very long time since I worked
directly with TrueType instructions, so I may be mis-remembering, but my
understanding is that IUP *would* be expected to adjust both control
points in such a case. The text says "...fall sequentially between..."
but does not require the untouched point to be *immediately* between the
touched points.
The meaning of "fall[s] sequentially between a pair of touched points",
as I understand it, is that if you travel around the contour from an
untouched point U either clockwise or counterclockwise, you will reach a
touched point T₁ or T₂. So U falls between T₁ and T₂ (regardless of how
many other untouched points, on- or off-curve, may intervene), and can
be adjusted accordingly.
This also deals with the degenerate case of a closed contour where only
one point has been touched. I think (though have not verified) that in
this case, IUP would affect *all* the other points on the contour. (T₁
and T₂ in this case are the same point.)
>
> It may be possible to update the instruction to also operate on pairs of
> untouched points sequentially between touched points, or to add a new
> instruction that does so, but only if there are not other cases arising
> from quadratics with the same pattern. More importantly, the heuristics
> for the quadratic case -- how the instruction moves the control point in
> relation to its adjacent quadratic on-curve points -- don't obviously
> apply to the cubic case. This is not just because there is "another
> point". How one cubic control point should move in a given case can
> greatly depend on the position of the other control point. In general
> the "behavior" of cubics is more complex than that of quadratics --
> they're stranger creatures.
The question of how cubic control points should behave may be trickier,
yes -- I haven't tried to look into this. I think the existing TrueType
algorithm would indeed handle them (as described above), but whether
this would be a useful result is unclear.
JK
>
> Anyway, if all this is accurate then hinting is likely to be a problem
> if cubics are added to glyf and TT hinting is still considered to be
> supported in glyphs that contain them, unless new instructions are also
> added.
>
> Skef
>
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
More information about the mpeg-otspec
mailing list