<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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?</p>
<p>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.</p>
<p>On the glyf side of things, <i>on paper</i> 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 <i>wrong</i>.)<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Skef<br>
</p>
<div class="moz-cite-prefix">On 1/24/24 08:06, Dominik Röttsches
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAN6muBsN5osdg0Wtv=_90Gj=tOwLJbWoFG_QDTSWu90puHyrEA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hi Skef,<br>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jan 24, 2024 at
11:34 AM Skef Iterum <<a href="mailto:skef@skef.org"
moz-do-not-send="true" class="moz-txt-link-freetext">skef@skef.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 1/24/24 01:05, Dominik Röttsches wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hi Skef,</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jan 24,
2024 at 10:54 AM Skef Iterum via mpeg-otspec <<a
href="mailto:mpeg-otspec@lists.aau.at"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">mpeg-otspec@lists.aau.at</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I
was looking through the COLR portions of the spec
and didn't find any <br>
guidance on applying transformations to CFF or
CFF2 glyph sources, what <br>
with those formats various horizontal- and
vertical- specific operators.<br>
</blockquote>
<div><br>
</div>
<div>What do you mean by: "what with those formats
various horizontal- and vertical- specific
operators."?</div>
<div> <br>
</div>
</div>
</div>
</blockquote>
<p>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. </p>
<p>(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.)</p>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p> </p>
<p>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.<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>Ok, let me know if you have any more questions.</div>
<div><br>
</div>
<div>Dominik</div>
<div> </div>
<div><br>
</div>
<div> </div>
</div>
</div>
</blockquote>
</body>
</html>