[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.


> 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