My real problem is that I don’t have a usable list of Cyrillic kern pairs so I don’t know what constitutes an appropriate pair in real use.
That depends on the range of Cyrillic you are covering. There are indeed some combinations that never occur (either phonetically impossible or each letter belongs to different languages), but I’d say it’s safer and faster to kern everything than to do research and avoid unnecessary ones. And don’t forget to kern against punctuations too, such as «…» „…“ which are used for quotation in Russian and other countries.
1 Like
Thanks, Tosche and Jakob; that’s good information, probably exactly what I need – especially the links.
Maybe it would be a good feature to have a Glyphs kern pair file which could be enabled to display kern pairs automatically so the kerning could be set simply by selecting any pair and making the visual adjustment as is done now by typing or pasting.
It would only display a list of kern pairs where both glyphs of a pair exist in the font.
It would work in the same manner the GlyphData.xml file currently does, with a user file overriding the furnished file.
Such a feature would be useful to users worldwide who need kerning help with an unfamiliar language. It would save time in that the user wouldn’t have to set useless kerns because of that unfamiliarity.
I was about to suggest the Cyrillic version of the testing page, but Jakob beat me 
George,
I think sample string is just what you want, isn’t it? I customise it quite a lot for kerning all kinds of scripts. Another thing is that the pairs you need to kern differ greatly from one design to another, so such an internal library would end up listing all possible pairs. The most economical way would be that a user builds pair lists for each project, which is what I do in sample string, or in Pair List Builder in Metrics Machine (Metrics Machine is a dedicated kerning app, yet it doesn’t have such list; it assumes you build it each time, which is quite understandable).
At least there are pairs made of letters that belong to different languages (e.g. ЂҠ is a pair of Serbian and Bashkir letters, so it never happens, as of today, in theory). This level of pair elimination may be reasonable. But even if you think kerning between Latin and Cyrillic letters are totally useless, there are languages which mix them (e.g. Wakhi), which are mind-blowing.
Tosche:
Sometimes, but not always. In my experience, kern pairs work just fine. I always plan my basic spacing before I ever start a font and any kerning done at the end is just fine-tuning individual cases. Typically I use Kerning Groups for efficiency, and my Cyrillic characters are included, but there are always exceptions. That is correct since it is the Master List. However, it would only display in Glyphs those characters which actually exist in the current font. Exactly, and that is what I am proposing with my idea; we may just be stating it differently. I understand that such things do occur, but those combinations can adequately be covered by using Kerning Groups, I think. It all depends upon the font and the language, really.
You can put glyphs from different scripts in the same kerning group, but it is not advisable; it uses up more processing resource than kerning groups separated into each script.
I mean, all possible pairs of all existing glyphs, which is astronomically many.
I don't think so. I'm saying that it just makes sense that each builds sample strings every time. I make Cyrillic fonts many times (for both retail and custom) and their character coverage and design vary greatly. Maybe Glyphs can add basic A-Я and
Thanks for that info; I will change my font. It's easy enough to do.
To me, "astronomically" implies perhaps over 100,000 kern pairs. Such a number might apply to a Chinese script but I doubt one could apply the word to most other scripts. If basic character spacing is pre-planned then an enormous number of kern pairs is not necessary unless it is a font that has really special needs such as an unusual display face.
I wasn’t asking for a comprehensive kern pair list covering all scripts, only Cyrillic.
I agree, and I certainly wouldn't ask Georg to devote his resources to such an enormous task just to benefit a small group of users. But if he could enable users to provide their own lists, that is something he might conceivably be able to do.
Glyphs breaks the kerning groups by script. So if you add the A-cy to the A class, you will end up with two classes in the font and the kerning attached to both. So you are save to save time on this one.
You can add your own strings in the Preferences.
Thanks Georg. I had looked everywhere but there. I believe that will work for my needs.
Actually I tried it before but it was probably not working (e.g. Latin-Cyrillic pairs still kerned). Are you sure it works?
I’m sorry, I did not remembered is correctly. It only splits if it has to flatten kerning (because of exemptions).
But I use the same classes for all scripts, anyway.
Does anyone know for sure if it is a problem or what are the potential problems with cross script classes?
Because of the way I build fonts, I can’t see that it would be much of a problem for me or my users other than having kerning pairs in a font that may never occur in use. So far as those extra kern pairs causing excessive processing time, I would like to see a benchmark test of that before I felt it is a problem.
Frank Grießhammer. He did a talk on exactly this topic at ATypI Amsterdam.
My understanding is this. There are four groups of pairs if you kern between Latin and Cyrillic:
- Lat-Lat
- Lat-Cyr
- Cyr-Lat
- Cyr-Cyr
Typically the groups 2 and 3 are never accessed, yet the font renderer actively looks at them even if there is no pair occurring in the current text. It gets even worse when you add Greek to this.
1 Like
I am just about to start kerning a Latin-Cyrillic-Greek font and I am terrified about the idea of having 9 groups of pairs!!! Does anyone know whether Glyphs finally manages to break the kerning groups by script, thus avoiding this subsequent processing issue?
When I tested this, splitting the classes by script automatically produced bigger GPOS tables. And if you keep the number of pairs at a sane number you should be save. All my fonts are done like this and I never had any problem.
2 Likes
Thanks for the info, Georg.