<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>With this sort of deep and messy question it can be clarifying to
      consider how one <i>should</i> address the answer in the
      specification.</p>
    <p>If I understand you right, things have gone against the
      script/language mechanism over the past decades on the (broadly
      speaking) client side. So the responsible thing to do now would be
      to deprecate that mechanism in the spec and recommend that future
      fonts do all substitutions and positioning in the context of DFLT
      dflt. This will save foundries a lot of effort and heartache. <br>
    </p>
    <p>Analytically: if this is what should be said then we should say
      it.</p>
    <p>What worries me about the dmap proposal <i>as a solution to the
        language/region problem</i> is:</p>
    <ol>
      <li>Instead of saying the above outright, it sort of mumbles it in
        a way that will be picked up on by sophisticated readers, who
        will realize that constructing TTC slots with distinct
        (effective) cmaps, and then also trying to have all of those
        slots support every language via GSUB/GPOS, increases the
        development burden and multiplies the QA burden so that must not
        have been the intended goal.</li>
      <li>Because of 1, it creates a self-fulfilling prophecy of fewer
        and fewer fonts using the GSUB/GPOS mechanism leaving less and
        less of a reason for client-side implementations to use them
        fully and correctly. <br>
      </li>
    </ol>
    <p>Thus we consign the future to the present while hanging anyone
      who missed the message out to dry.</p>
    <p>In contrast, a hinge point in GSUB/GPOS means that one can design
      a single unified font and just tie into the "initial"
      script/language using the overlapping GSUB trick (which could
      presumably be canned in a tool-set like fontTools) and TTC,
      addressing the messy present while not giving up on the better
      future.</p>
    <p>Skef<br>
    </p>
    <div class="moz-cite-prefix">On 12/27/23 08:55, John Hudson wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:97e5bffd-39b0-48e4-82e5-0e2268c3b326@tiro.ca">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div class="moz-cite-prefix">On 2023-12-27 3:19 am, Skef Iterum
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:1a29b310-0df5-4529-b60e-3d8890afcdf5@skef.org">
        <meta http-equiv="Content-Type"
          content="text/html; charset=UTF-8">
        <p>Some preliminary notes on an idea I'm looking info, starting
          from this line of reasoning:</p>
        <ol>
          <li>My worry about using dmap for multi-language/region
            support is that the solution is separate from the
            script/language GSUB/GPOS mechanism. <b>Ideally we want
              fonts that support different scripts and languages via the
              latter</b>, and doing so while starting with different
            initial cmaps is a lot of work and QA.</li>
        </ol>
      </blockquote>
      <p><b>Do we? </b>The langsys mechanism in OTL has proven to be
        unreliable for coming up on thirty years, such that we now
        recommend to clients having separate fonts for individual
        languages if differences in glyph shape or behaviour are
        considered critical. The chain of things that document creators
        and software need to get right to ensure correct display of
        langsys-specific GSUB or GPOS is too fragile to be reliable,
        while selecting a clearly labeled font targeting a specific
        language is much more robust. Hence, e.g. Tiro Devanagari Hindi,
        Tiro Devanagari Marathi, and Tiro Devanagari Sanskrit.</p>
      <p>JH<br>
      </p>
      <p><br>
      </p>
      <pre class="moz-signature" cols="72">-- 

John Hudson
Tiro Typeworks Ltd    <a class="moz-txt-link-abbreviated"
      href="http://www.tiro.com" moz-do-not-send="true">www.tiro.com</a>

Tiro Typeworks is physically located on islands 
in the Salish Sea, on the traditional territory 
of the Snuneymuxw and Penelakut First Nations.

__________

EMAIL HOUR
In the interests of productivity, I am only dealing 
with email towards the end of the day, typically 
between 4PM and 5PM. If you need to contact me more 
urgently, please use other means.</pre>
      <br>
      <fieldset class="moz-mime-attachment-header"></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>
  </body>
</html>