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

[Dominik Röttsches]

Hi Skef,

On Wed, Jan 24, 2024 at 11:22 PM Skef Iterum via mpeg-otspec <
mpeg-otspec at lists.aau.at> wrote:

> I suppose the remaining question is: How do you anticipate you will
> support VARC when it becomes part of the specification and what guidance do
> you think the spec should provide when it comes to that sort of support?
>
I am not sure I can answer that. Similar to what I described for COLRv1, I
expect it to be supported below the level of retrieving a path into an
internal intermediate representation. So from the rasterisation
perspective, we rely on retrieving that path, and render from there.

Dominik

On 1/24/24 08:06, Dominik Röttsches wrote:
>
> 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
>
>
>
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240125/3e382fd4/attachment.html>