Kerning

Wed Mar 24 14:36:43 CET 2010

Dear all,

In order to be able to submit ballot comments in time for them to be processed through official channels we need to finalize the modifications to the text of the corrigendum by March 29th (Monday next week). There are two changes that were proposed:

1)      Replacing “must” with “should” in the Recommendations section for ‘kern’ table (see email from Sairus below), and

2)      Changing the recommended order of GPOS / kern processing, as suggested by Behdad – I am quoting his email he sent to OpenType list:

> (a) If the number of kern feature lookups in the resolved language system in the GPOS table is zero,

> then the kern table must be applied, followed by any remaining GPOS features requested.

I believe the order should be the other way around.  GPOS applies on the logical glyph stream whereas 'kern' applies on the visual glyphs.  So, normally, GPOS is applied, glyphs reversed for RTL runs, then kern applies.
Thank you,
Vladimir

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Sairus Patel
Sent: Thursday, March 11, 2010 7:25 PM
To: opentype-migration-list at indx.co.uk; mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] RE: [OpenType] Kerning

Thanks for the explanation, Si. From what you’re saying, it sounds like TT fonts must have a kern table in order for kerning to happen in PowerPoint Office 2007, at least on Windows. (Does anyone know of other such apps?)

I didn’t call them out in the lists of Windows fonts with both GPOS and kern tables below, but as I’ve mentioned before, important fonts such as Times New Roman and Arial in Vista have a kern table and a GPOS table with no kern feature.

What should a layout engine do in this case? I’m not sure users will be very happy if OpenType apps don’t kern their TNR and Arial documents – or if the GPOS features that are present don’t get applied.

Or do we consider the above fonts to be badly made?

If it helps, I think it’s OK to change the “must”s in Adobe’s proposal (quoted by Vlad below) to “should”s. It is in the Recommendations section, after all, and not in the spec proper. (I think layout engine behavior should be in the spec proper, but that’s not something that will be addressed in this next round.)

Also, if desired, I’m OK with changing “font vendors are encouraged” to “font vendors are strongly encouraged”.

(I’ll be out of the office March 12-22, BTW.)

Best,

Sairus

-----Original Message-----
From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of Levantovsky, Vladimir
Sent: Wednesday, March 10, 2010 12:04 PM
To: multiple recipients of OpenType - sent by
Subject: RE: [OpenType] Kerning

Message from OpenType list:

Thank you, Michelle.

All,

Currently, there is a language in the ISO/IEC 14496-22/DCOR1 (draft corrigendum) that modifies ‘kern’ table section of the “Recommendations” (chapter 7) by adding the following:

When a kern table and GPOS table are both present in a font, and an OFF layout engine is requested to apply kerning to a run of text of a particular script and language system: (a) If the number of kern feature lookups in the resolved language system in the GPOS table is zero, then the kern table must be applied, followed by any remaining GPOS features requested. (b) If the number of kern feature lookups in the resolved language system in the GPOS table is non-zero, then all GPOS lookups, including the kern lookups, must be applied in the usual way and the kern table data ignored.

If a kern table but no GPOS table is present in the font, then an OFF layout engine must apply the kern table to the text, regardless of the resolved language system of the text.

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.

If we want to modify the text of the corrigendum, we need to come up with and agree on the new wording. The draft corrigendum is currently under open ballot, and in order to submit ballot comments on time we need to finalize any changes to the text no later than end of March.

Thank you and best regards,

Vladimir

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Michelle Perham

Sent: Wednesday, March 10, 2010 2:32 PM

To: mpeg-OTspec at yahoogroups.com

Subject: [mpeg-OTspec] FW: [OpenType] Kerning

Forwarding Simon's response posted to the other list.

-----Original Message-----

From: listmaster at indx.co.uk<mailto:listmaster%40indx.co.uk> [mailto:listmaster at indx.co.uk<mailto:listmaster%40indx.co.uk>] On Behalf Of Simon Daniels

Sent: Wednesday, March 10, 2010 10:58 AM

To: multiple recipients of OpenType - sent by

Subject: [OpenType] Kerning

Message from OpenType list:

Hi,

Responding to earlier questions regarding OpenType Kerning and TrueType kern table co-existing in some of our fonts.

There are two reasons some of our fonts contain both styles of kerning…

1. During the development of Office 2007 we made the case for PowerPoint turning on kerning by default. When they followed our advice they found that the new C* fonts were not kerning, we knew we really had to do something, and that was adding in the kern table. This happened at the last minute during Windows Vista/Office 2007, by converting OT-kerning to kern and removing all pairs that contained unmapped glyphs.

2. Some Windows apps, and Mac OS, assumed that any font with GPOS table would contain OpenType kerning, so kern table was being ignored in fonts like TNR which had mark positioning. For this reason we had to add OpenType kerning to some of the legacy fonts which we’d licensed to Apple as well as those commonly used in the OT-savvy Windows apps.

I don’t know if the spec needs to talk about what to do if a font contains both. One would expect that both sets are compatible, and that the app would use the OpenType kerning first, and only use kern if there were no GPOS kerning.

Cheers, Si

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Sairus Patel
Sent: Tuesday, March 02, 2010 4:16 PM
To: mpeg-OTspec at yahoogroups.com; opentype-migration-list at indx.co.uk
Subject: RE: [mpeg-OTspec] Interaction between kern table and GPOS table

Microsoft wrote on 2/9/2010:
> It is trying to cover some class of legacy cases… I do not even know how common this case is.

Fonts containing both GPOS and kern tables that ship with Windows:

** XP SP2: 4 fonts **
(pala.ttf palab.ttf palabi.ttf palai.ttf)

** Vista: 65 fonts **
(arial.ttf arialbd.ttf arialbi.ttf ariali.ttf ariblk.ttf calibri.ttf calibrib.ttf calibrii.ttf calibriz.ttf cambria.ttc cambriab.ttf cambriai.ttf cambriaz.ttf Candara.ttf Candarab.ttf Candarai.ttf Candaraz.ttf constan.ttf constanb.ttf constani.ttf constanz.ttf corbel.ttf corbelb.ttf corbeli.ttf corbelz.ttf dokchamp.ttf euphemia.ttf framd.ttf gisha.ttf gishabd.ttf himalaya.ttf impact.ttf iskpota.ttf leelawad.ttf leelawdb.ttf meiryo.ttc meiryob.ttc monbaiti.ttf moolbor.ttf pala.ttf palab.ttf palabi.ttf palai.ttf segoepr.ttf segoeprb.ttf segoesc.ttf segoescb.ttf segoeui.ttf segoeuib.ttf segoeuii.ttf segoeuiz.ttf tahoma.ttf tahomabd.ttf times.ttf timesbd.ttf timesbi.ttf timesi.ttf trebuc.ttf trebucbd.ttf trebucbi.ttf trebucit.ttf verdana.ttf)

** Windows 7 (Enterprise): 81 fonts **
(arial.ttf arialbd.ttf arialbi.ttf ariali.ttf ariblk.ttf calibri.ttf calibrib.ttf calibrii.ttf calibriz.ttf cambria.ttc cambriab.ttf cambriai.ttf cambriaz.ttf Candara.ttf Candarab.ttf Candarai.ttf Candaraz.ttf constan.ttf constanb.ttf constani.ttf constanz.ttf corbel.ttf corbelb.ttf corbeli.ttf corbelz.ttf dokchamp.ttf euphemia.ttf framd.ttf gisha.ttf gishabd.ttf himalaya.ttf impact.ttf iskpota.ttf iskpotab.ttf KhmerUI.ttf KhmerUIb.ttf LaoUI.ttf LaoUIb.ttf leelawad.ttf leelawdb.ttf meiryo.ttc meiryob.ttc monbaiti.ttf moolbor.ttf msjh.ttf msyh.ttf pala.ttf palab.ttf palabi.ttf palai.ttf segoepr.ttf segoeprb.ttf segoesc.ttf segoescb.ttf segoeui.ttf segoeuib.ttf segoeuii.ttf segoeuil.ttf segoeuiz.ttf seguisb.ttf seguisym.ttf Shonar.ttf Shonarb.ttf tahoma.ttf times.ttf timesbd.ttf timesbi.ttf timesi.ttf tradbdo.ttf trado.ttf trebuc.ttf trebucbd.ttf trebucbi.ttf trebucit.ttf verdana.ttf)

Cleary, the number of such fonts is *increasing* with every new version of Windows. Brand-new font families as well as some of the most commonly used fonts in the world (Arial and Times, as listed above) have both GPOS and kern tables.

Surely the OT/OFF specs cannot ignore addressing how such fonts are to be handled.

> It is really easy to generate GPOS lookups out of ‘kern’ table, especially with my kern2volt toolJ.

In that case, it would be good to know the reason for putting the ‘kern’ table in fonts -- especially new families -- that ship with Windows. Or are all the fonts above to be considered badly made?

I think understanding that is an important first step in getting resolution on this issue.

Best,
Sairus

From: Michelle Perham [mailto:mihill at microsoft.com]
Sent: Tuesday, February 09, 2010 12:40 PM
To: Levantovsky, Vladimir; Sairus Patel; John Hudson
Cc: mpeg-OTspec at yahoogroups.com
Subject: RE: [mpeg-OTspec] Interaction between kern table and GPOS table [1 Attachment]

Thanks Vlad. At Microsoft we have some concerns over the kern table recommendations. Here is a summary of our concerns that was compiled by Sergey:

- It is hard to define exact behavior that will work for everybody. Does it make sense to make it per-script or we just cover legacy font with no kerning lookup at all? Should we skip mark glyphs while looking for kerning pairs? There is no strict answer for these questions, so it opens door for incompatible implementations and, therefore, hacky fonts.

- It is dangerous to combine kern and GPOS lookups. It may seem to help with some fonts, but will mess up less obvious cases. I remember how easily we broke font lookups by zeroing widths of mark glyphs outside of GPOS. Applying kerning may have the same effect.

- It is really easy to generate GPOS lookups out of ‘kern’ table, especially with my kern2volt toolJ. We did this backwards for ClearType fonts without much effect on overall font size. FontLab also should be able to generate both from one source.

- I do not see this as implementation spec, it has appropriate level of detail for desired behavior. But it does not mean I like this proposed behavior. It is trying to cover some class of legacy cases, will open door for future hack,  have danger of breaking old fonts and may not work as Adobe expects it to work. And I do not even know how common this case is.

- Too many ‘must’s.

Michelle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100324/56377f9e/attachment.html>