[mpeg-OTspec] MS Proposal for a new Name Table ID

[Adam Twardoch (List)]

Dear mpeg-OTspec & opentype list members,

I'm not sure how the discussion on this topic concluded, but I'd like to 
revisit it, making an alternative proposal.

I personally think that there is great value to the OT script, language 
and feature tag system, one that could be leveraged.

Currently, the GSUB and GPOS tables describe how a certain glyph or a 
series of glyphs should be transformed under a certain context, the 
context being the script, language and feature.

As it has been noted in this discussion, what's missing is the 
information which default glyphs within the font are "good" for a 
certain script and language, i.e. which are "worthy" of exploring at 
all. But in my view, what's also missing is an indicator as to which 
forms certain glyphs have by default, *before* any GSUB or GPOS features 
were applied.

I think a table could be devised that would make use of the current 
script, language and feature system, but instead of using any lookups, 
that table would only include the glyph coverage info, which is already 
defined the OTL structure.

We could define a "GINF" (Glyph Info) table which uses the OT script and 
language structure to provide mappings to ENCODED (or -- alternatively 
-- ALL, not sure myself) glyphs within a font file which are used for a 
certain OT script, or a certain languagesystem -- but they should only 
be included if their usage is MEANINGFUL, i.e. if the glyphs are "well 
designed" for the purpose.

Such structure could be used by a font engine to quickly identify a 
subset of glyphs which are relevant for a particular script and 
languagesystem. Inside this structure, there would be no real "action" 
associated with a lookup. So probably a special lookup type would need 
to be defined which has a coverage table but nothing else.

The GINF would be especially useful to tell applications which script or 
language is well supported by the default, i.e. encoded glyph forms. And 
the GINF table could also include feature tags which would be used if a 
font already has a default glyph form which would normally be yielded 
through the application of a feature.

So for example, if a font includes oldstyle numerals in the default 
glyphs for the digit Unicodes, the GINF table could provide the info:
   Script: DFLT, LangSys: dflt, Feature: onum, Coverage: [zero one two 
... eight nine]
Conversely, the GSUB table would then include:
   Script: DFLT, LangSys: dflt, Feature: lnum -- and the appropriate 
substitution to lining numerals
An application would "know" that for such a font, to get oldstyle 
numerals, it would need to do "nothing", i.e. not apply any GSUB feature 
at all.

Similarly, if a font includes small caps glyphs mapped directly in the 
"cmap" to lowercase Unicode codepoint (because it does not have "real" 
lowercase letterforms at all), the GINF table could provide the info:
   Script: latn, LangSys: dflt, Feature: smcp, Coverage: [a b c ...]

The same kind of information could be used to have information about CJK 
glyphs. If the font is designed for Simplified Chinese, it would simply 
have something like:
   Script: hani, LangSys: ZHS, Feature: <empty>, Coverage: [all CJK 
glyphs which are mapped to Unicodes]

So for the structure, I *guess* there would be a need to have a way to 
express an empty feature tag, but perhaps not.

As for GINF lookup types, we could even think of having several "levels" 
of information, which could be expressed by different kinds of lookups. 
I can think of two right away:

GINFLookupType1: Basic Glyph Information
Just coverage table -- the glyph information consists simply of the 
presence of a GID in the coverage table

GINFLookupType2: Glyph Information with Simple Names
Coverage table plus some kind of references to a name table ID (using a 
similar format as GSUBLookupType1, but name table IDs would be used 
instead of the substituted GIDs) -- per GID or class, there could be a 
reference to a name ID string. This way, symbol fonts or fonts with 
unusual glyphs could store human-readable descriptions of the glyph's 
contents in the "name" table, and provide a mapping here.

GINFLookupType3: Glyph Information with Extended Names
coverage table, plus a set of entries which point to name table IDs for:
* human-readable glyph description
* designer's name
* license text
* ...

(We could agree on a few useful ones.)

Additional GINFLookupTypes could be added in future.

The above is not a fully-formed proposal (and probably the proposed 
structure is a bit "naiive"), but could prove useful for both the 
purposes that Microsoft has aimed at in the original proposal, and 
beyond. In essence, my idea is to re-use the OTL table structure for 
this kind of information. Of course the GINFLookupTypes 2 and 3 are just 
an attempt to add value for other purposes, especially to give 
developers a chance to sensibly include human-readable information on a 
per-glyph basis, which I think is something many people would welcome.

Best,
Adam

-- 

May success attend your efforts,
-- Adam Twardoch
(Remove "list." from e-mail address to contact me directly.)