<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thanks, Peter.</p>
    <p>The Arabic example was added after discussion with the W3C I18n
      Core Working Group. In this case, the expectation is that the
      entire connected glyph sequence was drawn with one stroke, and
      thus opacity can show up unexpected joins that would be hidden
      with a fully opaque rendering.</p>
    <p>But your nice example clearly shows a case where the expectation
      is that each glyph is a separate, semi-transparent object, they
      glyphs have graffiti-like overlap and the rendering should reflect
      this.</p>
    <p>Which means I probably need to update CSS Color 4 to address both
      cases, and to point out that one size does not fit all cases.<br>
    </p>
    <p>Is the font you used freely available? If not, could I use your
      graphic (with attribution)?<br>
    </p>
    <div class="moz-cite-prefix">On 2021-01-09 05:30, Peter Constable
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:MWHPR1301MB211264CD3C6D32CE42BA151986AD0@MWHPR1301MB2112.namprd13.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
      <style>@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri",sans-serif;}span.EmailStyle25
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}div.WordSection1
        {page:WordSection1;}ol
        {margin-bottom:0in;}ul
        {margin-bottom:0in;}</style>
      <div class="WordSection1">
        <p class="MsoNormal">While reading the <a
            href="https://www.w3.org/TR/css-color-4/"
            moz-do-not-send="true">
            CSS Color Module Level 4 draft</a>, a related complication
          was brought to mind by figure 11:<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><img style="width:7.8166in;height:2.125in"
            id="Picture_x0020_2"
            src="cid:part2.1F698278.EA8596F5@w3.org" class=""
            width="750" height="204" border="0"><o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">If two elements of a composition overlap
          and have alpha < 1, their alphas would combine. What figure
          11 is showing is a case in which the alpha is applied to the
          text as a whole (the containing text element). But it brings
          to mind an issue for color fonts if glyphs are overlapping: In
          the case of a font like Use Your Imagination, the colour
          glyphs’ layers have alpha < 1, the glyphs intentionally
          overlap, and the expectation is that the alphas in the
          overlapping regions combine. E.g.,<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><img style="width:4.175in;height:2.8833in"
            id="Picture_x0020_3"
            src="cid:part3.20CCD686.9D6E439E@w3.org" class=""
            width="401" height="277" border="0"><o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">But one could imaging a different colour
          font for a cursively connected face in which overlapping
          glyphs have connections with fills of the same colour and
          alpha, and with the intent that the alphas do not combine but
          that the overlapping regions are intended to display with the
          same alpha as the stroke from each glyph would have—as in
          figure 11 above.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">The main point here is to point out one
          more way in trying to control compositional interactions
          between adjacent colour glyphs is non trivial, and a single
          example isn’t a sufficient representation of usage scenarios.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Peter<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b>From:</b> Vladimir Levantovsky
              <a class="moz-txt-link-rfc2396E" href="mailto:vladimir.levantovsky@gmail.com"><vladimir.levantovsky@gmail.com></a>
              <br>
              <b>Sent:</b> Wednesday, January 6, 2021 2:23 PM<br>
              <b>To:</b> 'Peter Constable' <a class="moz-txt-link-rfc2396E" href="mailto:pgcon6@msn.com"><pgcon6@msn.com></a>;
              'Georg Seifert' <a class="moz-txt-link-rfc2396E" href="mailto:typogeorg@gmail.com"><typogeorg@gmail.com></a>; 'Laurence
              Penney' <a class="moz-txt-link-rfc2396E" href="mailto:lorp@lorp.org"><lorp@lorp.org></a><br>
              <b>Cc:</b> 'MPEG OT Spec list'
              <a class="moz-txt-link-rfc2396E" href="mailto:mpeg-otspec@lists.aau.at"><mpeg-otspec@lists.aau.at></a><br>
              <b>Subject:</b> RE: [MPEG-OTSPEC] WD for AMD 2 and COLR v1
              enhancements<o:p></o:p></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><span style="color:#1F497D">> </span>Your
          suggestion below sounds relatively simple, but I’m not sure
          it’s as simple as it seems.<span style="color:#1F497D"><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">+1!<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">I don’t think
            it’s simple. If we assume it’s implemented …<o:p></o:p></span></p>
        <ul style="margin-top:0in" type="disc">
          <li class="MsoListParagraph"
            style="color:#1F497D;margin-left:0in;mso-list:l0 level1
            lfo2">
            the number of layer groups can’t be prescribed, it would be
            up to a font developer to decide. We may think we do not
            need more than three layer groups but it’s not up to us to
            decide;<o:p></o:p></li>
          <li class="MsoListParagraph"
            style="color:#1F497D;margin-left:0in;mso-list:l0 level1
            lfo2">
            we cannot assume to know the “meaning” of the layer group.
            Something simple, like e.g. “background” or “drop shadow”
            may seem straightforward, but like Peter said, even that can
            be problematic because shadow directions cast from a virtual
            light source would affect rendering results based on
            direction;<o:p></o:p></li>
          <li class="MsoListParagraph"
            style="color:#1F497D;margin-left:0in;mso-list:l0 level1
            lfo2">
            even if we think it’s ok to allow overlaps between glyphs in
            the same layer group – the overlaps of translucent
            background layers may still need blending;<o:p></o:p></li>
          <li class="MsoListParagraph"
            style="color:#1F497D;margin-left:0in;mso-list:l0 level1
            lfo2">
            applications would have to completely change their text
            rendering pipeline, starting with the need to determine a
            number of layer groups from the font [possibly, per glyph].
            Combining different glyph ranges on page may require
            different number of rendering layers (e.g. color +
            monochrome glyphs on the same line of text), multiple layers
            need to be rendered, and it would have to be redone every
            time there are any viewport / layout / spacing / scale
            changes …
            <o:p></o:p></li>
          <li class="MsoListParagraph"
            style="color:#1F497D;margin-left:0in;mso-list:l0 level1
            lfo2">
            in my opinion, any proposed change that affects how
            applications interact with fonts is a non-starter.<o:p></o:p></li>
        </ul>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D">Vlad<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b>From:</b> mpeg-otspec [<a
                href="mailto:mpeg-otspec-bounces@lists.aau.at"
                moz-do-not-send="true">mailto:mpeg-otspec-bounces@lists.aau.at</a>]
              <b>On Behalf Of </b>Peter Constable<br>
              <b>Sent:</b> Wednesday, January 6, 2021 2:35 PM<br>
              <b>To:</b> Georg Seifert <<a
                href="mailto:typogeorg@gmail.com" moz-do-not-send="true">typogeorg@gmail.com</a>>;
              Laurence Penney <<a href="mailto:lorp@lorp.org"
                moz-do-not-send="true">lorp@lorp.org</a>><br>
              <b>Cc:</b> MPEG OT Spec list <<a
                href="mailto:mpeg-otspec@lists.aau.at"
                moz-do-not-send="true">mpeg-otspec@lists.aau.at</a>><br>
              <b>Subject:</b> Re: [MPEG-OTSPEC] WD for AMD 2 and COLR v1
              enhancements<o:p></o:p></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoPlainText">Georg:<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">To discuss what might be feasible, I
          think we really need a better understanding of what set of
          problems might be solved. There has to be some limit to the
          functionality—we can’t provide Illustrator in a TTF—and I
          think to be feasible any additional capabilities would need to
          be very minimal. The original use case that made colour fonts
          a reality was emoji, and I think none of this is needed for
          emoji. But this question really pertains to text faces. What
          are the kinds of effects
          <o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">You've given one example, with letters
          that have a 3D extruded appearance, with the bodies of the
          letters not overlapping, but each having a layer for a shadow
          that extends (at least for some glyphs) beyond the left side
          bearing. Of course, the shadows could have gone to the right
          (virtual light source on the left), in which case the problem
          might not occur at all (at least for some implementations)
          because of how rendering is done. Note that the problem, in
          the most general case, isn't limited to colour fonts, but can
          also arise for achromatic fonts if adjacent glyphs overlap and
          are styled with different colours. Here's an example using
          Calibri with letter spacing condensed to create overlap:<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoNormal"><span style="font-size:48.0pt;color:red"
            lang="EN-CA">A</span><span style="font-size:48.0pt"
            lang="EN-CA">B<span style="color:red">C</span>D<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:48.0pt;color:red;letter-spacing:-10.0pt"
            lang="EN-CA">A</span><span
            style="font-size:48.0pt;letter-spacing:-10.0pt" lang="EN-CA">B<span
              style="color:red">C</span></span><span
            style="font-size:48.0pt" lang="EN-CA">D<o:p></o:p></span></p>
        <p class="MsoPlainText">Here’s a screenshot of how this appears
          in my mail agent:<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText"><img style="width:2.0in;height:1.75in"
            id="Picture_x0020_1"
            src="cid:part8.1E8A705C.9DF834A8@w3.org" class=""
            width="192" height="168" border="0"><o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">Now, each glyph overlaps on top of the
          glyph on its left. Someone might say, “Oh, but I want them to
          layer the opposite way.” That doesn’t imply there’s a
          compelling business case for text layout engines to add an
          option to control how overlapping glyphs layer. <o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">I do understand that this non-colour
          font example isn’t entirely applicable to colour fonts, but it
          raises a valid question: how much machinery does it make sense
          to add, and what is an appropriate threshold of diminishing
          returns.<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">Btw, I mentioned the <a
href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fontspace.com%2Fuse-your-imagination-font-f43274&data=04%7C01%7C%7C57c87363b8634946d3d408d8b2919cd9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637455685753903745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=knql33%2BclsVAiNEn17ZxPntDmbcfcdtgDVZoYlIKryY%3D&reserved=0"
            moz-do-not-send="true">
            Use Your Imagination</a> font, which has overlapping glyphs
          that have some transparency and so blend with simple alpha
          blending. If you look at the examples or try it out, you’ll
          notice the same right-over-left layering of adjacent glyphs,
          which is manifested by the drop-shadow effect (a transparent
          black layer). The shadow effect used in this font didn’t
          require any additional data in the font. (That font was
          implemented using OT-SVG, but could just as well have been
          implemented using COLR v0.)<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">Your suggestion below sounds relatively
          simple, but I’m not sure it’s as simple as it seems. First,
          there’s the question of what additional data is needed to
          describe layer groups. As I mentioned earlier, this wouldn’t
          be difficult for COLR v0 colour glyphs, but for COLR v1 the
          notion of layer is not so simple. Then there’s a question of
          what controls for blending of corresponding layer groups from
          adjacent glyphs should be provided: would only simple alpha
          blending be sufficient? Without example use cases, how do we
          decide that?<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">Then, there’s the implication for text
          rendering engines: it implies that engines must render all
          colour glyphs in each line in three separate passes: layer
          groups 0 for all glyphs in the line, then layer groups 1, then
          layer groups 2. Is that additional complexity in rendering
          implementations worth it? I think more business justification
          would be needed to convince implementers.<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">Peter<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">-----Original Message-----<o:p></o:p></p>
        <p class="MsoPlainText">From: Georg Seifert <<a
            href="mailto:typogeorg@gmail.com" moz-do-not-send="true">typogeorg@gmail.com</a>>
          <o:p></o:p></p>
        <p class="MsoPlainText">Sent: Wednesday, January 6, 2021 9:55 AM<o:p></o:p></p>
        <p class="MsoPlainText">To: Laurence Penney <<a
            href="mailto:lorp@lorp.org" moz-do-not-send="true">lorp@lorp.org</a>><o:p></o:p></p>
        <p class="MsoPlainText">Cc: Peter Constable <<a
            href="mailto:pgcon6@msn.com" moz-do-not-send="true">pgcon6@msn.com</a>>;
          MPEG OT Spec list <<a
            href="mailto:mpeg-otspec@lists.aau.at"
            moz-do-not-send="true">mpeg-otspec@lists.aau.at</a>><o:p></o:p></p>
        <p class="MsoPlainText">Subject: Re: [MPEG-OTSPEC] WD for AMD 2
          and COLR v1 enhancements<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">I don’t think we need to have control
          for M x N layers. Assigning a layer group ID would be
          sufficient. And I don’t think in most cases we need more than
          three groups (e.g. background/shadow, body, highlights; and in
          most cases body and highlights can be drawn together). This
          will not add much complexity. Draw all layers from each group
          for all glyph in the text box. I don’t think special control
          for blending between glyphs is needed, just draw then as it is
          now.<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">so instead of drawing:<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">    A.layer0, A.layer1, A.layer2,
          B.layer0, B.layer1, B.layer2
          <o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">we do (assuming that layer0 and layer1
          are in one group):<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">    A.layer0, A.layer1, B.layer0,
          B.layer1, A.layer2, B.layer2<o:p></o:p></p>
        <p class="MsoPlainText"><o:p> </o:p></p>
        <p class="MsoPlainText">Georg<o:p></o:p></p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
mpeg-otspec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>
<a class="moz-txt-link-freetext" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media</pre>
  </body>
</html>