<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I've been thinking about this a bit more in light of both of
Peter's and John's thoughts and I'll try to summarize where I
wound up.</p>
<p>On the one hand, yes, I was too quick to say that different cmaps
followed up by a single GSUB would be a strange thing to attempt.
When, in a "post-cmap" context, all remaining problems of
substitution are "stylistic" in the narrow sense, one unified
table would do. For instance, if one cmap maps point A to X, and
another to Y, and from the perspective of the designer the other
glyphs to be substituted are "X but in a different style" and "a
ligature of Y with Z", then there's no issue. <br>
</p>
<p>At the other extreme are (individual) fonts designed to support
many language tags. In this case, if one changes the cmap like the
case above, some tag will need to (in effect) remap X back to Y
and another Y back to X. This is easy to arrange with distinct
GSUBs corresponding to the distinct cmaps because one knows "where
A starts at". With a single GSUB the whole situation stops making
sense. It's much easier to know that A always starts at X and
reassign it than to have to, in effect, catch A at either X or Y
and then assign it to X or Y as needed by the tag. (Or, more
generally that codepoint assignments start out as, e.g., for
Japanese and then reassign them for simplified Chinese or Hong
Kong Chinese as needed, rather than start out assigned for one of
several initial languages.)</p>
<p>I have been informally thinking that most fonts will do at least
some of the latter, which I'm also hearing from John. In a later
message Peter describes the Meiryo case as an example of a class
that doesn't need to (because even if the TTC instances do each
support multiple languages, the differences are such that they can
be mapped stylistically). Actually there are two classes, if I'm
understanding right. One is providing a separate font via TTC
because that's the way stylistic variations of one script (e.g.
italic Latin) are generally supplied, even though the glyphs for
the central script (e.g. Japanese) are the same. The other is
supplying a version of a font with some tweaks (e.g. a "UI" font),
where there is no other standard convention for representing the
difference (although the fact that one can't use a stylistic
variant tag for that purpose, although true, is a bit sad). </p>
<p>So: <br>
</p>
<ol>
<li>I agree that cases like Peter describes exist in current
practice.</li>
<li>I don't see these cases as being "central", really, but</li>
<li>Plenty of other things just as "non-central" have
functionality in the spec.</li>
</ol>
<p>Thus there's no reason not to pursue "dsub".</p>
<p>Skef<br>
</p>
<div class="moz-cite-prefix">On 1/3/24 17:58, John Hudson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6f313ff6-3aae-4ffd-8946-adc46207ade7@tiro.ca">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 2024-01-03 1:06 pm, Peter
Constable wrote:<br>
</div>
<blockquote type="cite"
cite="mid:PH7PR21MB33562BA61986B8264893A73DDE602@PH7PR21MB3356.namprd21.prod.outlook.com">
<p class="MsoNormal"><span style="font-size:11.0pt">></span>
Constructing a GSUB that will work correctly downstream from
different cmaps is a strange thing to even attempt.<span
style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Why so? In a
TTC, one table that will almost certainly be common is the
glyf/CFF/etc. table with outline data. In that case, the
glyph IDs are the same across all of the font resources. So,
there can be a single lookup list; if any glyph IDs appear
in a lookup coverage table but aren’t mapped from cmap, then
that data is ignored.</span></p>
</blockquote>
<br>
<p>Thinking this through:<br>
</p>
<p>The CMAP table produces the initial state of the glyph run for
the input character string.</p>
<p>Different CMAP tables will produce different initial states of
the glyph run for the same input character string.<br>
</p>
<p>Those different glyph runs may both be processable in a single
GSUB and/or GPOS table if these are structured around the
knowledge that the different CMAP tables are producing the
upstream glyph input for everything that happens in the
subsequent GSUB and GPOS.<br>
</p>
<p>In this respect, the different CMAP tables feeding glyph runs
into the OTL processing are akin to the rvrn, locl. or ccmp
layout features, i.e. things that affect the initial state of
the glyph run in preparation for downstream GSUB and GPOS. They
can be said to be ‘pre-affecting’ the initial state of the glyph
run, but have the same implications: downstream GSUB and GPOS
have to take their effects into account.<br>
</p>
<p>I can think of situations in which the (down)streams merge, but
I think this would only result in an unwanted ambiguity if a
font developer were careless: such merging would likely be
intentional, reflecting a state in the glyph run where the
initial distinction either is no longer relevant—e.g. where the
shaping of a glyph sequence into a conjunct ligature removes the
shape distinction that mattered at the outset.</p>
<blockquote type="cite"
cite="mid:PH7PR21MB33562BA61986B8264893A73DDE602@PH7PR21MB3356.namprd21.prod.outlook.com">
<p class="MsoNormal"><span style="font-size:11.0pt"> So it seems
like the only reason for needing separate GSUB or GPOS
tables would be if the scripts, language systems or features
needed to be different. Is that ever necessary?</span></p>
</blockquote>
<p>Yes, see e.g. Nirmala UI and Nirmala Text, which ship as a
single TTC with a common glyf table but distinct GSUB and GPOS
supporting different behaviours for the same glyphs in different
target environments.<br>
</p>
<p>I can also imagine—but have not seen—someone building a TTC as
a combined delivery format for a bunch of different typefaces
supporting a variety of scripts, but some of the nominal fonts
in the TTC might only support a subset of the total set of
scripts, so would have tailored OTL tables.<br>
</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>