<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 25, 2024 at 12:36 PM 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>Let me be more specific: The VARC specification anticipates that
      TrueType<br>
      "instructions" will be valid and should be applied when
      compositing/rasterizing<br>
      VARC glyphs with glyf-based atoms, and that CFF2 PostScript-style
      hint<br>
      parameters will be valid and should be used when
      compositing/rasterizing <br>
      VARC glyphs with CFF2-based atoms, yielding hinted output when
      there is<br>
      hinted input (except in special cases such as the text itself
      being transformed<br>
      via CSS or some other means). Just extracting and transforming the
      path<br>
      information and then feeding it to a moveto/lineto/(q)curveto
      based rasterizer<br>
      won't support that, as such a rasterizer won't be aware of
      TrueType <br>
      instructions or PostScript style hinting, and anyway that data
      would be<br>
      stripped out of the path data.<br>
      <br>
      The question is: What should the specification say to make this
      expectation<br>
      clear and to clarify anything else the implementer should know, at
      least at<br>
      a high level?</p></div></blockquote><div>My understanding: Based on transforms, screen dpi etc. the application would create a hinting environment if possible and desired, i.e. determine if the text is going to appear as horizontal, pixel grid-affected text, extract the uniform scaling parts of the transform into a ppem font size, and run path extraction with an environment configured so that hinting can run, then proceed with the extracted "asbolute" path for rendering. </div><div>I don't have strong opinions on whether that should appear as guidance in the spec. </div><div><br></div><div>Dominik</div><div><br></div><div><br></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>Skef<br>
    </p>
    <div>On 1/25/24 02:09, 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
            11:22 PM 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">
            <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>
        </div>
      </div>
    </blockquote>
  </div>

</blockquote></div></div>