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