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

[Levantovsky, Vladimir]

Here is the latest version of the draft corrigendum (attached) - please review and let me know if any corrections are needed.

Thank you,
Vladimir


> -----Original Message-----
> From: Sairus Patel [mailto:sppatel at adobe.com]
> Sent: Wednesday, January 20, 2010 11:06 PM
> To: Levantovsky, Vladimir; John Hudson
> Cc: mpeg-OTspec at yahoogroups.com; opentype-migration-list at indx.co.uk
> Subject: RE: [mpeg-OTspec] Interaction between kern table and GPOS
> table
> 
> John Hudson 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.
> 
> Yes, I meant font makers. Here is a revision of the last sentence of my
> proposal:
> 
> "If compatibility with legacy environments is not a concern, font
> vendors are encouraged to record kerning in the GPOS table's kern
> feature and not in the kern table."
> 
> Vladimir, could you please replace the last sentence of my proposal
> with the above.
> 
> Thanks,
> Sairus
> 
> 
> -----Original Message-----
> From: Levantovsky, Vladimir
> [mailto:Vladimir.Levantovsky at MonotypeImaging.com]
> Sent: Wednesday, January 20, 2010 8:00 PM
> To: John Hudson; Sairus Patel
> Cc: Behdad Esfahbod; mpeg-OTspec at yahoogroups.com; opentype-migration-
> list at indx.co.uk
> Subject: RE: [mpeg-OTspec] Interaction between kern table and GPOS
> table
> 
> Since I did not see any objections to Sairus' proposal I will go ahead
> and add this text to the corrigendum.
> I also suggest that we should discuss in details the points that John
> brought up in his email. I think his arguments are valid and
> emphasizing the benefits of GPOS-based kerning would be a good thing.
> We can discuss it and, if agreed, make changes in the corrigendum via
> ISO ballot process. (which will be opened for three months once the
> draft corrigendum is approved).
> 
> Thank you and best regards,
> Vladimir
> 
> 
> > -----Original Message-----
> > From: John Hudson [mailto:john at tiro.ca]
> > Sent: Wednesday, January 20, 2010 4:11 PM
> > To: Sairus Patel
> > Cc: Levantovsky, Vladimir; Behdad Esfahbod; mpeg-
> > OTspec at yahoogroups.com; opentype-migration-list at indx.co.uk
> > Subject: Re: [mpeg-OTspec] Interaction between kern table and GPOS
> > table
> >
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 330 bytes
Desc: w1xxxx-14496-22_DCOR1.doc
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100120/a79f56db/attachment.bin>