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

[Skef Iterum]

Having said the previous message, there's still the question of what to 
do about

    On 1/3/24 16:28, Peter Constable wrote:
>
>     >My basic concern is … fewer fonts//will attempt to use the
>     script/langsys mechanism correctly…
>
>     That’s a valid and reasonable concern.
>
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.

I think we've brought up three sorts of things in this area, any of 
which we might pursue to improve the overall picture:

 1. 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.)
 2. 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.
 3. 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.

Skef

On 1/5/24 15:26, Skef Iterum wrote:
>
> 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
>
> _______________________________________________
> 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/a302adf4/attachment-0001.html>