<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">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"><u></u>

  
    
  
  <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">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>