I am very excited to be getting my visa for India today! I’m one of the instructors for a 3-day advanced type design workshop with FontLab. Registration is now open on the FontLab blog, and there is a detailed schedule of planned talks.
One problem with releasing lots of pre-release builds to my Kickstarter backers is that I don’t test every single one as much as I otherwise would. Generally any errors are minor, but earlier today I managed a moderately important one: I didn’t remove overlapping paths in my outlines during the build process. Well, actually, I did remove overlap, but as I did not first decompose my composite glyphs, it didn’t fix most of the problem cases.
Why would you want to have overlapping paths in your glyph outlines, and why/when would it be a problem?
Here are several glyphs (as shown by H. James Lucas) that had overlapping paths in this last build:
So, clearly it’s a problem if they render badly in some apps. Interestingly, this is dependent on not only what is doing the font rendering, but also what size the glyphs are rendered at. Adobe’s core rendering engine has three or four different rendering modes, and what it picks is size-dependent.
Overlapping paths are sort of okay in TrueType fonts—the rendering engines will deal with them better. But they will still produce bad results if a user does something like apply an outline or stroke to the text.
So why do I leave these things in while developing the font? Well, during development, it is useful to keep the basic elements separate, and only remove overlap later on. So for example, if I change the underlying swash H glyph, I want the Swash-H-with-bar to automatically pick that up. Similarly, the C shape seen in the colon currency symbol (used in Costa Rica and El Salvador) is shared between the Ghanaian cedi, the euro symbol, and a stylistic variant of the cap C. I used the same primitive elements in the ffj ligature in numerous other ligatures (including ffi). And so on.
Of course, as leaving overlaps in the final font causes problems, normally I take care of this as part of each build. My usual build sequence for creating OpenType OTF fonts from my FontLab file:
- Make sure version string has been correctly incremented (in several places)
- Remove all hinting (shift-F7 in FontLab Studio 5 for Mac)
- Select all glyphs in font (Cmd-A in FLS)
- Autohint all glyphs (F7 in FLS)
- Save file
- Following actions must be done without saving the file again, to preserve original data in the FontLab file:
- Decompose all composite glyphs
- Remove overlap (Cmd-F10 in FLS)
- Export OTF (Cmd-Opt-G in FLS)
- Change license URL to point at the personal license
- Export OTF again with “-NC” (non-commercial) in the file name
- Close font without saving file
Anyhow, in this particular build I missed the “decompose” step, so all overlaps involving composite glyphs (most of them) were still overlapping. Of course I have fixed this, and am sending revised fonts to my backers.
Adding kerning is one of the very most tedious tasks in developing a font, if it is done well. It is also the final major production task in type design.
As I am finishing this stage on the Regular style of my Kickstarter typeface Cristoforo, and about to send updated fonts to my backers, I find myself needing to explain what this kerning business is, anyway. So I thought I would post something here for general public consumption, and point to it from my latest Kickstarter update.
In fonts, each glyph is placed in a slot with a certain amount of space allocated to it, which generally includes white space on either side. The total horizontal space allocated to a glyph is its “advance width.” The distances between the furthest extent of each side of the glyph and the ends of the allocated space are the “sidebearings”—which can even be negative numbers, if part of a glyph sticks into a neighboring space.
In high-end type design, spacing is an especially complex art and craft. But many junk fonts don’t even get the basics right, and that is easily detected. Decent spacing is consistent, and follows certain general principles about shapes. Consistency means the “same” elements should get the same space across different glyphs, and similar elements spaced similarly. So the left sidebearings of OCGQ and the right sidebearing of D are all usually either the same or very close.
Designing even spacing is about keeping a relatively consistent amount of white space between letters. In a typical sans serif font, a letter like O only needs 50–60% as much in the way of sidebearings as an H. Something like a T or a V might have sidebearings at or close to zero. Lowercase letters are generally spaced slightly closer than their cap brethren.
The word “kerning” can refer to any of three things:
- noun: data in a font that adjusts spacing for particular letter combinations.
- verb: the act of creating such data
- verb: when setting text, the act of adjusting space between particular letters in text. This is an operation done by a typesetter in text setting software, and is not a font editing operation. Also, not to be confused with tracking, which is adjusting the overall spacing of a block or range of text all at once.
For purposes of this article, I’m concerned with the first two definitions: kerning data built into fonts, and how to create that data data. We’ll get to the “how” later, first let’s talk about the “what.”
It’s critical that the basic spacing be done well in any font, but for particularly difficult combinations, the font should also contain built-in kerning (which can help avoid the need for the end user to do manual kerning). Kerning is a set of adjustments to the default spacing for specific troublesome letter combinations, so as to deal with fact that, without intervention, “AV” will be set too far apart, or that in some fonts “f)” will make the top terminal of the f collide with the parenthesis. Vast amounts of kerning are not always a necessity for a well-made font, but if there is no kerning, or if it does not deal with common situations like “LT” and “To”. . . then there is something wrong.
In the “old days” prior to about 10–15 years ago, kerning was done by defining pairs and adjusting the spacing. So combinations such as To and Te would be separate pairs, as would VA and WA. This was a pain, but still manageable as long as fonts still only have <256 glyphs per font, although some would end up with thousands of kerning pairs, and some apps would break (in different and interesting ways) when working with very large amounts of kerning data.
But it is not unusual for an OpenType font to have a thousand glyphs or more. Cristoforo Regular has 1324 glyphs now. Luckily, OpenType allows for “class kerning,” in which glyphs can be grouped into classes, and then the classes are kerned instead of individual glyphs.
So the first thing to do is to define those kerning classes! I spent days on and off just doing that for Cristoforo Regular. Some of them only apply when the class is on the left, some when the class is on the right, and a few apply to either side. I had 96 kerning classes before I started kerning. I made a few additions and deletions during the process, and am sitting with 101 right now, with 632 distinct adjustments between classes (the class equivalent of “kern pairs”). Probably a week or more of work, if it was full time.
Here’s the display of classes in FontLab Studio 5.1.4. Most of my classes for Cristoforo have anywhere from 4–30 glyphs, but some have just one or two, and the largest has 84.
Getting the class definitions right is critical. If a glyph is missed out, it doesn’t get kerned. If a glyph appears in two left-side or two right-side classes, it causes an error that means that a bunch of the kerning will never be applied when the font is used. (FontLab Studio warns appropriately, but debugging can take a while.)
Here is how the spacing can be viewed with arbitrary strings of text in the metrics window. At the moment the effect of kerning is not being shown.
Below you can see the same text only with kerning applied.
The next version, below, highlights the points where kerning is happening. Mostly kerning makes the combinations closer together, except the “e.” combination, where the period has to be moved a smidge further away.
Most graphics and publishing apps simply use the kerning data in the font by default. You have to do something special to avoid it or get different results. This is true of Photoshop, InDesign, Illustrator, and QuarkXPress.
The Adobe apps refer to the kerning built into the font as “Metrics” kerning, as opposed to no kerning or Adobe’s automatic “Optical” kerning. In a well-made font Metrics kerning produces the best results, but even then Optical kerning can be handy for combinations the type designer missed, or situations that can’t be handled by kerning built into the font (such as kerning between different font sizes or two entirely distinct fonts).
Even WordPerfect, back around 1990, had kerning on by default, if I remember correctly. But not Microsoft Office.
Microsoft Word has allowed you to turn on kerning pretty much forever, it just defaults to being off. To turn it on, in recent versions, go to Format > Font or hit Ctrl-D (Cmd-D on Mac). You’ll get a big dialog. Select the “Advanced” tab.
Then in the top “Character Spacing” section, check the box that says “Kerning for Fonts.” The default is to set kerning on for 12 point and above, but you can reduce it—I generally set it to 1 point because I want kerning on all the time. Unless I am writing an article about kerning I never want it off.
PowerPoint has more recently started supporting kerning. In more recent versions, go to Format > Font or hit Ctrl-T (Cmd-T on Mac). In the resulting dialog select the “Character Spacing” tab. Then check the “Kerning for fonts” option.
So that’s all you need to know to use and appreciate kerning!
NOTE: About 1/4 of the text of this post is borrowed from my article “Know If a font Sucks,” currently in press for the March–April issue of Communication Arts.
I had so much fun doing this in Portland, that I am again joining Dave Crossland (pending sufficient registrations) to teach a 2-day intro type design workshop in New York City at Columbia University’s School of Journalism, July 20–21.
We have essentially a loose anarcho-syndicalist collective, organized by Dave under the “Crafting Type” banner. Doing this in a tag-team format turns out to be amazingly effective and fun. Dave comes from a very different perspective than I do in some respects, but we share our love of type and type design. Students really benefit from a variety of viewpoints and expertise.
The Singapore Crafting Type workshop is July 17–19, being taught by Eben Sorkin and Octavio Pardo. They too are knowledgeable instructors with varying perspectives, and it should be a great opportunity!
Here again is some of my own work:
Hypatia Sans poster on Adobe’s site, click for high-res PDF.
I am joining Dave Crossland and other type designers (depending on registration levels) to teach a 3-day intro type design workshop here in Portland at the Pacific Northwest College of Art (PNCA). I am really looking forward to this, even if I don’t know that I can live up to the hype from the initial teaser post about it. But I love type, and I have spent a lot of time thinking about how to teach the basics of type design. I am looking forward to helping do that in a workshop environment, and doing so with other instructors so we can divide up the material, and even dynamically discuss things in front of the class. Dave comes from a very different perspective than I do in some respects, but we share our love of type and type design.
Thanks to Paul Platosh at PNCA for helping make this happen!
Here is some of my own work:
Hypatia Sans poster on Adobe’s site, click for high-res PDF.
For a long time I thought of the PANOSE numbers in fonts as only used for things like font matching, without any practical impact in most day-to-day use of fonts. I am reminded this week of how dangerously wrong that belief is.
For those who are unfamiliar with it, the PANOSE number of a font is a chunk of metadata that describes the font with a sequence of digits, an encapsulated description. Here’s the PANOSE section in FontLab Studio’s Font Info pane.
This week, for the second time in the past 15 years, I discovered a WIndows font bug caused by improper PANOSE numbers in fonts, which I had never heard of before.
The first bug was simple: if you set the appropriate PANOSE digit to say the font is monospaced, Windows will ignore the actual advance widths in the font and treat every glyph as having the same advance width. This means that you had better not set the PANOSE to monospaced unless the font is utterly and completely monospaced. This may seem simple, but consider that some supposedly-monospaced fonts still have ligatures. If, say, the fi ligature is to have a different width than the i by itself, then the font is not truly monospaced and setting the PANOSE to monospaced will mess up that glyph’s advance width (at least, in many Windows applications, though not most Adobe apps).
If my understanding is correct, the new bug is also simple: if you have a style-linked family such as a regular and an italic, the general PANOSE class had better be the same for every family member, or else Windows will get very confused. In my case, the regular was of the “Latin Decorative” class and the very early build of the italic was “Latin Text” (because I hadn’t bothered developing the PANOSE number yet for the italic). Some very odd symptoms occurred for a user with an existing document in Word 2010 on Windows 7.
This is also a lesson in font testing. Even something as simple as coordinating family members for Windows, a mostly well-understood area, and one in which I have considerable expertise, can fail for unknown reasons. There is no substitute for actual testing in apps: this issue was not identified by Adobe’s fabulous CompareFamily test tool, probably because they had never encountered it. I had used the italic by itself in Word on Windows, and both the fonts together in Creative Suite apps, and all was well. That was simply insufficient.
Definitely a major error on my part. Certainly, this was not a final release, but even a pre-alpha build released to my Kickstarter backers, as the new italic was, should behave more reliably than this one did.
Some screen shots and info on the font production process posted as an update on my Kickstarter page, including some thoughts on why ATF called it “American Italic” instead of “Columbus Italic,” the transition to standard type alignment around 1900, and illustrating good vs bad curves.
Wow, it has just been a crazy time lately. I wrote most of this yesterday at 36,000 feet, on my way home from a quick tour of Europe for work: Barcelona, Paris, Hamburg and Munich. This included numerous customer meetings and three speaking engagements:
- Typo Week in Barcelona: I talked about some of my Font Detective work
- WebVisions Barcelona: CSS 3 OpenType support, the new web typography frontier
- Typographische Gesellschaft München (Munich): Fonts for eBooks
Now I have a break for a couple of weeks before my next conference, TypeCon in Milwaukee (Aug 1–5), where I’ll host a panel to talk about Kickstarter as a means of funding new type design. I’ll also be doing a talk on the same subject at ATypI in Hong Kong (October 11-15).
In the meantime, I have been hard at work in my off-hours on my Kickstarter-backed typeface, Cristoforo, with help from my fabulous intern, Andrea Harrison. The full details are available to my backers in an update on Kickstarter, but for public consumption, I’ll just say that work continues on the upright face, and has started on the italic, and I am predictably enough wishing that I hadn’t promised to add so much language coverage (central European, Greek, Cyrillic). But it’s coming along, and the extended language support offers some greater design challenges than just digitizing an old typeface.
My day job has kept me pretty busy, and has presented me with some one-sided decisions. Gee, I have exactly one day free in Paris: work on Cristoforo, or visit the Louvre? Okay, so I’m probably not going to collect a lot of sympathy votes here. But after spending less than 48 hours in each of Paris, Hamburg and Munich, then flying back to Portland, I am pretty beat.
Finally, I need to thank my backers for Cristoforo! Without them I would not have tackled the typeface, or would have done something much less ambitious and done it more slowly. Here is the backer listing (and yes, some of these are pseudonyms, it’s whatever they use on Kickstarter).
As I’ve been posting about lately, Cristoforo is a family of three fonts I am developing, reviving Columbus & Columbus Initials (Ihlenberg, 1892) and American Italic and American Italic Initials (Ihlenberg, 1902) as well as adding a symbol font. I am the lead designer, with the assistance of my new intern, Andrea Harrison.
I funded the development of Cristoforo through a Kickstarter campaign, which raised over $10,000 from backers. Woot!
Current ETA on finished fonts? February 2013. However, limited pre-release versions will be available to appropriate levels of backers starting in mid-July.
Here are my awesome backers, in tiers by their level of support.
Great Old Ones
Philip M. Payes
M Sean Molley
Juris L. Purins
H James Lucas
Sarah E Canzoneri
Alexander Y. Hawson, M.D.
Damon Loren Baker
Battlefield Press, Inc.
Fred Hicks / Evil Hat Productions
Derek M. Koch
Mark L Pappin
Galahad de Corbenic
David Occhino Design
Robert “Rev. Bob” Hood
Hans de Wolf
Stacey Van Keuren
Rt Andrez Mora
Elliott C. Bäck
Adam Hunter Peck
THomas W. Holt Jr.
Juan M. Escribano
Wayne A Arthurton
H. James Lucas
With about 48 hours to go (midnight Sunday PDT), my Cristoforo font project on Kickstarter is at about $9,300 in pledges from backers who want to get cool fonts and other swag. As $10,000 is my final “stretch” goal (the point at which I add Cyrillic support to the fonts), I was trying to decide how to both celebrate and encourage the last few pledges I need. I settled on releasing a free font that might be of interest to some H.P. Lovecraft / Cthulhu fans: Dark Symbols icons designed by Brennen Reece and Graham Walmsley, fontified by me, released at no charge under the Open Font License 1.1.
Download Dark Symbols font (Zip archive of .otf).
What are the Dark Symbols? Graham explains them on his blog, but basically these are rough-edged hand-drawn symbols, intended for folks to mark up Cthulhu-related role-playing adventures.
I may also incorporate the Dark Symbols in my Cristoforo Symbols font; that’s TBD. But in any case, enjoy this free font, and consider supporting Cristoforo in its waning hours on Kickstarter!