Which pairs are you looking at (and which font version)?

5.062

AV versus VA?

Which version is shipping with Windows 7?

5.62 is the Windows 7 version. Looking at the font in PPT there is kerning in both pairs.

Cheers, Si

I tried setting the same thing in Corel Draw and it seems to be kerning AV and VA but I'm confused...there is an AV pair in the kern table but no VA. I'm guessing kerning is being done elsewhere? Where is it being set if not in kern table?

Calibri has both a kern table and OpenType kerning.

Cheers, Si

Thanks Si.

In OpenType window the kern feature just says:

feature kern { # Kerning
# Latin
lookup kern1 {
lookupflag IgnoreMarks;
} kern1;
language TRK ; # Turkish
language ROM ; # Romanian
language IPPH;
script grek; # Greek
lookup kern1;
script cyrl; # Cyrillic
lookup kern1;
language SRB ; # Serbian
} kern;

Where are the actual pairs and their values???

(Sorry if I'm being thick.)

>Calibri has both a kern table and OpenType kerning.

Is that recommended? What's the reason for having both?

Calibri and the other MS ClearType fonts were originally made with GPOS kerning only. When MS Office decided to adopt some of these fonts as defaults, they requested that kern tables be added, since Office apps did not yet -- and still do not! -- support GPOS kerning for European scripts. The kern tables contain filtered flattened kerning from the GPOS sources, including only encoded glyphs; even so, the size of some of the kern tables is very large, and it is quite possible that apps might fail to support all the kern pairs.

In general, I'd recommend against including both GPOS and kern table kerning, unless a client specifically requests it and has some pressing technical need.

Thanks, John, that's a very comprehensive answer. I thought it was not exactly recommended.

The kern table for Calibri seems really arbitrary: caps from A to O and some accented caps too, no lower case in the first glyph in the pair. That's why I was confused.

So, no-one's answering... where are the actual kerning pairs for Calibri (if the kern table is not a full set)???

The full kerning in Calibri is implemented in the GPOS table, using the OTL kern feature rather than the kern table. The kern table contains a subset of the full kerning, for use by applications that do not support GPOS kerning.

But I'm wondering how are you checking the contents of the kern table, Nick? I've made a dump of the Calibri Regular kern table, and it contains 26,706 kern pairs, including plenty of lowercase letters in the first glyph position.

Anyone want to see them all? :)

I've made a dump of the Calibri Regular kern table,

If I run ttx Calibri.ttf, the file Calibri.ttx contains a kern table with 3225 entries.

And I get the same as Nick for the first glyphs. Here they are for Calibri version 2.00

A AE AEacute Aacute Abreve Acircumflex Adieresis Agrave Amacron Aogonek Aring Aringacute Atilde B C Cacute Ccaron Ccedilla Ccircumflex Cdotaccent D Dcaron Dcroat E Eacute Ebreve Ecaron Ecircumflex Edieresis Edotaccent Egrave Emacron Eogonek Eth F G Gbreve Gcircumflex Gcommaaccent Gdotaccent H Hcircumflex J Jcircumflex K Kcommaaccent L Lacute Lcommaaccent O Ograve

On the other hand, the size of the kern table returned by "ftxdumperfuser -l calibri.ttf" is 84906 bytes. So is the size of the file obtained by using "sfntedit -x kern calibri.ttf". And finally, if I remove the _k_e_r_n.py and _k_e_r_n.pyc files of ttx, the hex dump of the kern table that ttx produces also gives 84906 bytes.

And I get this message from FontForge: In the 'kern' table, a subtable's length does not match the number of kerning pairs.

It looks like ttx is only dumping the first kernsubtable.

In any case, FontForge gives 14148 kerning pairs. On the other hand, the file Calibri.kern.xml given by "ftxdumperfuser -A a calibri.ttf" reports just one table:


<KERNTable version="0" subtableCount="1" >
<kernSubtable format="1" length="19366" coverage="0x0001" tupleIndex="14148" kernVertical="no" kernCrossStream="no" kernVariation="no" >
</kernSubtable>
</KERNTable>

The length does not make much sense for 14148 pairs.

I added a few traces to the file _k_e_r_n.py to better see what is going on (and to see that ttx identified a bug before desisting on decompiling). Here is a trace on calibri.ttf

Dumping "calibri.ttf" to "calibri.ttx"...
len(data)=84906
nTables=1, version=0
4 bytes consumed
Decompiling table 0
   Length=19366 (encoded with 2 bytes; note 19366+2**16= 84902)
   decompiling data[:19366]
   Version: 0, length: 19366, coverage: 1
   6 bytes consumed
   8 other bytes consumed for nPairs, searchRange and rangeShift
   nPairs=14148 (each is 6 bytes: 84888 bytes + 14 = 84902 bytes)
buggy kern table
Dumping 'kern' table...

The culprit is rather clear: a table length that is read as 2 bytes whereas the actual length is larger than 65535.

I get the same trouble with Cambria.ttf and Constantia.ttf

Michel

>>>Anyone want to see them all? :)

John, I was expecting to see all 26,706 kern pairs in the kern table when I opened it in a new metrics window but there are only 4,860 kern pairs and all this is for v5.62. Why doesn't it open all of them up like the other Microsoft ClearType fonts?

By the way Michel, you completely lost me after your second post!

Anyway.

Michel, you completely lost me after your second post!

Well, when I look with FontForge, it first tells me that there is a kern table but I also get the message that it will not read it because there is also a kern feature in GPOS. If I generate the corresponding afm file, I get 34863 kerning pairs (taken from GPOS).

To force FontForge to read the kern table, I remove the GPOS table from Calibri with "sfntedit -d GPOS Calibri.ttf" and generate again the afm file. This time I get the 14148 kerning pairs of the old style kern table plus a warning that the kern table does not comply with the specs.

The rest was simply to find more precisely the cheat, or the bug, or at least the reason why ttx would output only 3225 pairs with first glyph from A to Ograve.

Michel

EDIT: According to the spec, the subtable should be 19366 bytes long and there is just one. It starts with 14 bytes of info and then there is 6 bytes per kerning pair. (19366 - 14) / 6 = 3225. After that, ttx stops decompiling.

The basic issue is that the ancient kern table spec uses a USHORT for the 'length' field (for the length of the entire kern table including all subtables). Why it was specified this way is a complete mystery to me, since the length of the entire *table* is already given by the font's Table Directory (header). It's not even redundant, since the Table Directory length is a ULONG, allowing for a much larger table. But that's how it is.

So, for tools or other processes that make use of the length field, you can do the math with the table & subtable header lengths, etc. and figure out that the number of pairs in a format 0 subtable is theoretically limited by that field to a maximum of 10920 (which I'm sure the inventors thought would be more than enough at the time, but nowadays, not so much).

But, many tools and some operating systems ignore or at least don't choke on kern tables where the length field is not correct, and can calculate the actual length of a format 0 subtable by using 'nPairs' field.

Sorry, I must have mistyped; it is not 34863 but 34347 kerning pairs and I get the same number in a new metrics window if I open the file with my demo version of Fontlab studio 5.0.4 Mac

I've got FontLab Studio 5.0.4 and it still gives me just the 4,860 kern pairs. I'm guessing that what Michel and Joshua have written above explain it! Thanks.

To check, I would use the AFDKO command sfntedit in a command window; "sfntedit -d kern Calibri.ttf" removes the old style kern table from the file. You are left only with the GPOS kern feature; you then open with FontLab.

If you are on a Mac with AFDKO installed, in a terminal window and in the Calibri.ttf folder, copy and paste the line

spot -t GPOS=7 Calibri.ttf | grep ' pos ' | wc -l

I get 34347 after the carriage return. What do you get?

I just ran a test with FontLab. I removed the GPOS table and opened the resulting font with FontLab. It found 3225 kerning pairs, the same as ttx does. My guess is that the GPOS kern feature has been removed from the font and all the kerning pairs put in an old style kern table. On that table spot crashes, ttx and FontLab do not do their best to circumvent the hack. The only solution I see is to open the font with FontForge, generate anew the ttf, and open the resulting font with FontLab. You should then see all the kerning pairs.

Or take a look at the kern table in DTL's OTMaster (the Light version is free).

I can generate fonts with such huge old style overflowing kern tables with ttx, that won't decompile them afterwards, and look at them with DTL OTMaster Light, that will generate no font. Amusing.

Yes, that is quite funny, but I understood this discussion to be about the content of the shipping Calibri kern table and how to accurately view that content. Creating or editing such huge kern tables is a different matter.

If the aim is just to view accurately, DTL OTMaster Light does quite a good job.