number of kerning pairs vs. performance

Miles Newlyn

I have a design that includes Latin, Greek and Cyrillic. There are 6000+ kerning pairs.
I'd like to know what people think about this number. Is it too high? Half of the font file data will be kerning, adding 30-40kb per file = a problem with web font file size?

Robin Mientjes

That is a high number of kerning pairs, but if you’re worried about web fonts, an idea might be to subset the different writing systems.

Miles Newlyn

forgot to mentions that there are small caps for each script too.

If i expand the kerning, there are 69,000+ pairs. Am I right in thinking that 6000 class pairs in the OT Kern feature is less of an issue?

Thomas Phinney

No, it's not less of an issue.

That said, many web font processing systems will by default omit the kerning entirely, and kerning is off by default in browsers (because like MS Word, they know better than font standards how to process font data, it seems).

Dave Crossland

off by default in browsers (because like MS Word, they know better than font standards how to process font data, it seems).

because it slows down rendering, and milliseconds are dollars

Deleted Account

Thomas, I recall talking to MS folks about this, and with kerning on, there was a tiny time difference over a large document of small type. That was 15 years ago for print, a print operation that would then take 12,000,123,345.56 times longer to complete than the display time of the kerned pages. It's pretty funny, actually. Perhaps Dave is right about time for some huge corner of the web. But testing the 'kerning slowdown' for good type in small web ads, might indicate to the inquisitive that we are not in Word anymore. There is also a balance between the typographic authenticity of a composition, for a specific company, and these dollar thingies, where money becomes well spent in font development to avoid using the defaults. In anything beyond the defaults, without embedding, is it not a whole 'nother speed already being implied, Dave? So good letter spacing might just be important enough, to make kerning a good long term commitment, by a company, to its type design. Then perhaps instead of writing off all the great Latin text composition of all time, as too slow for modern computing, , why not, perhaps, encourage people to make the best fonts possible, and perhaps investigate, fund and implement, and githubbify kerning subsetting, like, by Friday, it's like that easy dude.

Thomas Phinney

Hey David, I’m with you. Office apps and browsers should support kerning, AND have it on by frickin' default. It's not rocket science, and it's not a major performance drag.

I'm just noting that... they don’t.  

Dave Crossland

investigate, fund and implement, and githubbify kerning subsetting

That part is already done, boss.

Back to Miles' topic  

The context for his initial post is http://forum.glyphsapp.com/t/too-many-kerning-pairs/2037 

A friend wrote me, "Counting kerning pairs, be it glyph-to-glyph or class-to-class, in AFDKO syntax leads nowhere. What matters is the GPOS table's PairPos Format 2 subtables that will be generated from the AFDKO syntax kern feature. And given the structure of the PPF2 subtable, it may happen that less kerning in AFDKO syntax ends up as more data after conversion to PPF2 subtable(s), and conversely. So this discussion here is a bit besides the point."

Deleted Account

I'm agreeing with your agreement, Thomas, good points.

...it is simply funny, some of the unicorn gas. Fonts, as they become 'free commodities' cost nothing, except in the downloading and rendering. Cool!

Avoid 'the cost' of downloading by using defaults, avoid 'the cost' of rendering by using the default size of default fonts, and at default sizes of the default fonts, avoid kerning. This leaves one looking at, things like Google ads, and the rest of web content in 1999.

Click on such a google ad by a company wanting free, and you often get to site full of type converted to graphics, slow down, while, it may, take, some time, to, load... like 1999.

It seems so like a tweested repeat of the logic that had kerning turned off in Word. "Do not wait here, wait over there."

I'm glad we had this very useful conversation, thanks.

Miles Newlyn

A friend wrote me, "Counting kerning pairs, be it glyph-to-glyph or class-to-class, in AFDKO syntax leads nowhere. What matters is the GPOS table's PairPos Format 2 subtables that will be generated from the AFDKO syntax kern feature. And given the structure of the PPF2 subtable, it may happen that less kerning in AFDKO syntax ends up as more data after conversion to PPF2 subtable(s), and conversely.

that's precisely the point Dave. I've learnt that the parameter "number of kerning pairs" in itself means nothing. In fact a font of 6402 pairs but produced with a well made 'kern' feature gets less font size than a font of 4424 pairs but produced by a badly made 'kern' feature.

Kent Lew

I've learnt that the parameter "number of kerning pairs" in itself means nothing.

To add further anecdotal evidence to this point —

Not that long ago I had to troubleshoot some fonts that were not compiling due to dreaded “kern overflow” errors, even with a subtabling routine applied.

After some analysis, optimization, and restructuring of the kerning data, I was able to resolve the issues and get the fonts to compile.

What is counterintuitive is that the sources that would not compile had fewer pairs than those that did. For example, one source with 6458 pairs and 185 groups would *not* compile; but that same source with 8300 pairs and 268 groups compiles just fine.

That particular issue was more about compiling, not overall file size; but there’s obviously a relationship.

The key is often the class-kerning exceptions and their subsequent enumeration. The structure of the kerning data can be as important as (or even more than) the overall quantity of that data.

Ben Kiel

The key is often the class-kerning exceptions and their subsequent enumeration.

This. You can have a lot of kerning with GPOS kerning, but be very careful if you have large numbers of glyphs in groups that have class kerning exceptions, this can blow things up very quickly.

Khaled Hosny

and kerning is off by default in browsers

I assume you mean some browsers, because Firefox had kerning on (and other in by default features) for a long time now, and I’m pretty sure Safari does so as well. I don’t know about IE, but Chrome on the other hand disables all OpenType features for scripts is deems simple (specifically they have a dumb fast code path for such scripts which skips OpenType layout, but they are working on eliminating it), but even in Chrome turning on any feature (using CSS font-feature-settings) has the side effect of enabling all default features (because it switches to the complex code path).

Adam Twardoch

The only thing these days which does have some influence on performance is the number of lookups in the font. This is understandable: for a given combination of enabled features, on each glyph, all associated lookups get executed — one after another. So the more lookups need to be executed, the more "loops" happen on every single glyph. Multiple lookups are typically used in the `calt` feature (contextual alternates).

There, it may have some semi-visible impact on rendering whether your `calt` feature uses 2-3 lookups or 15. But the number of kerning pairs does not have influence because finding the matching kerning pair within a 1000 pairs or within 60,000 pairs takes pretty much the same time. 

Thomas Phinney

Khaled: Thanks for that! It seems my information may be dated.

Until recently, Firefox by default only turned kerning on for text at 20+ px. However, it seems that perhaps last December in Firefox 34 they may have started supporting kerning by default.

I'll have to do more research on the others, but it may be that their status has changed recently as well. With IE, of course there are a lot of much older versions in use out there, although that problem has been getting better over time.

T