[MPEG-OTSPEC] The substitution spectrum, was Re: [EXTERNAL] Shared GSUB/GPOS notes, was Re: dmap proposal

[Skef Iterum]

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.

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.

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.)

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).

So:

 1. I agree that cases like Peter describes exist in current practice.
 2. I don't see these cases as being "central", really, but
 3. Plenty of other things just as "non-central" have functionality in
    the spec.

Thus there's no reason not to pursue "dsub".

Skef

On 1/3/24 17:58, John Hudson wrote:
> On 2024-01-03 1:06 pm, Peter Constable wrote:
>>
>> > Constructing a GSUB that will work correctly downstream from 
>> different cmaps is a strange thing to even attempt.
>>
>> 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.
>>
>
> Thinking this through:
>
> The CMAP table produces the initial state of the glyph run for the 
> input character string.
>
> Different CMAP tables will produce different initial states of the 
> glyph run for the same input character string.
>
> 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.
>
> 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.
>
> 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.
>
>> 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?
>>
> 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.
>
> 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.
>
> JH
>
>
> -- 
>
> John Hudson
> Tiro Typeworks Ltdwww.tiro.com
>
> 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.
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240105/13c32f56/attachment.html>