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

[Martin Hosken]

Dear Adam,

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

I don't understand the need for the coverage table in this structure. An application works in terms of unicode values and not glyphs. There is no reverse mapping from glyphs to USVs. So what is the value of having a list of glyphs? If it is to, in effect, repeat the exemplar information for a language, wouldn't that be easier done by a different mechanism such as LDML? In the case of Indic, having a list of conjunct glyphs for a language also tells us nothing. More helpful would be an exemplar listing all the required conjuncts as unicode strings which an application can run through gsub and see if the result is a single glyph or else it can trust the font when it reports that it supports that particular language.

I also think you are conflating two ideas: writing system support and default feature settings. Any feature settings given for one language are also going to need to be listed for all other languages. An alternative proposal would be to have two new string ids in the name table (yes I know it's a slight abuse of the multilingual nature of name table entries, but it would be very cheap to implement).

id LANGSUPPORT: A space separated list of language tags known to be intentionally supported by this font.

id FEATURES: A list of features that can be changed and their default values as a space separated list of id=val strings.

As I write this I realise that we had a discussion about LANGSUPPORT before. Trying to get a complete list for latin would be problematic. But OTOH we are no worse off for some minority language if no fonts say they support it than we were before and any hints we can get can help.

In addition, it is possible to specify this information using GSUB/GPOS now simply by mapping different script+language pairs to the same structure that dflt+DFLT maps to. An application can get a complete list of script+lang tags and also a list of features that script+lang pair supports (or globally).

Either way, if we give up the need for a coverage table, on the grounds that it doesn't really tell us anything, we can get what you want for next to no cost to the standard.

Yours,
Martin