Having been iterating on this font project awhile, I thought I’d mention some of the things I’ve noticed.

One of the big issues I’ve had on the few times I’ve tried to make typefaces is getting the weight right. I don’t know if there are solid rules, especially when some designs are meant to be thicker or thinner than usual. Given I’m trying to make a font to be used for text, rather than for display, a medium weight is best. But what the hell is that?

Looking at glyphs in FontForge can be deceiving. Your design needs to be thicker than you’d think (at least until your eyes adjust). While designing, you need the shapes to be big, to be able to work on them. You’re seeing them as they would be used for display. Display typefaces can get away with being thinner (or thicker) than text faces, because the eyes don’t have to work as hard to make out their features. But when you go to test or use the design as text, it looks quite different.

It’s still a tricky thing, and individual widths in a font will still require manual testing. I don’t know if there’s a good rule or way to decide on a number. The one I’m making uses roughly a tenth of the height as its standard width. Some of the fonts I’ve looked at seem to vary more than others, and I don’t know if the tenth is a good rule or not (for sans fonts; for serif fonts, there tends to be width variations on different strokes, so there are probably two or three widths that you’d need to balance between each other).

In order to test the weight (and other features) I went with LaTeX, which has a fontsmpl (font sample) package that helped a lot. I can make changes, generate the output font file, and re-render the PDF all with minimal effort (though I could write a shell script to make it even more minimal). That’s the second pain point: testing the font.

The main benefit of using a PDF to test is that I can guarantee the output is the current state of the generated font. Ideally I would do most of my testing in Firefox on the web. I do some of that, using a custom stylesheet I can toggle on and off, but Firefox does not reload the whole font every time it changes on disk. But it does, at some point, reload parts of it. So if you have Firefox open to a page using your font, and you change it, depending on how you change it, it may do some strange things with what it displays after some delay.

I believe it has to do with Firefox reloading the shape data of glyphs, but not refreshing the glyph tables (or the equivalent for however the font files work internally). So if you add or remove glyphs and regenerate, Firefox will (after some unknown delay) load some of the new data, and how it does that can result in some weird garbled mess, including wrong characters, inverted rendering (where the bowl’s counter (or white-space) is filled), other stuff I forgot or suppressed the memory of.

To counter that, I try only to test out on Firefox once, and if I regenerate I either stop testing with it or reload the browser first. (You could generate the font with another name, and switch which name the browser is using, but I haven’t wanted to do all that.)

The other risk with testing in the browser is that this here web is full of typos (particularly social media). Errant spaces are the worst. You think you have an overlooked kerning issue, only to find out someone put a space there. You have to be skeptical when testing on social sites like Twitter. It may not be the font, it may well be the tweet. But social media yields solid variety in testing. People put words in all caps, you get good coverage on numbers, symbols.

One of the biggest mistakes I made was trying to do some things too soon. It helped in learning, but it also caused (and continues to cause) a lot of reworking. Leaving kerning tables alone, not trying to make an italic version, small caps, a bold version, and not worrying too much about composite glyphs/accented glyphs would have made the initial font creation a lot less interesting but after going back to fix things a few times, I’m trying not to mess with them until the basic version is more finalized.

Kerning by classes is great, but it takes some trial and error to figure out good classes. Also, Fontforge may overkern certain pairs if you use the automatic kerning. I haven’t disabled it, but that does mean going back and check everything. (In general, FontForge has a lot of things it can do for you semi-automatically, after which you’ll need to double-check and clean up or improve its results. In my experience this is a bit clumsy, yielding a mix of excellent and baffling results.)

One of the things I eventually learned was that it’s much easier to check the box in Glyph info that lets you create overlapped shapes. This lets you focus more on getting individual strokes looking good than trying to figure out how the combination should work. But you have to turn that setting—”Mark for Unlink, Remove Overlap before Generating”—on for each glyph that uses it, plus for any that reference an overlapping glyph. Even then, how they overlap may need tweaking to avoid problems with overlapping hints. (The quickest way to enable the mentioned glyph setting seems to be to use the context menu when it pops up validation errors during font file generation.)

In some cases, like A, you might only have an overlapping bar with an inverted V shape. But for others, like X, it’s easier to build from a pair of slanted lines for the main strokes, than to get their crossing right using a single crossed shape. If you want to change the width or angle of the strokes that you’d write by overlapping, it’s much less trouble if they’re two separate shapes than if they’re part of a more complex single.

And speaking of X, use a lot of guides. One for the x-height (the height of lowercase x; the dotted line on those grade-school handwriting forms), another at what I call the curved x-height (for lowercase letters like a, b, c, etc. that have curved tops, they should be slightly higher than the x-height (known as overshoot)). Another guide for the curved-bottom, and a third for curved-top for capitals. (The top of the normal bounding area is already marked with a built-in guide.) There are probably more I should use, like marking the en-width and em-width off? Shrug.

Wikipedia: “Typeface anatomy” is a good place to learn some of the terms used to describe various parts of glyphs. Hovering over a glyph in FontForge provides some useful information, including the Unicode indexes for related characters (and in the case of composites, the ones that it comprises).

But there’s too much to know and a lot of it is down to taste. My current goal is for it to be good enough to (eventually) use it on this site. (That will probably require subsetting it out in a separate file in order to save size for all the accented characters and so on that would otherwise go unused. We’ll see.)