<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 11:22 PM Skef Iterum via mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at">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"><u></u>

  
    
  
  <div>
    <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></div></blockquote><div>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. </div><div><br></div><div>Dominik</div><div><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>
    <div>On 1/24/24 08:06, Dominik Röttsches
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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" target="_blank">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">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>
  </div>

_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div></div>