<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/24/24 01:05, Dominik Röttsches
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAN6muBt0w44yCL6TrZbxDpB+DFRq5rOOwXFgeT6BAiYD0+5xJA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
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.)<br>
</p>
<blockquote type="cite"
cite="mid:CAN6muBt0w44yCL6TrZbxDpB+DFRq5rOOwXFgeT6BAiYD0+5xJA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Was it assumed that implementations would first unpack into
some <br>
intermediate form, such as moveto/lineto/curveto sequences,
and thus no <br>
further guidance was needed? (Obviously COLR does work with
CFF and <br>
CFF2, so one assumes, or hopes, that the implementations
sorted all this <br>
out.) Or is it more that one can just expect that
implementers will <br>
figure this sort of thing out in general, and if so how does
one decide <br>
what needs some guidance and what doesn't?</blockquote>
<div><br>
</div>
<div>Are you wondering about this from a hinting perspective?
A COLRv1 or COLRv0 implementing stack arrives at a situation
where a glyph contour needs to be clipped and filled. The
glyph sizing is controlled by an application font size, for
example coming from CSS. And also, a local transform can
exist, from a CSS affine transform, or otherwise. Then, font
internal transforms can occur in COLRv1. I'd say the most
reasonable thing is then to see if the text is still
horizontal and only uniformly scaled, extract the actual
font size after applying transforms, render at that size
with hinting if possible. If the text is rotated or
non-uniformly scaled, skewed etc. render without hinting.
That's at least what I see making sense for TrueType. </div>
<br>
</div>
</div>
</blockquote>
<p>I'm currently trying to write something up from a CFF2 VARC
hinting perspective but these questions are not about hinting --
I'm assuming COLR implementations don't attempt to hint. In
particular I was wondering what to say about transformation and
flex hints and realized that's not just a hinting question --
there's the more basic question of what to do if, e.g., an hflex
instruction undergoes a transformation that no longer leaves the
curve pair horizontal. </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>
<p>Skef<br>
</p>
</body>
</html>