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

[Skef Iterum]

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?

It's my suspicion that most existing COLR v1 support was implemented 
similar to your description. Basically, COLR was seen as more as vector 
graphics rather than traditional text shaping and was added as an 
extension of vector graphics (which was probably how SVG-in-ot was seen 
as well). That works fine but will generally result in stripping out 
CFF-style hints or TT instructions prior to any transformations, and 
rasterizing with an engine that wouldn't know or care about what to do 
with that information anyway.

On the glyf side of things, /on paper/ glyf can already do a lot of the 
things VARC does, so it shouldn't be a big deal to extend support in a 
TT-instruction-consuming glyf rasterizers to handle VARC cases. However, 
I've heard informally that people rarely if ever used glyf component 
transformations with, e.g., rotation because it wouldn't work with 
hinting. (And not necessarily, again from what I've heard, just in the 
sense that hinting would be selectively "turned off", but maybe that 
results might just be /wrong/.)

CFF(2) has historically not had transformations built-in, and while I'm 
writing up a guide to how the various PrivateDict and per-glyph 
parameters should be interpreted, there's still basic questions of 
implementation given the current "PostScript-style" rasterizers. Do we 
expect that implementations will rasterize atom-level components 
separately and composite them together? That would work in an overall 
monochrome/oversampling model but will lead to overlap artifacts in 
rasterizers that handle anti-aliasing directly. Or do we expect that 
implementations will want/need to build up a composite CharString first 
and rasterize that as a unit "glyph"? That's possible but will require 
not only translating the dimension-specific operators into a more 
transformation-friendly form -- analogous to the translation into 
vector-graphics-land that happens now -- but also slicing and combining 
the stems and hint/cntr masks.

However, maybe I'm wrong about all of this. CSS has transforms and maybe 
that path uses the "traditional" rasterizers, so at least in the 
browsers those stacks have already been modified as they need to be 
(setting aside tricky overlap-related questions). And of course 
PostScript had transformation matrix contexts from the beginning, so 
there must have always been a sensible way to get hints and 
transformations to cooperate, or at least not get in each other's way.

I just don't really know the current state of the shaping and 
rasterization stacks and therefore what sort of guidance the spec should 
provide. Or whether (as the current draft does implicitly) we can just 
say nothing about any of this and let the implementations sort it out 
for themselves.

Skef

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240124/ed9f97ac/attachment.html>