[MPEG-OTSPEC] Documentation guidance on CFF(2) transformation

[Skef Iterum]

On 1/24/24 01:05, Dominik Röttsches wrote:
> Hi Skef,
>
> On Wed, Jan 24, 2024 at 10:54 AM Skef Iterum via mpeg-otspec 
> <mpeg-otspec at lists.aau.at> wrote:
>
>     I was looking through the COLR portions of the spec and didn't
>     find any
>     guidance on applying transformations to CFF or CFF2 glyph sources,
>     what
>     with those formats various horizontal- and vertical- specific
>     operators.
>
>
> What do you mean by: "what with those formats various horizontal- and 
> vertical- specific operators."?
>
E.g. the h* and v* operators such as hlineto, vlineto, hhcurveto that 
would need to be converted to different operators in the face of almost 
any rotation and some skews.

(An intermediate and "absolute" moveto/lineto/curveto representation (no 
relative values) would have the advantage that all points could have the 
transformation applied in the same way, which is why I brought it up.)

>     Was it assumed that implementations would first unpack into some
>     intermediate form, such as moveto/lineto/curveto sequences, and
>     thus no
>     further guidance was needed? (Obviously COLR does work with CFF and
>     CFF2, so one assumes, or hopes, that the implementations sorted
>     all this
>     out.) Or is it more that one can just expect that implementers will
>     figure this sort of thing out in general, and if so how does one
>     decide
>     what needs some guidance and what doesn't?
>
>
> Are you wondering about this from a hinting perspective? A COLRv1 or 
> COLRv0 implementing stack arrives at a situation where a glyph contour 
> needs to be clipped and filled. The glyph sizing is controlled by an 
> application font size, for example coming from CSS. And also, a local 
> transform can exist, from a CSS affine transform, or otherwise. Then, 
> font internal transforms can occur in COLRv1. I'd say the most 
> reasonable thing is then to see if the text is still horizontal and 
> only uniformly scaled, extract the actual font size after applying 
> transforms, render at that size with hinting if possible. If the text 
> is rotated or non-uniformly scaled, skewed etc. render without 
> hinting. That's at least what I see making sense for TrueType.
>
I'm currently trying to write something up from a CFF2 VARC hinting 
perspective but these questions are not about hinting -- I'm assuming 
COLR implementations don't attempt to hint. In particular I was 
wondering what to say about transformation and flex hints and realized 
that's not just a hinting question -- there's the more basic question of 
what to do if, e.g., an hflex instruction undergoes a transformation 
that no longer leaves the curve pair horizontal.

However, I didn't find a discussion of that sort of issue in the spec, 
implying that there's some level of this stuff implicitly "left to the 
reader". I'm trying to get a sense for what that level is so that what I 
say about hinting can conform to it.

Skef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240124/a1a5390d/attachment.html>