<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Having said the previous message, there's still the question of
what to do about</p>
<blockquote>
<div class="moz-cite-prefix">On 1/3/24 16:28, Peter Constable
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:PH7PR21MB33560E1B1462958BAF72E154DE672@PH7PR21MB3356.namprd21.prod.outlook.com">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">></span>My
basic concern is … fewer fonts<i>
</i>will attempt to use the script/langsys mechanism
correctly…<span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">That’s
a valid and reasonable concern.
</span></p>
</blockquote>
</blockquote>
<p>And more particularly the fact that, while there are other
reasons for dmap, it did seem like the conversation about it
started as a solution to the current state of
multi-language/region support.</p>
<p>I think we've brought up three sorts of things in this area, any
of which we might pursue to improve the overall picture:<br>
</p>
<ol>
<li>The GSUB tricks I've been talking about seem like they already
fit within the spec and could provide a way for fonts that
already support multiple langsys tags to "export" any of those
as the "dflt" in a TTC slot. (One might also have to play around
with the name table.)</li>
<li>The langsys tag registration system seems a little
disconnected from standards, and maybe that should be fixed. One
possibility: a new langsys table format with a 6 or 8 byte "tag"
size, to allow direct representation of some existing or new
standard or standards (e.g. ISO 639-3 plus something for
regions). Another more likely possibility: provide and maintain
a standard map from some existing or new standard or standards
to tags, and add a table allowing fonts to supplement that map
with new entries if needed.</li>
<li>There's an intriguing, more general idea of some way of
allowing a TTC slot to, in effect, alter the default behavior of
the font as described in its tables. We talked about specifying
a langsys tag and having the slot act as if that tag had been
specified. One could imagine doing the same thing with a style
tag like 'ss03'. Or a named instance of in a variable font. Or
really anything that can currently be picked using CSS. In
theory this might even be based on some subset of CSS, provided
as a blob in a new table. This is in the general spirit of
allowing many different features and possibilities to coexist in
a single font but then allowing those to be shared as the
default behavior of a TTC slot, providing backward compatibility
for applications that need distinct fonts. <br>
</li>
</ol>
<p>Skef<br>
</p>
<blockquote></blockquote>
<div class="moz-cite-prefix">On 1/5/24 15:26, Skef Iterum wrote:<br>
</div>
<blockquote type="cite"
cite="mid:13a9dd34-ae19-484e-bb30-c5e0bb8ee73d@skef.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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 moz-txt-link-freetext"
href="mailto:mpeg-otspec@lists.aau.at" moz-do-not-send="true">mpeg-otspec@lists.aau.at</a>
<a class="moz-txt-link-freetext"
href="https://lists.aau.at/mailman/listinfo/mpeg-otspec"
moz-do-not-send="true">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a>
</pre>
</blockquote>
<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>