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

[John Hudson]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240103/2bafaff7/attachment.html>