[mpeg-OTspec] Interaction between kern table and GPOS table

[John Hudson]

Sairus wrote:

Perhaps the problem is that I am misunderstanding what you mean by 
'vendor' in the statement, so that should be clarified. I thought you 
were talking about application makers, but perhaps you meant font makers.

> What motivates our wanting to encourage vendors to move from the kern table to the GPOS table for kerning?

For me, the grounds for encouragement are that one can do a lot more 
with GPOS kerning than one can with kern table kerning. For some 
scripts, I would argue that GPOS kerning is essential because interglyph 
spacing needs to be contextual: pair kerning as implemented in the kern 
table simply isn't up to the task of correctly spacing these scripts. 
But even for 'simple' scripts like Latin, the limitation on encoded 
glyphs in the kern table is a major handicap. So long as application 
developers imagine that they can get by with supporting the kern table 
instead of GPOS kerning, fonts and typography will be handicapped by the 
inertia of this obsolete technology.

> If we envision some "pure" OT layout engine in the future that doesn't support the kern table, that might be a reason. However, given that practically every font in a Windows system that has kerning expresses it in a kern table (sometimes in addition to a GPOS feature),

On whose Windows system? Most of the fonts on my system have GPOS 
kerning only, and this is also true of most of the fonts that I have 
personally made for MS. The MS ClearType fonts had kern tables 
retroactively fitted to them when Office decided they wanted to make 
Calibri etc. standard fonts, but I take this as a good example of what 
I'm talking about: the inertia of app developers imagining that a kern 
table is an acceptable substitute, or even an equivalent, for GPOS kerning.

Because of the size limitation of the kern table*, no effort was made to 
extend the kern table kerning for the Windows 7 extensions to ClearType 
fonts: its a frozen legacy table supporting a small subset of the 
interglyph spacing adjustments in these fonts. Even ignoring the fact 
that it doesn't apply any kerning to unencoded glyph variants, it 
doesn't even apply kerning to all the encoded glyphs.

* As documented on the OT list by Joshua Hadley and Karsten Luecke in 
July 2007.

> It seems to me that the kern table is pretty much here to stay in the OT spec.

Even though its size limitations mean that an increasing number of fonts 
cannot be properly spaced using this table?

> All that said, it may be OK for that last sentence to be strengthened or to otherwise indicate the kern table as "deprecated",  but it would be good to be clear on why we're doing that. Suggestions for revised wording are welcome.

The only situation I can see in which I might opt for a kern table as a 
reasonable solution to interglyph spacing adjustments is if I were 
making a font that a) had a relatively small glyph set, b) required only 
adjustments to the spacing of encoded glyphs, and c) required backwards 
compatibility. Because of the backwards compatibility issue, I doubt if 
we're yet in a place in which we could formally deprecate the kern 
table, but I think a strong statement pointing out its limitations and 
discouraging its use would help move us towards an eventual deprecation.


> (John, BTW, I don't know if your statement "The interaction of kerning and mark positioning is the biggest weak spot in OT Layout: there is no easy way to address it." on the " GPOS kerning; pure anchor-based accents in Latin?" thread on the OT list 12/8/09 is related to this.)

No, not directly related. The difficulties of spacing and mark 
positioning interaction are specific to GPOS, i.e. they're the problems 
that arise even when one is using the best tools that OpenType has to 
offer. If one were using the kern table instead of GPOS, one wouldn't 
even be able to approach that particular set of challenges because the 
presence of the combining marks would break any kerning.


We're well over a decade into the 'OpenType era' now. Is disturbing to 
me that major applications are still relying of something as limited as 
the kern table while some of us are getting increasingly concerned with 
the limitations of OpenType itself.

JH



-- 

Tiro Typeworks        www.tiro.com
Gulf Islands, BC      tiro at tiro.com

Car le chant bien plus que l'association d'un texte
et d'une mélodie, est d'abord un acte dans lequel
le son devient l'expression d'une mémoire, mémoire
d'un corps immergé dans le mouvement d'un geste
ancestral.  - Marcel Pérès