<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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">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>
</body>
</html>