When I stumbled across Seoul Namsan, the official typeface of the City of Seoul, I immediately liked some of its characters. No matter how exotic its name, something in the shapes of this font reminded me of the Allgäu region of Germany, more specifically of the graphic designer and typographer Otl Aicher who lived there. So I couldn’t help but wonder whether we could use it as the basis for a new libre typeface, optimized for today.
Luckily, the Korean font is available under the permissive OFL license which allows one to make alterations as long as one doesn’t use the original name of the font. So I decided to name my derived typeface Leutkirch, after the town where Otl Aicher lived.
Libre fonts
What do we mean with “libre”?
In software, “libre” means that not only can you take a piece of software and use it for free (as in “Freeware”), but more importantly the software is developed by a community in the open in a collaborative process, and you are free to participate in this development process or take the prior work as the basis for your own modifications and derived works.
Similarly, libre font software, like any other libre software, is developed by a community in the open in a collaborative process. This opens a tremendous space for collaborative creativity and learning, and the artifacts can be used by others without too many restrictions (e.g, use them in e-books and software appliances).
Just like with software, I think that developing fonts in collaborative development processes will lead to more experimentation and variation. Moreover, since the work is done by volunteers out of intrinsic motivation, there are no economic or other external pressures that may lead to shortcuts being taken in some commercial productions. So I think that libre development processes can ultimately result in higher quality — both in terms of artistic designs and in their technical implementation.
Libre font tools
An area where we are seeing rapid progress in open source is graphics applications. Also, Font rendering and the availability of high-quality libre fonts has greatly increased in recent years.
UFO
Let’s start with the Unified Font Object (UFO) which is not a tool but a format. In short, it is what C is to computer programs — a open standard language for the “source code” of fonts.
The Unified Font Object (UFO) is a cross-platform, cross-application, human readable, future proof format for storing font data.
It is developed in the open at https://github.com/unified-font-object/ufo-spec. More and more libre, open source and even commercial font tools are using it.
FontForge
So I started out using FontForge, which is a free and open source font editor available as an AppImage for Linux. This is great because it means that you can download the latest version directly from the project at https://github.com/fontforge/fontforge/releases and run it on most Linux distributions without the need for using a package manager or any complicated steps.
Using it, I quickly learned about the intricacies of naming fonts properly. Given more than four decades of technical debt in font file definitions, there is more to it than meets the eyes. Basically just about every piece of metadata exists multiple times in a font file, and one needs to ensure to properly follow all applicable restrictions and check the redundant information for consistency. In fact, some font tools have built-in consistency checkers for this very purpose.
Adobe Type Tools
In the area of font technology, many companies are moving at least parts of their font technology to open source. Perhaps most notably, Adobe with https://github.com/adobe-type-tools/. If you are interested in the history of Adobe as a company and the early development of digital printing and font technology in particular, then I can highly recommend watching the recordings of the Desktop Publishing Pioneer Meeting at the Computer History Museum in Mountain View, California (unfortunately it under-represents the European side of things, such as the story and inventions of the URW company).
For Leutkirch, we are using makeotf and otf2ttf from Adobe Type Tools to turn UFO source code into the final font software.
Proprietary tools
Even tough I prefer to use libre tools to create libre software when possible, there are clearly situations in which using proprietary tools can save time, increase quality, and/or have other advantages.
URW IKARUS and its legacy
“Legacy” is meant in a good sense here. With algorithms that date back to the very early days of digital type, URW IKARUS is possibly the longest-running line of software in the area of fonts. According to Wikipedia, its customer list reads like the who-is-who of the 80s font industry:
It was licensed by major foundries such as Agfa-Compugraphic, Autologic, Berthold, ITC International Typeface Corporation, Letraset, Linotype, Monotype, Stempel, and others.
Intrigued by the possibilities of IKARUS and its impressive history, I ordered a paperback copy of the book by its inventor, Dr. Peter Karow: “Digitale Schriften: Darstellung und Formate” from 1992. (The book is also available digitally and in English directly from the publisher.) Not only does it contain an interesting overview over the early history of digital fonts and the basic challenges of reproducing typefaces digitally, it also describes IKARUS and the various font formats used by the URW font toolchain in great detail. From today’s perspective it is also dated in some aspects, as becomes evident already on the first pages when it suggests that font design should always start on paper. Almost 30 years later, the fonts of today are usually born — just like their designers — as digital natives.
Today, the URW font tools are living on as part of the DTL Font Tools by the Dutch Type Library, which are developed jointly with URW.
OTMaster (OTM)
According to the company that sells it,
The flagship of the DTL font tools is without any doubt OTMaster (OTM). (…) OTM is the multi-functional ‘swiss knife’ for professional font production. It is used by many experts in the field and applied by some of the largest companies in the software industry, among which Adobe.
Thankfully, they are also providing a Light version for free that allows those of us to tinker with it who could otherwise not afford such a professional-level tool.
Back to the topic of font naming and metadata. OTM Light contains a consistency checker that basically does what its name implies.
LetterModeller (LeMo)
Looking at the font, I noticed that round shapes had many more control points than what most other fonts are using:
While the book “Digitale Schriften: Darstellung und Formate” by Dr. Peter Karow does contain a chapter on how many and where control points should be placed, that chapter is referring to the use of URWs IKARUS control points rather than the Bézier control points used today in tools like FontForge and LetterModeller. (In case you wonder: IKARUS control points had an advantage over Bézier curves when digitizing from paper because all control points are on the contour of the shape, but since digitizing from paper has become increasingly rare, this advantage does not seem to be that significant anymore.)
Luckily, there is a description of how many and where control points should be placed in fonts made of Beźier curves in the Adobe Type 1 Font Format specification, a book that is informally known as the “black book” and is nowadays freely available online from Adobe.
Even though that book mainly describes the inner workings of the PostScript when applied to fonts (something might be interesting but not essential for a font designer to understand), there is the highly relevant chapter 4 that explains in practical terms how to strategically place points for Bézier curves for professional fonts. It is clearly stated in that chapter that one should “use the fewest Bézier curve segments that accurately represent a shape.”
Paths should be concise which means that no more than the points essential to create a shape should be used. Points need to be placed at
- Edges
- Extrema
- Tangents (for example, straight line to curve, curve to straight line, or curve to curve)
- Exceptions (There’s always exceptions. )
So, how can we turn the many control points from the original Seoul Namsan font into something that conforms to the rules outlined by the Adobe black book while minimizing error-prone manual work?
Turns out that deleting points in FontForge will destroy the closed path. You will end up with missing parts in the character outline, which you will have to recreate manually.
Enter LetterModeller (LeMo) by Frank E. Blokland and the programmers at URW. Besides implementing an exciting approach to produce typefaces based on digital models (something that is material for another article), its glyph editor (based on the URW IKARUS toolset) has two tools that are very useful to do this kind of job:
By selecting “Extreme points”, we make sure that control points are exactly at the extrema. Next, the “Delete point” utility is working true wonders:
Using it, we can remove the extraneous control points while maintaining the shape of the contours to the maximum extent possible.
It’s a fun game I call “Font Mikado” to click on the extraneous points and take out as many as possible without changing the shapes.
Just as Arthur C. Clarke formulated,
Any sufficiently advanced technology is indistinguishable from magic.
Certainly true for this feature in LetterModeller, among many others.
Update: Turns out that one can play “Font Mikado” using the libre FontForge editor too, by selecting a point and then pressing Ctrl-M (“Merge”).
Still, other features of LetterModeller are certainly absent in libre tools such as FontForge as of today.
Which brings us to the question, how can we use OTM Light and LetterModeller in a libre font production workflow?
Libre font production workflow
As mentioned earlier, a libre font production workflow should ideally make use of libre tools as much as possible, but as we saw, making selective use of proprietary tools can help increase quality and save time. When using proprietary tools to create libre software, one should be careful not to lock the resulting artifacts into proprietary file formats, and should ideally only use proprietary tools that are within the reach of all potential contributors, which usually excludes expensive tools (after all, many libre projects are not seeing any revenue).
So, how can we integrate OTM Light and LetterModeller into a libre font production workflow?
Turns out it is a bit more involved than anticipated, but it can be done.
Get OTM Light and LetterModeller to run on Linux
First of all, we need to ensure that we are allowed to use the tool for the purpose of making libre fonts. I could not find anything in the documentation that comes with OTM Light and LetterModeller that would make me doubt that we are allowed to use those for the purpose of making libre fonts.
Second, we need to get the tools to run on our machines, which for most libre software developers today means, Linux distributions. Unfortunately, it can be hard to get binaries built on one Linux system to run on another — especially when compared to how easy this is on the Mac. This is a problem I have been addressing with the AppImage format for portable Linux applications which many libre graphic applications are using nowadays. For now, I could get OTM Light and LetterModeller to run by a procedure roughly like this — I will not go into details here but it can illustrate the point that it might be a good idea to ship OTM Light and LetterModeller as AppImages in the future.
tar xf OTM_Light_370_LIN.tgz # is 32 bit
tar xf LeMo_540_Linux.tgz
sudo apt -y install fonts-freefont-ttf
sudo mv /usr/share/fonts/type1 Desktop/ # Otherwise we get a crash
sudo mount ubuntu-16.04.1-desktop-i386.iso /mnt
sudo mount /mnt/casper/filesystem.squashfs /mnt
export FC_CONFIG_DIR='/mnt/etc/fonts'
export ICONV_PATH=.
/mnt/lib/ld-linux.so.2 --inhibit-cache --library-path '/mnt/lib/i386-linux-gnu':'/mnt/usr/lib/i386-linux-gnu' '/home/me/DTL OTMaster 370 Light/DTL OTMaster 370 Light'
cd '/home/me/LeMo_540_Linux/'
touch qt.conf
mkdir -p lib
( cd lib/ ; ln -s /usr/share/fonts/truetype/freefont fonts )
dpkg -x libjasper1_1.900.1-debian1-2.4ubuntu1.2_amd64.deb .
dpkg -x libpng12-0_1.2.54-1ubuntu1.1_amd64.deb .
export LD_LIBRARY_PATH=./usr/lib/x86_64-linux-gnu/:./lib/x86_64-linux-gnu/
./'DTL LetterModeller 5.4'Integrate the tools into a UFO based workflow
Since we must avoid to lock the resulting artifacts into proprietary file formats (although in the case of the URW file formats, “proprietary” is probably not the correct term, as the file formats are fully published in “Digitale Schriften: Darstellung und Formate” by Dr. Peter Karow and could probably be implemented by anyone), we want to use UFO as the format for storing the font “sources”, as this is what most libre font projects have settled on.
Integrating OTM Light and LetterModeller into a UFO based workflow is a bit harder than imagined, too, but it can be done like this:
Other than what its Readme claims, LetterModeller seemingly cannot import .otf files directly. So we have to
- In OTM Light, open the
.otfversion of the font - Edit -> Fixup
- Tools -> Consistency Checker
- On each tab, click “Check” and “Apply”
- File -> Export
- Leave the first three options checked (
.be,.ufm,.cha) - Click “OK”
- In LeMo, “Open font data…” and select the
.bejust created - To export to UFO, “Export font data…”. Important: Select the
.ufmand.chathat were earlier exported in OTM Light - Rename the suffix of the folder like this:
mv LeutkirchSans-Regular_ufo LeutkirchSans-Regular.ufo - Remove particularities of the font editor in the UFO format like this:
ufonormalizer -v LeutkirchSans-Regular.ufo
And there we have it, a workflow that incorporates OTM Light and LetterModeller into a UFO based workflow for creating libre fonts on a Linux machine.
Of course, this is just the beginning of my journey into learning about and making libre fonts. And unlike their “closed” counterparts, libre fonts are never complete… which may be their weakest and strongest aspect at the same time. In case you want to check out what we have so far, here is the GitHub project.
probono is the founder and lead developer of the AppImage project, contributor to hundreds of open source projects, and interested in software usability and digital typography.
FontForge AppImage was used for font editing. OTM Light and LetterModeller were used for font conversion and editing. Typora AppImage was used for editing this article.
