Version Control for Typeface Development

I’ve wanted to write a bit about version control in relation to font software for a while, but Version Control is a big subject (hence the capitals!) and has been extensively covered elsewhere for software development, so I’ll try to limit myself to a description of how it can be used for typeface development. More information about the system used here (Subversion) can be found at the ‘Red BeanSVN book web-site.

Font files are software (and how SVN can help)

First off, I’ll start by stating that Fonts Are Software. And not just in a pragmatic fit-the-definition-for-intellectual-property-law sort of way, but in a real code-compile-interpret sense. Obviously fonts aren’t just software, they contain tables of data that are the realisation of a designer’s vision for a typeface, but because the design transmitted is in the form of code, there are coding practices we can learn from the software engineering community that can help us make better font files. One such practice is the use of version control systems.

Version control systems, like the open-source, Subversion (SVN), store files in a repository who’s job is to manage change between versions. To work on these files, you have to check-out a copy, then save back any changes to the repository. Every time you save a new version of your files to the repository, known as ‘committing’, the revision number for the repository increments, starting from 0. So, every revision of your work has a unique rev number.

The most fundamental benefit of using version control is as a simple backup of your work. The repository is stored separately from your working copy, often remotely on a web-server. So, if the worst happens to your computer, you’ve got a recent copy of your files saved to go back to. The life of a typeface project is long, the chances of losing work are high, so this alone sells it for me!

But better than that, version control systems don’t just save a copy of the latest version, they also allow you to go back to any version you’ve committed to the repository. This is great, because if you’ve made a bad design decision, after a night at the pub say, you can easily go back and retrieve a previous version not inspired by several pints of terrible British lager.

If you work in a team, you’re likely to run into problems if two people have made changes to the same file. It can be a fiddle to get changes integrated or in the worst case, someone’s work is going to be overwritten and lost. Subversion uses a copy-modify-merge model to handle this problem. Each user has a copy of the file from the repository. They make modifications. Then, when they each commit that file back to the repository, the changes are merged together.

For example, Alice makes a change to the features file by adding some more substitutions to the LIGA feature. Bert is also working with a copy of the same features file and has made changes to the LOCL feature. Alice doesn’t have Bert’s changes and visa versa. After Alice has committed her changes to the repository, when Bert commits his changes, Subversion will merge the changes together automatically creating a file with both changes to LIGA and LOCL.

What if Alice and Bert have both been working on LIGA? If there is an overlap in the changes made to a file, when the second person (Bert) commits the file there will be a conflict. This isn’t as bad as it sounds. The file will be flagged as being conflicted and Bert can decide which changes to keep, mark the file as resolved and carry on committing it to the repository.

For a (much) better description of this process have a look at Versioning Models in the SVN book.

Binary to text files

SVN prefers plain text files (like this HTML page). This is a bit of a problem for most of us, because programs like FontLab Studio store your work in a binary format, like .vfb files. SVN is happy to store them, but we can’t easily do the cool stuff SVN offers, like merging or dealing with version conflicts. Feature files and class data can be exported as text files, but what about glyph data?

Thanks to Robofab, and in particular the UFO format, we can store our glyph data in text files! Robofab comes with tools, written in Python, for exporting and importing between FontLab and the UFO format.

When you export a font to UFO, each glyph is stored in its own text file, the GLIF. So when you’ve added or modified a glyph to the SVN repository, it’s easy to see what was committed during a particular revision, and conversely, which revisions contain changes to a particular glyph.

Python and SVN

If you’re into Python scripting, you might want to use the pysvn extension to make use of SVN in your FontLab and Robofab scripts. Here are some examples:

Export to UFO and commit to SVN

Below is an example script that uses pysvn to export the current font to UFO, add un-versioned files to SVN control, and commit the changed UFO and .vfb files to the repository as a new revision. v1.3

(Works within FontLab, and requires Robofab and pysvn. More info about the script here.)

Generate a font with the latest rev number attached

When you generate a font file from your project, you can include the revision number as part of it’s font information. Below is a modified version of Ben Kiel’s, that generates a font file and adds the current revision number as part of the minor version information. This way, you know exactly which revision a font was generated from. So, if your font is major version 1, and it was generated from rev. 23, the generated font would be version 1.23.

(Works within FontLab, and requires Robofab and pysvn.)