Howdy, Stranger!
Categories
- All Categories
- 39 Introductions
- 3.6K Typeface Design
- 764 Font Technology
- 1K Technique and Theory
- 587 Type Business
- 435 Type Design Critiques
- 526 Type Design Software
- 30 Punchcutting
- 132 Lettering and Calligraphy
- 79 Technique and Theory
- 53 Lettering Critiques
- 461 Typography
- 289 History of Typography
- 111 Education
- 61 Resources
- 479 Announcements
- 74 Events
- 104 Job Postings
- 147 Type Releases
- 153 Miscellaneous News
- 259 About TypeDrawers
- 52 TypeDrawers Announcements
- 109 Suggestions and Bug Reports
Options
Reason for separating Latin and Cyrillic kerning groups?
Josh_F
Posts: 52
I remember reading somewhere that it is best not to combine kerning groups between Latin and other scripts like Cyrillic. Could anyone elaborate on this?
For example, in Latin, you might have a kerning pair for "C" to "o", and in Cyrillic, the Es looks like a Latin "C", and the Cyrillic "o" looks like a Latin "o", meaning it seems much easier to just place them in the group containing the formal Latin equivalent.
Without combining them, I then have to reference a bunch of Latin kerning pairs to build a similarly kerned Cyrillic alphabet.
Does that make sense?
For example, in Latin, you might have a kerning pair for "C" to "o", and in Cyrillic, the Es looks like a Latin "C", and the Cyrillic "o" looks like a Latin "o", meaning it seems much easier to just place them in the group containing the formal Latin equivalent.
Without combining them, I then have to reference a bunch of Latin kerning pairs to build a similarly kerned Cyrillic alphabet.
Does that make sense?
0
Comments
If there are quite a few classes that are only needed in one writing system or the other, then it can save space. In some cases, quite a bit. But it really varies by typeface and designer.
In cases where the kerning exceeds 64K in a single subtable, this is important to try as otherwise either kerning must be cut off or the font won't compile (the exact nature of failure depending on your font editor).
FontLab VI will check for and do such compile-time optimizations automatically behind the scenes; with other apps, there are scripts and tools for it.
As Thomas explains, there are production advantages to having them separate, in terms of subtabling if necessary when compiling.
Therefore, I generally start with them combined, and toward the end of my development process I split them out, if necessary. If your font editor or workflow can handle this on-the-fly at compilation time, so much the better.
I think the main thing to be aware of in such an approach is managing exception pairs.
-josh