[MPEG-OTSPEC] Documentation guidance on CFF(2) transformation
Dominik Röttsches
drott at google.com
Wed Jan 24 17:06:32 CET 2024
Hi Skef,
On Wed, Jan 24, 2024 at 11:34 AM Skef Iterum <skef at skef.org> wrote:
>
> 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.)
>
Yes, in our COLRv1 implementation(s), the path is retrieved at a ppem
particular size and then stored into an internal representation before any
transformations are applied. In that sense we treat `glyf` and CFF contours
the same way, they are retrieved from the respective glyph table, before
they are used and placed into the paint operations for COLRv1.
> 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.
>
Ok, let me know if you have any more questions.
Dominik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240124/4f321548/attachment.html>
More information about the mpeg-otspec
mailing list