Figures to letters: no. But a few instances with 7 and, maybe, 2 ( . , ) … and always assure yourself that you don’t kern any tabular figures, how painful it may ever look
I do it with proportional figures, but not tabular. Not totally sure it's worth it, but it doesn't seem like that much trouble. I also kern proportional figures with each other and with punctuation.
Vasil, if your font allows combining the figures with existing letter kerning, as Craig suggests, the impact is extremely minimal (a few more glyphs in the initial lookup). Worst case scenario is a couple more look-ups.
Technically, this should not be a problem at all. Creating the kern pairs in the first place is a much bigger job.
It's tangential, but since I learned it only after the fact: Don't kern Latin figures with RTL scripts' letters (and vice versa). Since the kern pairs would span across scripts those features will never work in a font, even if your font editor might let you pursue such folly.
That’s the case of things now, Johannes. In addition to the scripts being processed in different glyph runs, the directional difference means kerning won't work across the bidi boundary.
However, there’s been a lot of talk about freeing up GPOS to process across the run boundaries used for GSUB, especially in the context of post-linebreak layout, in which a single direction could be presumed for an entire line of text. So at some future time there may be the option for cross-script and cross-direction kerning and other layout features.
Kerning pairs for Uppercase to superscripts are needed, and figures to superscript letters for ordinals. Note references use superscript figures after letters, and may also use superscript letters.
Hi Michael. That’s basically the approach I take, although I tend not to kern letters to numerals (because life is short, and the people who would care about such things are probably using software that allows them to manually kern). I create separate kerning lookups for each script, and a shared lookup for numerals-to-numerals.
At least, that is how I handled it in the Brill types. Some more recent projects use a unified source, in which all the kerning gets rolled into a single set of lookup subtables. I don’t like it, because it is inefficient at the text processing stage, but it is more convenient at the font tool stage.
Thanks for the answer, John, I think about performance too.
Why did I start thinking about it. I am currently working on a serif face (about 1500 glyphs including Small Caps) and some of the Small Caps characters borrow design elements from lowercase letters, in other words, the shape is close enough to be included in one class. I must say that serifs somewhat unify the shape of characters, and the amount of kerning is reduced. But for the same reason, the number of characters with a similar shape has increased.
As a result, the right-side class "A" was 69 glyphs, "vwy" — 70, and "bceop" — 198. Not sure if this is too large number for the class. Are there any restrictions and will it affect the rendering speed for the old computers?
OTL groups, including kerning classes, can be as big as you like, I think, and should not significantly affect processing speed. I just made some fonts with huge context groups, and they seem to behave fine.
and always assure yourself that you don’t kern any tabular figures, how painful it may ever look
Yes. And given that lining figures are far more popular than old style figures, and lining figures are generally also made monospaced to serve for tabular use, this does mean there are few occasions to safely kern letters to digits.
Not that it can't be done, or wouldn't be worthwhile, for some kinds of typefaces, such as a Jenson or an Aldine or a Garalde, where old style figures are the norm.
OTL groups, including kerning classes, can be
as big as you like, I think, and should not significantly affect
processing speed. I just made some fonts with huge context groups, and
they seem to behave fine.
On your computer. How many times do I read news items like "Computers with such-and-such peripheral no longer boot after latest Windows Update"... even Microsoft can't seem to test their updates against a sufficiently wide selection of the possible system configurations out there.
Not that I can realistically suggest a MIcrosoft-level testing regimen for every font publisher!
Comments
7A7JF4T4V4W4Y4.
However, there’s been a lot of talk about freeing up GPOS to process across the run boundaries used for GSUB, especially in the context of post-linebreak layout, in which a single direction could be presumed for an entire line of text. So at some future time there may be the option for cross-script and cross-direction kerning and other layout features.
Does this make any sense?
At least, that is how I handled it in the Brill types. Some more recent projects use a unified source, in which all the kerning gets rolled into a single set of lookup subtables. I don’t like it, because it is inefficient at the text processing stage, but it is more convenient at the font tool stage.
Why did I start thinking about it. I am currently working on a serif face (about 1500 glyphs including Small Caps) and some of the Small Caps characters borrow design elements from lowercase letters, in other words, the shape is close enough to be included in one class. I must say that serifs somewhat unify the shape of characters, and the amount of kerning is reduced. But for the same reason, the number of characters with a similar shape has increased.
As a result, the right-side class "A" was 69 glyphs, "vwy" — 70, and "bceop" — 198. Not sure if this is too large number for the class. Are there any restrictions and will it affect the rendering speed for the old computers?
On your computer. How many times do I read news items like "Computers with such-and-such peripheral no longer boot after latest Windows Update"... even Microsoft can't seem to test their updates against a sufficiently wide selection of the possible system configurations out there.