The final build

Last time, I wrote about how software developers might add a first, confidence-building test to their project. 

How might a type designer do the same sort of thing, increase their confidence in their font software quality through one change?

I don’t have a definitive answer, but I do have a few ideas. You could start by:

• Scripting a tiny piece of your test sheet
• Running a single script on your output fonts
• Building on the the work of others, through projects like Drawbot, or even Font Bakery (which has been tackling the ideas I’ve been writing about in the past few messages for a while—I plan to write more about that in the future)

All of these are pretty code-forward, but even having, say, an InDesign template you maintain and use for each project for test sheets, or ensuring you write a README to your future self, are great starting points.

Why is it relevant that type designers—particularly small foundries and independent designers—think about this at all?

Actively used typeface projects are more likely than actively used software projects to have unchanged source files, or even be considered “done,” for a very long spell of time.

Until, years later, you have a client or customer request to add a single glyph, and need to create a new build or export of the fonts.

That won’t happen on literally every project, it’s true. There will be a last time you build output files, and the source files will never be touched again.

Do you know which projects those are going to be, in advance? I don’t.

When the project is fresh and actively being worked on, putting extra effort into making the files easy to rebuild, run the tests, output test sheets—whatever intervention point you choose—is a worthwhile addition to your type design practice. That time investment won’t pay off one-to-one for every project, but it does tend to pay off in aggregate.

Until next time,
Kenneth