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?
0
Comments
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?
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).
because it slows down rendering, and milliseconds are dollars
I'm just noting that... they don’t.
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."
...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.
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.
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.
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.
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).
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.
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