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

[Dominik Röttsches]

On Thu, Jan 25, 2024 at 12:36 PM Skef Iterum <skef at skef.org> wrote:

> Let me be more specific: The VARC specification anticipates that TrueType
> "instructions" will be valid and should be applied when
> compositing/rasterizing
> VARC glyphs with glyf-based atoms, and that CFF2 PostScript-style hint
> parameters will be valid and should be used when compositing/rasterizing
> VARC glyphs with CFF2-based atoms, yielding hinted output when there is
> hinted input (except in special cases such as the text itself being
> transformed
> via CSS or some other means). Just extracting and transforming the path
> information and then feeding it to a moveto/lineto/(q)curveto based
> rasterizer
> won't support that, as such a rasterizer won't be aware of TrueType
> instructions or PostScript style hinting, and anyway that data would be
> stripped out of the path data.
>
> The question is: What should the specification say to make this expectation
> clear and to clarify anything else the implementer should know, at least at
> a high level?
>
My understanding: Based on transforms, screen dpi etc. the application
would create a hinting environment if possible and desired, i.e. determine
if the text is going to appear as horizontal, pixel grid-affected text,
extract the uniform scaling parts of the transform into a ppem font size,
and run path extraction with an environment configured so that hinting can
run, then proceed with the extracted "asbolute" path for rendering.
I don't have strong opinions on whether that should appear as guidance in
the spec.

Dominik




> Skef
> On 1/25/24 02:09, Dominik Röttsches wrote:
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240125/b2baaa1b/attachment-0001.html>