Font version changes

Cory Maylett

I'm assuming it boils down to judgment calls, but I'm wondering about generally acceptable changes that can be made between font version updates.

It seems clear that obvious glitches should be fixed, like a mysterious control point that somehow ended up a ways away from where it should be. I'm also assuming that additions to the font would be fine, like adding a lesser-used Cyrillic character or a locl variant at a customer's request.

What I'm much less certain about are aesthetic changes. How about adjusting the curve in a zeta because it doesn't look quite right or making a slash a little thinner or thicker? Or even something more substantial, like altering a glyph in a way that affects its width metrics or going so far as changing the look of an ampersand?

As a graphic designer and user of type myself, I'd obviously be fine with bug fixes and additions, but if, say, a slightly widened O in a new version of a font caused a series of cascading line shifts in a magazine layout I was working on, I'd be less than pleased with the change.

Anyway, does anyone have any general guidelines or thoughts on this? I have a font family with around 6,000 glyphs that I'm close to finishing up, and I swear that as soon as I upload it to the distributors, I'll see an endless string of adjustments that I wish I would have made. At what point do you call it good enough, and what kind of flexibility is generally acceptable for making fixes, tweaks and changes between versions?

Chris Lozos

That is the eternal question we all struggle with.  Actually you can make updates as you wish as long as the metrics don't change.  If the metrics change, then customers get reflow issues with legacy work in the same font.  If you must make metrics changes, you might think about updating the name [adding "new" or some other identifier] so users can have version control over existing work.

The frustration with never being finished is quite common.  The longer you are at it, the more efficient you become at working and at seeing problems early on.  It can be quite unsettling to look at work you thought looked good a few weeks ago.

Ray Larabie

All software gets updated and I think customers are used to the idea. If my update causes considerable reflow or the vertical metrics have changed, it gets a integer increment (2.000, 3.000). If it doesn't affect reflow significantly, it gets a 0.1 update (1.100, 1.200). Bug fixes or a minor changes such as an additional currency symbols get a 0.001 update (1.001, 1.002). Some of my fonts are already past version 6.000. Most font distributors won't inform customers that a new version is available. MyFonts does but I think they're the only one. Maybe someday the OS will let people know that a newer version is available.

Thomas Phinney

This issue can be one of the toughest calls out there in the font business, IMO. While there are some easy calls, there are also plenty of gray-area cases where there is no right answer, just a question of which customer unhappiness you would rather deal with.   

I led an internal discussion around this at Adobe back in the mid-2000s. It was not an easy decision to go ahead and rename some of our future fonts adding numbers into the names. But if you add “New” or some such to the family name, what do you do the next time you revise the typeface?

I agree with Chris L that as long as metrics are unchanged (and I would add, that there are no major design changes), you can and should leave the name unchanged. Minor bug fixes that do not impact metrics are fine.

Why not change names?

A name change inconveniences existing users who move to the new version and need to update documents, or who have to deal with different versions floating around between different users, sites, whatever.

Minor aesthetic tweaks in one or two glyphs may irk a designer or two, but won't usually cause anything disastrous. So that's usually relatively safe.

Why not keep names?

On the other hand, reflow and differences in character support with same-named fonts can be a large or even devastating issue for pro publishers and the like, reprinting existing documents. Whether they suddenly get reflow or characters go away because somebody had a new version of the font and somebody else had an old version, it can be an insanely expensive mistake if not caught (and highly frustrating even when discovered). PDF as an archive format probably helps in this regard, but only somewhat.

So, if long documents and/or pro publishing are a noticeable part of your customer base, it is reasonable to rename fonts when sufficiently large changes occur. That's why Adobe decided to rename their new version of Trajan back when they added Greek and Cyrillic support as well as more weights. Although admittedly, for a display face such as Trajan people are more likely to spot missing characters or major reflow issues.

Nick Shinn

I am gravitating towards re-naming the file (suffix: -Pro), but not how it appears in font menus. 

Jack Jennings

Does anyone just append the version number to the font name? Would there be creeping compatibility issues with something like that?

I'm imagining something like "Some Grotesque (1.0.1)", "Some Grotesque (1.2.0)", etc.

If that would work, you'd trade "Automatic Updates" (your client could install the new font file and have a all of their documents updated without manually changing), but on the other hand you'd insulate yourself completely from reflow issues.

If fonts are software, why not treat them like any other software library dependency and just have the user lock in a certain version number?

Mark Simonson

I change the name usually only when the metrics change significantly. In the case of Proxima Sans, which became Proxima Nova, the weight scheme and naming also changed. In a few cases, I changed the name when the character set changed significantly, even if the metrics had not (Changeling to Changeling Neo, Refrigerator to Refrigerator Deluxe, Mostra to Mostra Nuova). For minor tweaks and additional language support, I leave it alone.

FWIW, I think appending the version number to the name is not a great idea. You will force your users to change all their documents every time you issue an update. Otherwise they will need every version they've ever used installed. Seems like it would be more annoying than helpful.

Dave Crossland

Sadly the www.semver.org version numbering doesn't fit fonts well, because OpenType only allows for A.B not A.B.C style numbering in its version number fields. Using A.BCCC might be a reasonable compromise

Jack Jennings

I get that updating automatically seems like a convenience but it's a double-edged sword. With no version number at all your user has to be extremely vigilant when updating any typeface, since they're unaware of what reflow or stylistic issues this may cause. If you're dealing with any significant number of historical/legacy files, the trouble of potentially wrecking havoc by updating fonts just means that the fonts will never be updated.

In the software world there are two ways that managing dependencies works: either you lock in a version number for the software you want, or you bundle the dependency directly with your software.

In a hypothetical type workflow that would mean either each version of the typeface has it's own version number, or the desktop publishing software would read the font files that are either embedded or in a "package" folder (like what InDesign can export).

Nick Shinn

Wreaking havoc. I’m guessing this is related to “wrought”. Hope I spelled it right.

Nick Shinn

My current best practice is to keep the menu names the same, but change the file names to Fubar Nova, if there are design and metric changes, or Fubar Pro, if the changes are just language or feature additions.

Jack Jennings

Nick Shinn said:

Wreaking havoc. I’m guessing this is related to “wrought”. Hope I spelled it right.

Yep. Slippery fingers + autocorrect + no proofreading

Kent Lew

I don't feel that keeping menu names but changing file names is necessarily sufficient help to the user. The app will not signal that the font has changed, and that can result in reflow or missing features without any warning.

The hypothetical example that I used when arguing to adjust the menu names for Font Bureau’s major OT update of Benton Sans was this:

Suppose that Corporate Client hires Design Firm to create some important marketing materials. Corporate Client specifies that their brand font is Fubar. Design Firm goes and licenses the latest version of Fubar which has small caps and oldstyle figures, etc. Design Firm designs brilliant materials utilizing these Fubar bells and whistles. Design Firm delivers materials to Corporate Client’s in-house designers to finalize and produce.

Corporate Client uses the design materials to launch major campaign. But the bells and whistles are missing from the final produced pieces. Corporate Client is unhappy.

What happened? Corporate Client only had the original Fubar family. When they opened the files, there was no warning that anything was missing or different. Stylesheets that called for OT Small Caps or Oldstyle Figures simply didn’t get any applied. Nobody noticed. That happens in a high-pace production environment, especially when spread over multiple phases and departments.

When documents get passed between Designer & Client or within divisions of a Corporate Client, etc., it can be important for major versions of fonts to trigger indications within the software environment.

It would be nice if software actually read some version number in the font info and provided an indication. If this warning were turn-offable in preferences that it wouldn’t need to be a nuisance for more closed-system users.

Chris Lozos

I have seen this happen, just as Kent just described.  It is more likely to happen in large organizations with many people involved.  Thanks for spelling it out, Kent!

Cory Maylett

Kent, as a designer myself, the problem you've mentioned is one we've been facing since the introduction of desktop publishing.

An experienced designer would be unlikely to assume that his or her version of Fubar was the same as the Fubar version on another computer — especially a client's computer. On the other hand, there are many new designers who stumble across this potentially disastrous problem at least once before learning their lesson. This is one more argument against fresh-out-of-university designers freelancing before gaining real-world experience working under more senior designers, but that's another subject.

If layout applications, like InDesign, did a better job alerting users to font version changes — similar to their missing fonts alerts — it would help. Of course this would result in many annoying alerts spooking designers into possibly expensive and often unnecessary font version upgrades, who would then chastise Adobe for adding this feature. It would be nice, however, if InDesign did, at least, alert users to missing glyphs and reflow issues.

Personally, I rarely turn over source files to clients. When I do, it's always accompanied by a straight-forward discussion about fonts, as in, "No, I can't legally give you the fonts I used. You'll need to buy them yourself, then check carefully for reflow issues."

Kent Lew

Yes, experienced designers usually communicate specifically if exchanging files. But, as you note, not all designers are as experienced or type-savvy as us. And marketing materials can get handled by many hands other than designers.

Missing glyphs can be flagged in InDesign — “pinked out” .notdef glyphs. I think this feature is on by default.

Missing OT features and reflow, however, are much sneakier culprits.