The ArrowType Blog

How to make a font in Glyphs, starting from Illustrator

2025-02-14T00:00:00Z

A fairly common question is: “I’ve drawn a font in Adobe Illustrator. How do I make it into a font?”

Back when I made my own first font (about 13 years ago, already!), I remember being surprised that Adobe didn’t just offer a font-making application as part of the Adobe Creative Cloud. They make fonts and they make creative tools, right? Well, more accurately, Adobe makes money. Type design is too niche a market for them to focus on providing full software for it. (To be fair, Adobe has made great contributions to the underlying tech of fonts, and Adobe Fonts is pretty well-regarded in the type community!)

The upshot is: font editing apps are made by a few very small, very cool companies. As you can see from my other blog posts, I am partial to RoboFont and Glyphs.

If you are just starting out, I suggest giving Glyphs a try! If you have already started drawing a font in Illustrator, this article may be helpful to you.

Two things to note up-front:

If you’ve already drawn a character set in Illustrator, you can alternatively use a product called FontSelf, which will allow you to make a font right from Illustrator. I haven’t tried FontSelf, so I can’t comment on how fully featured it may or may not be. If you’re looking for the fastest solution, though, this might be it!
If you haven’t yet drawn a bunch of glyphs in Illustrator, I highly recommend learning to draw directly in Glyphs, instead. The drawing tools in Glyphs are about a million times better than those of Illustrator, when it comes to creating letters. Glyphs gives you much more control and (with a bit of practice)is much more efficient and less frustrating for drawing letters.

In either case, spacing is arguably the most important part of making a font. So, if you’re making a font, it’s a great idea to start working within a proper font editor as early as you can.

How to start your font in Glyphs 🔗

First, make a new font in Glyphs. Go to “File > New from Glyph Sets…” then select “Latin” as the option for a script. Toggle on “Yes” to prepare glyphs for, and start with Basic. You can easily add more glyphs later.

Next, decide on your font’s cap-height. Glyphs gives 700 as a default, and it’s a reasonable default.

In Glyphs, go to “File > Font Info” (Command+i, or click the ‘i’ icon). Then, go to the Masters tab, and check the cap-height.

A bit more detail on font metrics

The cap-height uses units that are part of the Units per Em, or “UPM” of the font. The UPM is the measure of the coordinate grid you will be drawing your font within. You can think of it like graph paper. How precise do you want your grid to be? You can go beyond the bounds of the UPM. A UPM of 1000 is a good default.

If you want, you can also find the cap-height of a most fonts by opening them up in Glyphs. Some fonts have a UPM that is different from 1000, which will change the relative cap-height. 1000 is generally good to stick with, though. If a font you are looking at has a UPM of 2048 and a cap-height of 1432, you can find its cap-height out of 1000 UPM by calculating capheight / upm * 1000, or 1432 ÷ 20248 × 1000 = 699.21875 (about 700).

(Also worth noting: the licensing of many fonts will prohibit you from inspecting them like this. So, uh... don’t post about your elite font hacking to social media.)

For what it’s worth, Helvetica Neue has a UPM of 1000, a cap-height of 714, and x-height of 517, so it’s pretty typical to be somewhat close to that. Don’t ask me how I know this. ;)

Script fonts tend to have taller cap-height and lower x-height, but it all depends on the design of a given font. Also, you can scale the font later if needed.

Copying glyphs from Illustrator into Glyphs 🔗

In Illustrator, scale all your drawings so that the overall font matches the cap-height you have chosen. Make sure to scale everything to that size, including round glyphs that may have “overshoot” and lowercase glyphs that won’t go up to the same full height. Scaling glyphs perfectly in Illustrator is a bit of a pain, but the closer you get to perfect here, the easier the next step will be.

One at a time, copy the glyph outline from Illustrator (just select the whole letter, then use Command+C), and paste it into GlyphsApp: open up that glyph’s Edit View, then double-click into it, and use Command+V. Select “Correct Bounds” if given the option.

With the standard arrow tool (Shortcut: V), drag a box around that outline to select it, or use Command+A to select all outlines in the current glyph. Slide that outline into place, and adjust the side bearings in the Glyph Info box below (you can turn this on with themenu item “View > Show Info”).

If you need to scale glyph outlines further, you can use the bounding box handles (“View > Show Bounding Box”), or move points.

If the glyph doesn’t look how you expect it to – maybe the interior counter space isn’t showing up as negative space – try using “Path > Correct Path Direction” (Shift+Command+R) while you’re editing the glyph.

If you have flat edges at the top/bottom of letters, it’s worth lining these up exactly on the metrics. Glyphs will show a little diamond shape when a node sits perfectly on a metric line.

When you paste in other letters, you will want to scale your other metrics to fit the x-height, ascenders, and descenders. Helpful to know: you can literally open the Font Info window next to an open lowercase glyph and watch the metric moving as you adjust the number.

What’s next? 🔗

Next up (even before you’ve added more than the first few glyphs!) is to learn how to adjust spacing so your glyphs have decent and consistent sidebearings. Pro tip: learn and use the keyboard shortcuts for this!

As you get further along, you can add more characters to your font from the sidebar.

Also, if you have new glyphs to draw, it’s worth drawing them directly in Glyphs, rather than going through Illustrator. Here’s a handy video on how to draw paths in Glyphs. This video also offers a bunch of perfect examples of why it’s so powerful to draw letters in a dedicated font editor!

If you want to engage in more passive learning, you can also check out my YouTube channel.

Happy drawing!

RoboFont vs Glyphs, and why I use both

2025-01-24T00:00:00Z

Wow, it’s been a long time since I last made a blog post. I’ve spent a lot more time making YouTube videos recently, but I just got a question via email, and it’s on a topic I’ve wanted to write about for years but never found the time for.

I apologize up front for any half-baked thoughts here. I have incomplete knowledge and biases from my specific projects and opportunities. Still, this is a topic that deserves attention, so it seems better to write about and share than to keep to myself.

The email:

Hi Stephen,

I hope you don’t mind me reaching out! I’ve been following your YouTube channel for the past few years, and I just wanted to say how much I enjoy your content. It’s been fascinating to get a behind-the-scenes look at the typefaces you’re working on, and I’ve found your advice incredibly helpful—it’s made a big difference for me, so thank you!

I’ve noticed in your videos that you often switch between Glyphs and RoboFont, and I was curious if you could share a bit about your typical workflow when creating a typeface with both apps. I completed the OHno Type Beginner’s Course and tried the 30-day trial of Robofont. While I found it really intriguing, I didn’t get much time to dive deeply into it.

Thanks so much in advance for any insights you’re able to share, and keep up the amazing work—it’s always inspiring!

Best Regards,
Person

Clearly, this person never specifically asked for “RoboFont vs Glyphs” as a head-to-head comparison, and I do try to address their question at the end. But, I think they may have the deeper question of “What app should I invest my time into?” This is a valid question, and worth exploring.

I sent them a quick reply, and I’ve expanded upon it for this blog post.

My context 🔗

I work in both apps quite often due to a quirk of my primary job: I help other people make and finish fonts. This involves building font “binaries” like OTFs and TTFs, using tools like FontMake, checking those outputs with tools like Font Bakery, and fixing problems that exist. Fixing problems often involves using either RoboFont or Glyphs (or some combination of the two) to adjust font info or design data. Sometimes, it means manipulating source files or font binaries with Python-based tools such as ufoLib2, glyphsLib, and TTfont.

Let’s take a step back from all the technical stuff, though...

My work background

I drew my first font in about 2012, in Fontographer, which was mostly a terrible choice. This software was first made in the ’80s and seemingly hadn’t changed much by 2012. This consistency is great for those who like to draw in Fontographer but not as intuitive for someone new to drawing type. Glyphs was already around, and it would have been the much better choice in most ways. I moved to Glyphs for fonts I drew in 2013–2014 for my undergrad Senior thesis, and I found it so empowering and fun to use. (On the other hand, there is a lot of educational value and long-term power in simpler tools that don’t gloss over what you are doing with too much automation. In a sense, this push-and-pull between control-vs-speed is at the heart of the RoboFont-vs-Glyphs question! This isn’t to say that RoboFont is slow, or that Glyphs doesn’t give control... it’s more that, out-of-the-box, each app prioritizes one side or the other of that tradeoff.)

I later got a Masters degree in type design at KABK TypeMedia in the class of 2018. There, I transitioned to Robofont, as most of my teachers and classmates used it. (After all, RoboFont started as a TypeMedia project, and a few of the instructors are actively involved in the creation and development of the UFO and Designspace formats.)

After TypeMedia, I worked as a freelancer for Google Fonts, building fonts made by others and preparing them for publication on Google Fonts. These fonts were mainly in the Glyphs format, but some were built with UFOs and a Designspace (i.e., created in RoboFont). I was also hired by Google Fonts to finish my TypeMedia thesis project, Recursive, and publish it as an OFL project. Recursive was a UFO+designspace project from start to publication.

These days, in my personal and commissioned font projects, I spend most of my time working in Glyphs.

I also currently work part-time as a font engineer at The Type Founders, where I once again take fonts designed by others and build/prepare these for publication.

Along the way, I’ve also freelanced for indie foundries, helping them set up build & QA processes and finish their fonts built in either RoboFont or Glyphs.

All font editors are beautiful

I love both RoboFont and Glyphs, and I am so grateful and impressed by their creators, teams, documentation, and support forums. I’ve met and conversed with the people who have built and supported both apps; they are all lovely people.

I should also acknowledge that I’m leaving a notable app out of this discussion: FontLab. I simply don’t have much personal experience with it. If you’re primarily a Windows user, it seems to be the main option. It is the primary tool of one of my favorite type designers, Matthijs Herzberg. Even on Mac, where Glyphs and RoboFont get most of the attention, FontLab is a powerful option. However, it’s not as popular with the designers and companies I have worked for so far, so my main experience with it is converting FontLab sources to UFOs and then building fonts from there.

There are still more apps for creating and editing fonts, but a complete survey of tools isn’t the point of this article.

Which app is better? 🔗

Like most things, it depends.

My high-level take is:

Both apps are really good, and each has their own strengths and weaknesses.
If you are self-teaching, Glyphs is easier to learn and be productive in.
If you want to learn about fonts and type design at a deeper level, RoboFont is arguably the better choice. If you are specifically interested in learning to code in Python, RoboFont gives a smoother on-ramp for this (in fact it will somewhat force you to write or at least use code in order to be productive). Even if you don’t write code, you will arguably gain a more well-rounded understanding of fonts and type design by working in RoboFont.
If you are following a formal course (such as the OHno Type course or a school program like TypeMedia or Type@Cooper), it’s best to use whatever software your instructor uses. That way, you can learn from them without a layer of software translation getting in the way.

Like any art form, the vital thing to learn is seeing and making the art, much more than learning to use the equipment. In this sense, type design is similar to graphic design, photography, painting, writing, playing guitar, skateboarding, or a million other pursuits ... equipment is only a means to an end. Your choice of gear may make specific tasks more straightforward or efficient, but gear is seldom the limiting factor. A pro can do good work on almost anything, whereas a beginner can’t buy their way to knowledge. You could make a great typeface using any font editor that allows you to draw, space, and kern glyphs, then output these into a standard font format.

The best parts of either app 🔗

The best parts of RoboFont:

Space Center emphasizes and organizes the spacing side of design, which is easy to overlook but arguably the most important aspect of type design.
MetricsMachine makes kerning a very direct, controllable process. (Kerning in Glyphs feels somewhat chaotic by comparison. Part of this is that it leaves the workflow more up to the user, and kerning in Glyphs becomes much better once you use the right sample text. Finding or making the right sample text is a bit harder, though.)
I also like some very specific details of drawing in RoboFont, like the fact that on-curve and off-curve points are selected in different ways (so offcurve nodes stay attached to moving on-curve points, unless you specifically select the offcurves). By contrast, Glyphs treats on-curve and off-curve points more equally, which is occasionally helpful but often slightly annoying. This is hard to explain, and it might not make sense to anyone reading this, and that is okay.
If you want to learn about scripting in Python, RoboFont makes this more approachable than Glyphs, mainly due to a more intuitive file structure: each “master” drawing of a typeface is its own .ufo package, whereas a Glyphs file puts all masters into a single package. The flip side of this benefit, though, is that you basically have to embrace code to be effective in RoboFont.

The best parts of Glyphs:

It’s just so fluid and fast to work in, and so many things that are semi-basic, like duplicating, renaming, and deleting glyphs, scaling the UPM, setting font info data across multiple Masters or Exports, etc... are simple UI operations – whereas many of these things require scripts to do at all in RoboFont, or else to do across multiple sources.
RoboFont also historically had some laggy drawing (this may have changed with the latest version, which I think is finally running more natively on Apple M chips, but I haven’t drawn in it much just recently.)
Glyphs is also very helpful in writing feature code, such as language localization, numeral styles, stylistic sets, and more.
I’ve found Kern-On very helpful for kerning work-in-progress fonts, which is most of my catalog, so far. However, I will probably take my fonts back through RoboFont & MetricsMachine before considering them “v1” / finished. Like anything involving “AI,” Kern-On results in a slightly amorphous output that is hard to fully understand and trust.
I slightly prefer the way “scaling edit” works in Glyphs. It’s one step more powerful than the similar tool in RoboFont, and in Glyphs, it’s available via modifier key hold, whereas it’s a separate tool in RoboFont. (For what it’s worth, it seems like FontLab may have an even better “power nudge” tool, though I don’t have much personal experience with it.)
If you want to avoid scripting, Glyphs will allow you to get further with no code. Glyphs is still a great choice if you want to embrace scripting, but it may be more challenging for beginners.

File formats: .ufo vs .glyphs

A discussion of font editors should also consider file formats, as these are a big part of the experience. The best part of the .UFO file format (used in RoboFont) is how simple it is to edit via Python scripting, even with no desktop app required. You can write a Python script to make an edit to one or many UFOs, and run that script in a terminal, without ever opening RoboFont.

This kind of “remote” editing operation is also (somewhat) possible via glyphsLib. Still, the glyphsLib library is a bit confusing in that it only supports glyphs3 files in an experimental way, in a development branch. (This is somewhat annoying, as the glyphs3 format has existed for over 4 years. But, I can’t really blame anyone for this, as it is amazing that any of this software exists at all, and I know that everyone involved in glyphsLib is busy with other work that is probably more vital to their paying rent, etc.) Running glyphsLib on a glyphs3 file will break certain things. The saving grace is how easy it is to edit whole families in Glyphs with the UI, making scripting less of a requirement for most projects. However, if you are trying to fix something basic (like a copyright string) across multiple families, UFOs are much more convenient.

There is also a philosophical difference between UFO and Glyphs formats: the UFO is an open standard, whereas Glyphs is made and controlled by a private company. So, the UFO format can be read and edited by many apps, while the Glyphs format can only really be edited by Glyphs. As part of this, it is arguably more future-proof to work in UFO files, because your ability to use them doesn’t hinge on the continued success or business model of a single company. On the flip side, glyphsLib is mostly very good at converting Glyphs files to UFOs, so even if Glyphs were e.g. bought by Adobe, you could (in theory) convert your Glyphs files from 2024 to UFO files in 2030, using the right version of glyphsLib. If one of the formats were to come under the control of a company like Adobe and locked down into something much more proprietary, locked behind a subscription, it would be a different story.

Finally, I appreciate how the UFO format is handled in Git, a tool I use for every project. A UFO is made of many separate files, so it’s easier to see what changed in a given Git commit. Now that Glyphs offers the .glyphspackage file format, however, it’s basically just as good (or maybe slightly better?) on this front.

Silly, personal reasons

I also have two pretty silly reasons for preferring Glyphs for drawing fonts:

I like making YouTube videos to share work sessions, and Glyphs is probably more popular among newcomers to type design. I also believe it has a more intuitive design workflow for a casual observer, and therefore, it makes more sense in videos.
I really like tiny keyboards. (Why? A proper explanation would take a separate blog post, but they’re portable, customizable, and quite simply... I just love how they look and feel to use.) Such keyboards tend to eschew the number row, making numbers available by holding a layer key. This is great for day-to-day computer operations, and it even allows you to fit a numpad on a layer, which I highly prefer to a typical keyboard. Regarding font editors, however: RoboFont’s essential tools are selected with number keys, and I haven’t ever found a way around this. So, it’s a two-key operation to switch tools, which is slightly annoying. I prefer tool selection via alpha keys.

Projects where I’ve gone back-and-forth

In the past, I’ve had families that I started in RoboFont but then moved to Glyphs. I’ve also had families that are primarily made in RoboFont, but taken into Glyphs for a specific operation, then moved back into RoboFont. In the future, I will probably have families that started in Glyphs, but end up in RoboFont.

In Shantell Sans, the design started in RoboFont, partly because I was getting better results from its Outliner plugin than the Glyphs equivalent. (I was drawing single strokes, then expanding these into filled shapes.) I later moved to Glyphs to take advantage of Kern-On. But, the build process actually exports back to UFOs, so it can manipulate these to create shifted glyph alternates, etc. This is partly explained in this lecture.
In Name Sans, I designed almost the full family as an upright/Roman-only system first, but I knew I needed Italics eventually. Once I was confident in the full design, I used a script to prep Italics, then edited these UFOs directly in Glyphs so I could clean up the skewed outlines as quickly and fluidly as possibly. With a huge batch of outline edits to be done, Glyphs was definitely more efficient due to its lag-free drawing. But, I ultimately kept the family as a UFO-based project, as I had already figured out all my technical stuff there.

When you need to use one or the other

Certain things can only be done in Glyphs, and certain things can only be done in UFOs.

Glyphs have various “smart” features like corner components that require Glyphs to interpret and build into output OTF/TTF fonts. My take is that these tools can be useful in an early design phase but shouldn’t relied on in a final font source because they are fragile between software versions and don’t allow full control over the actual shapes. However, different designers have different opinions on this.
There are some aspects of creating variable fonts / large families that work better in UFOs + Designspaces, where you have more precise control because you are closer to the final products. (Literally: when you build from Glyphs sources using FontMake, it first outputs to UFOs, then builds OTF/TTF fonts from there.) A specific feature that I don’t think works properly from Glyphs (neither via Glyphs build or FontMake build) is giving a glyph both Intermediate layers (e.g. to adjust shaping at an intermediate weight) and Alternate layers/glyphs (usually swapped to via an RVRN feature, or rules in a designspace). This miiight be fixed in a branch of glyphsLib, though? I’m not quite sure at the moment. Other similarly technical ends can’t always be achieved entirely within Glyphs sources, as they are somewhat abstracted to make design more intuitive and fluid.

How to go between the two apps

There are two basic ways to shift between apps:

Install glyphsLib, then use glyphs2ufo and/or ufo2glyphs on the command line.
Just open one or more UFOs (or an entire Designspace doc) in Glyphs, or export to UFOs from Glyphs. (It doesn’t seem like you can save from Glyphs to a Designspace, in the app – you’d have to do this with glyphsLib, or set up the Designspace separately.)

Glyphs files tend to have extra data, which can be good and bad when exporting to/from UFOs. It’s handy to use Git when doing this kind of back-and-forth so you can see what is changing. It is sometimes helpful to also run “UFO normalization” before and after the conversion so you can maintain a similar formatting of the UFO data. For this, you can run ufonormalizer or simply open and save UFOs with ufoLib2.

Signing off 🔗

I have suddenly remembered why I don’t write blog posts very often: it takes a lot of time to write something that is even close to decent!

Hopefully, though, this information is helpful to folks out there trying to understand this surprisingly deep question. If I’ve just dropped too many technical things without full explanation, and you are left more confused that when you started... welcome to type design! (But also, feel free to email me to ask for more info.) The ins and outs of “RoboFont vs Glyphs” is a question that touches on all aspects of type design and development, and as such, it’s something I continue to learn about all the time.

No matter what you’re making and which tools you use, all the best in your creative endeavors!

Update 1: layers 🔗

Soon after I published this, a friend reached out to mention how RoboFont and Glyphs handle layers differently. I can’t believe I forgot to mention this! A few notes on this:

The Glyphs Background layer is a quick Command+B keystroke away, and I use it constantly. RoboFont allows you to shift between layers with Option+Command+Up/Down, but the layers have some limitations.
Glyphs allows you to put a component into a background layer: so, for instance, if you are drawing an ohorn with a custom shape, you can place a live-updating o component in the background for a visual confirmation that your main shape is similar.
Glyphs also makes Intermediate layers and Alternate layers simpler to add and generally simpler to handle than RoboFont. (In UFOs, you can still use intermediate layers – within a UFO or in a separate UFO – and reference that layer from your Designspace.) This advantage in Glyphs somewhat ends if you try to use both Intermediate and Alternate layers, as I mentioned above. Hopefully, though, this limitation will be resolved in time.
Glyphs also assigns layers per glyph, and when you add a layer, it is date and time-stamped by default. This can be an easy way to quickly create a version history of glyph drawings as you iterate on an idea. This per-glyph model would also be possible in the UFO format, but RoboFont instead handles layers in a global sense, across a whole UFO, making them less useful for version history. (But there are better ways to handle versions and alternate glyph ideas. For versioning, save duplicate, date-stamped font files as you go, and/or use Git. To explore which shape of a glyph to use, make duplicate glyphs and test them in spacing strings, proofs, and marketing graphics.)

Update 2: composing accented glyphs & character sets 🔗

Working back in Glyphs later in the day from posting this, I was reminded of another aspect that differs quite a bit between these two applications: building precomposed glyphs. These are glyphs with accents that designers precompose in a font, such as aring (å) or Eacute (É), and so on.
In general, this is much easier and faster in Glyphs than RoboFont, because:

Composing accents uses “anchors” to specify where accents will attach to base glyphs. Glyphs gives a menu option for “Set Anchors” that will add in the main anchors needed for a wide range of language support, placing them at roughly the correct position. In RoboFont, you need to manually place these in each UFO source or use a script or extension to do so.
A bigger efficiency in Glyphs comes from automatically adjusting composed glyphs when you move anchors or accents in individual glyphs. In RoboFont, you have to recompose glyphs to apply such changes.

Possible drawbacks of the Glyphs approach are:

If the software does too much “magic” for you, it can be easy to become complacent and not notice if something has gone wrong. For example, you may create composed glyphs and get them to look how they should, but they will change if you adjust your anchor points in either the base or accents. It might disrupt your prior work if you don’t anticipate or notice this repositioning.
Glyphs has certain assumptions about names for combining accents and bases, and it will only compose glyphs intelligently if you give the bases & accents the exact names expected by Glyphs. For example, Glyphs will create the proper Acircumflex.ss01 if your file has both Acircumflex.ss01 and circumflexcomb.case, but if the former is called Acircumflex.alt and/or the latter is named circumflexcmb.case (without the “o” in “comb”), you will have to use a glyph recipe, like Acircumflex.alt+circumflexcmb.case=Acircumflex.ss01. (This probably seems like a weird gripe, but other standards specifically use the accent name circumflexcmb, without the “o”.) In RoboFont, you pretty much always need to use similar recipes in its Glyph Construction extension, which is less automatic, but allows a more tailored workflow, without the application being too opinionated about how you do things.

Character sets

As a related subject to composing glyphs, the two applications differ in how they expect you to set up character sets.

In Glyphs, building character sets happens in a few ways. Glyphs gives you a welcome screen for new fonts, and this offers to set up character sets for different scripts, like Latin, Cyrillic, or Arabic. It also gives a sidebar with categories for Glyphs, like “Latin > Basic,” “Latin > Central European,” “Punctuation > Parentheses,” “Figures > Tabular Figures,” and many others. Right-clicking on these allows you to add to that category of glyphs with appropriate naming and Unicode encoding. Building a character set is pretty straightforward if you accept the decisions made by the Glyphs team. To extend that, you can also add glyphs by names and lists of names, but Glyphs expects you to get the names “right” in order to get correct Unicode encoding and proper glyph composition support (as mentioned above).
In RoboFont, defining character sets isn’t too bad, but requires a bit of research and setup. RoboFont will set up glyphs with appropriate Unicodes, so long as you use the correct glyph names, according to the [GNUFL](https://github.com/LettError/glyphNameFormatter or AGLFN). For this, I find it essential to use the Glyph Browser extension. This extension is a bit like the Glyphs sidebar but is more powerful in some ways (you can search for glyphs by name or by typing them in) and less handy in some ways (I somewhat prefer the Glyphs categories to the more standard but more general character set categories that are presented in Glyph Browser).

Signing off, again 🔗

Who am I writing this for, anyway? I’ve attempted to present this comparison for someone new to the field of type design. Still, I must admit that I’ve included so many technical details that it would probably be difficult for most newcomers to follow.

Even so, if you have found this at all informative or entertaining, I’m glad! Come check out my YouTube or Mastodon for more type nerdery, and please say hello while you’re there!

The Story of Name Sans

2023-10-10T00:00:00Z

After several years of contemplation, exploration, work, and iterative releases, I have published a full Version 1 of Name Sans.

I wrote and published a process article on my main website. Read it here:

The Story of Name Sans

Shell Scripting for Font Builds

2021-06-18T00:00:00Z

Shell scripting is a method you can use to set up font build workflows that are approachable, scalable, and repeatable. I presented a tutorial on shell scripting in a presentation at the 2021 Typographics TypeLab.

The tutorial exists in a project repo at: github.com/arrowtype/typelab-2021

There is also a recorded version of the presentation on YouTube.

Happy scripting!

The Story of Name Sans, So Far

2021-05-26T00:00:00Z

Update: this article was original written in 2021, for Name Sans v0.5. More recently, Name Sans v1.0 was been released, along with a newer article describing Name Sans and its design process.

Name Sans is a modern interpretation of the mosaic name tablets of the NYC Subway. It is currently available with discounted pre-release pricing via Future Fonts.

From an outsider’s perspective, it might seem pointless to see a new release of “yet another geometric sans.” At a quick glance, it might look like Name Sans is basically just [insert your favorite sans-serif font name here]. Admittedly, there is some truth to this. Name Sans doesn’t have characters you can’t already typeset in other, previously-available fonts – it’s ultimately just a slightly different way of approaching the same old Latin script.¹

But, just as it’s nice to have new music, new fashion, and new architecture in the world, it’s nice to have new fonts. Projects like Name Sans are about giving designers new raw materials² to work with. Beyond that, new typefaces are about creative expression, pushing boundaries, engaging with history, and – at risk of sounding poetic – communicating something about the human experience. This article is here to point out some of the thinking behind Name Sans, what it can do that is different from other typefaces, and some of the details that make it unique.

What is Name Sans, anyway? 🔗

My favorite fonts are usually released along with an introductory article. Name Sans is still an active work-in-progress, now in its fifth pre-release version. In a way, you can think of this as the “v0.5” blog post introducing Name Sans, its process, and its design – I plan to revise this post when I can finally release version 1.0.

For me as a type designer, it isn’t always (if ever?) obvious what a project should be from the outset. Releasing Name Sans progressively through Future Fonts has helped me find what it really needs to be as a typeface. Certainly, my understanding of it has evolved since the earliest versions. Spending time with it myself – and especially seeing it in use by other designers – has helped push my thinking forward.

So what is Name Sans, really?

Well, one answer is that it’s the font you’re reading right now – but it’s also much more than that. Another simple answer is that it’s a 36-style font family with variable axes for Weight and Optical Sizing. But it’s also more than that.

Styles of Name Sans v0.5

As the tag line says, Name Sans is a modern interpretation of the mosaic name tablets of the NYC Subway.

Mosaic name tablets are by far my favorite feature of the Subway. These pieces of lettering built from ceramic tiles declare station names for Subway riders, while smaller versions provide extra wayfinding help within stations. Making this source of inspiration into a typeface is a project I have been imagining and sketching since moving to NYC in 2014, then more actively developing as a font family since the end of 2019.

Name Sans seeks to capture my favorite aspects of the varied mosaic signage of the NYC Subway system.

When I first had the idea for this project, I expected that I could dig up some kind of perfect blueprint for the mosaic signage from which to make a type revival. I have since seen a few tantalizing examples of historical documents that are close to what I’d like – but direct architectural plans have so far eluded me. So, the drawings for Name Sans are not a direct copy of scans from a dusty old type specimen. Rather, they are the product of me experiencing and appreciating the Subway mosaics over time, taking countless photos, and sketching ideas while riding the train.

As an NYC commuter, I almost always keep a sketchbook in my bag. When I can snag a seat, I try to draw letters. The rattling of the train is more apparent in some sketches than others, depending on my patience on any given day.

At one point, several years ago, I mentioned to an experienced type designer that I was thinking of making a typeface that would be a revival of the Subway mosaics. “Impossible!” they said, “what would you even revive?” At first, I was taken aback. How dare they doubt me like that! I wanted to prove them wrong. With time, I have come to understand what they meant.

Name Sans isn’t a revival, and it couldn’t be a revival.

Type revivals are recreations of specific fonts previously made with obsolescent technology, as when a digital font is made to recreate letters originally cast in metal for letterpress printing. There was no single, consistent “off-the-shelf” font used for the Subway mosaics. The system was built by several separate companies over many decades³, with projects led by different architects over time. The subway mosaics are a loose system of architectural lettering – not a singular typeface that one could “revive.”

So, this project is perhaps as much historical fiction as it is historical research. I am creating a type family based on what I have observed in actual mosaics and adapting this into a typeface that is useful, flexible, and built for this decade. Partly, though, I am making the typeface that I imagine could have been there the whole time, if perhaps Heins & LaFarge⁴ had commissioned a custom typeface for NYC’s first Subway from a type designer who time-traveled back a century.

In many ways, not having a single point of reference has freed me to make this project what it needs to be: a typeface that respects the past but doesn’t get stuck in it. There are clearly repeated lettering styles for different train lines and different eras. But also, something I love about the Subway is that there is not a perfectly repeated system for the name tablets. If all of the wayfinding was purely set in Helvetica and stations had a completely uniform aesthetic, the Subway would be painfully boring. More practically, it would also simply be harder to know when you reached the right station. As a rider of the NYC Subway, you learn to identify your stop by the color of tiles and the big lettering on the station walls. If you always had to look closely for Helvetica on uniformly–gray walls, you would end up missing stops a lot more often.

Name Sans picks up on my favorite aspects of the Subway wayfinding system and brings them together into an extended Latin character set with a wide range of weights and optical sizes. If I had gotten stuck on finding just one thing to revive, I wouldn’t have had the flexibility to really explore what is useful in a geometric-grotesque sans – and what is newly possible with type technology today.

The “Equitable Building” mosaic at Wall St is one of my favorite signs in all of NYC. Note the circularity, unusual proportions, and the sharp spur of the G. Even though I love specific mosaics, there are too many divergent styles to represent in a single typeface – so Name Sans brings in the best features from signs across the NYC Subway system.

Even if I had found blueprints, this project would have required creativity and adaptation. For one thing, the mosaics only contain the basic English uppercase alphabet, plus numbers and a few extra symbols like arrows and ampersands. I was always going to have to invent the lowercase, extended Latin alphabet, accents, and symbol set.

Beyond that, the mosaics only have a narrow range of weights – roughly “Regular” to “SemiBold” – and only have a sign-specific range of sizes – large to huge, meant to be seen from a distance. A typeface must offer a broader typographic palette unless if it is only intended for very specific usage. This suggested the need for an extended weight range. Type must be made for particular scales and contexts to work well. For Name Sans, that meant designing to target the small-to-large settings common to modern print & digital needs – often in longer strings than single Subway station names. I wanted Name Sans to deliver the punch of the mosaics effectively across font sizes, which suggested the need for a range of Optical Sizes (more on this below).

Working from more than a single specimen has also revealed possibilities beyond size & weight ranges. A challenging aspect of the project has been deciding which forms of letters to borrow from the system, as there are often multiple possibilities. For example, round uppercase letters can be found both with circular forms and with flat-sided forms, depending which station and sign you reference. Rather than drawing only the most common style of an uppercase, I have made two – a default set with the circular forms, plus a stylistic set (ss01) that takes on flat-sided, rectangular shaping. Another question was which R to use – the more common, basic construction with a straight leg, or the uniquely mosaic approach to a grotesque R with a monolinear leg “kick”? Well, it’s a modern typeface, so again, I could include both using Stylistic Sets. And then, it’s a modern typeface, so why not add a few other things fit that users might want, like a single-story a?

And thus, I have sought to build a typeface that captures the best energy and spirit of the Subway mosaics but which is genuinely useful to designers working in digital systems, wayfinding, and graphic design.

The following will go into more detail to describe the formal qualities that exist in the Name Sans design.

By the way...

If any transit archivists or aficionados are reading this and know of specific blueprints or specifications that I might have missed, I’d be super appreciative to learn more! The online archives are great but (understandably) don’t contain images for every possible item. A 2019 exhibit did include a few beautiful watercolors and pencil sketches, but not as many as I had hoped for. I haven’t yet been able to dig further into physical archives due to COVID-19 protocols, but I would very much like to see more! You can reach me at info@arrowtype.com if you want to chat.

A wide range of Weights & Optical Sizes 🔗

Name Sans includes two axes of stylistic variation: Weight and Optical Size.

Weight

It’s relatively self-evident what it means for a typeface to offer a range of weights. If a font has just one weight, it will be limited in how it can be used and will almost always need to be supported with other fonts. But, if a typeface offers even just two or three weights, it dramatically opens up what you can use it for. These benefits continue to increase with further range and granularity.

Name Sans has a weight range that is as wide as (reasonably) possible, offering both workhorse core weights and high-impact extremes in one easy-to-use system.

Many designers would reasonably contend that there is a point of diminishing returns. Once you have styles that are light enough and bold enough, along with a few between, you don’t really need more. There may also be a paradox of choice for users: if a typeface has too many options, it might become hard to pick the ones you want. These are valid concerns. From a creator’s perspective, too, it is essential to draw lines of scope so you can provide adequate focus to the work that falls within that scope.

For Name Sans, I have, of course, been thoughtful about project scoping – but I have also made a concerted effort to push those lines beyond what a typical project may impose. In my experience as a designer, there are always times when I wish a typeface would go just a little bit bolder or just a little bit lighter. A goal of Name Sans is to provide the most utility and versatility to as many designers as possible. So, just as a designer may select a computer with plenty of “headroom” in its RAM and storage – even if they may not use those full limits most of the time – there is value if a typeface can do more than most people need, on average.

A technical explanation of my approach for Name Sans: this typeface uses the full possible 1–1000 range for a variable Weight axis, as defined by the OpenType Spec.⁵ There are conventions for what font weight numbers mean, but their exact implementation comes down to the interpretation of individual type designers. 300 is usually Light, but how light is “Light”? 700 is almost always titled Bold, but how bold is “Bold”? What are the extremes of thinness (1) and thickness (1000)? For Name Sans, I have aimed for core weights (Light through Bold) to fairly closely match the thickness of comparable fonts. However, I have drawn the full range of 1–1000 – Hairline through Ultra – to be as thin and thick as reasonably possible.

What is reasonably possible, then? To get specific, I am drawing this typeface with a coordinate grid of 2048 units between ascenders and descenders (the UPM of the font). The Display Hairline style is meant to be a representation of the very core of the characters. It is drawn with stems of just 2 units on this grid – barely enough to allow similar thicknesses in straight, diagonal, and curved strokes. Meanwhile, the Display Ultra is drawn to be as thick as possible while still preserving my subjective understanding of the essence of the Name Sans design.

Weights 300 to 1 in Name Sans Display. The Hairline styles offer a near-invisible endpoint for disappearing & appearing animations.

A warning: the Hairline is so thin, it disappears in some contexts. Sometimes, it is better to use a slightly-thicker style (in the variable font, you can use weights like 15 or 27). Sometimes, it’s useful to add a bit of an outline stroke to these letters. It may seem odd to have a “dangerous” zone included with a font, but I think of it like a color palette. Designers are already used to choosing colors carefully so as to ensure a readable level of contrast. A super-thin font style requires similar thoughtfulness.

But, that disappearingly thin weight is a hidden feature: it allows Name Sans to animate in and out from this core. This can be especially useful in characters that maintain a common width between weights, like arrows and tabular numbers (activated with feature tnum). If any wine label designers are out there, the Hairline characters would also look preeetty nice printed at a large size on a wine label. Just an idea...

Optical Size

To understand Name Sans, it is essential to first have an idea of what optical sizing is. The optical sizes of a typeface are made to preserve its design intent at different sizes. In this way, optical sizes are fairly similar to font weights, which are usually made to preserve the design of a typeface at different relative levels of thickness or density.

The x-height, contrast, and overall proportions are subtly adjusted along the Optical Size axis to look as good as possible at large sizes while also providing comfortable readability in Text.

Just as there is no single answer to how every typeface should be designed for different weights, there are many ways to design for different sizes. Generally, though, there are some common strategies:

Letter spacing usually needs to be more generous for smaller sizes, or letters will look uncomfortably close. Conversely, spacing usually needs to be tighter at larger sizes, or letters may appear to be drifting apart. In fonts with optical sizes, the designer using the font must manually apply set tracking ideal for a given size. In fonts with Optical Size styles, size-specific spacing is taken care of within the font itself (especially in variable fonts with an opsz axis, like Name Sans Variable).
Somewhat similar to spacing, kerning can be more “aggressive” in larger sizes, but this will cause problems in text. In Name Sans, the height of lowercase letters is subtly adjusted for larger styles to allow nice, tight kerning in words like “Tokyo” and “Type”.
Notable visual aspects of a typeface are often emphasized at larger sizes and moderated at smaller sizes. In a high-contrast serif design, this might mean that thin strokes get thinner for larger sizes and thicker to remain visible at smaller sizes. Similarly, in Name Sans, the ends of the weight range are less extreme for smaller sizes – the Text Hairline & Ultra will remain legible at smaller point sizes than their Display counterparts. More specifics are detailed below.
Some details must be emphasized to hold up at smaller sizes. In a serif design, serifs typically need to be thickened to retain clarity clear in text. In Name Sans, the overall “sharpness” of the design is increased for small sizes, as is exemplified by notches in stems and flat portions of letters (more on this below, as well).

You can start to understand how a typeface handles optical sizing by placing different optical-size styles at the same scale. In Name Sans, this highlights the change of spacing, kerning, proportions, and shaping.

Letter spacing & kerning is optimized along the Optical Size axis for ideal visual impact and reading ease across sizes.

Of course, different optical sizes aren’t really meant to be compared at the same scale – or even really with the exact same content. It is generally more accurate to look at different optical sizes in their intended sizes. For Name Sans, Display is designed for 96pt, Standard is designed for 24pt, and Text is designed for 12pt. In practice, type is a little less exact than that – there are many factors beyond the control of the font size. For example, the distance of the viewer will change the perceived font size, and the exact physical size of fonts isn’t completely standardized across operating systems & apps. So, at the end of the day, even though optical sizing can automatically help designers to achieve more nuanced typography, some amount of contextual judgment will often be important.

Optical Sizes – as their name suggests – are designed to deliver the same visual intent at different scales. Typically, Display sizes are optimized for short names & phrases set at a large scale, medium sizes (like Name Sans Standard) are optimized for headlines, and Text sizes are optimized for running text.

Extremes get a lot of focus in the discussion of optical sizing because they help illustrate design features that might otherwise go unnoticed. However, what happens in the middle is just as important, if not more so. Name Sans Standard, then, seeks to roughly correspond to the sizing, spacing, and proportions of common sans-serif typefaces. If you don’t want to think about optical sizes and just want to do typography as usual, this “Standard” option is designed to work well for you. But, I hope you will consider branching out when projects allow for it – your typography will benefit from the added nuance!

Usage Note

Smaller optical sizes usually have slightly wider line lengths than display sizes. This is because smaller sizes have additional letter spacing and have slightly larger lowercase letters. However, this is not equivalent to a Width axis. If a given space is too small to fit with content in a Text style (e.g. a long address on a business card template), change the font size or the layout – not the optical size.

Geometry, but with nuance 🔗

A striking, prominent trait of the mosaics is that the circular letters are circles. In type, a circle never really looks like a circle, but I’ve iterated a lot to get as close as possible to a circular basis for letters like O, C, G, Q, o, c, and e – while also keep things looking circular in the context of type.

“Keeping things circular” may sound like a straightforward task – almost too basic for discussion. Just draw some circles, right? Actually, it’s not that simple. In well-made type, seemingly circular letters are never actually just geometric circles. Generally, the letter O has to be just a little less wide than tall, and its sides have to be a little thicker than its top and bottom – otherwise, it will look too wide when set in words. Further complicating things, letters like C and G can’t just copy the curvature of the O, or they will look comparatively wider. You can start to see these differences if you start rotating fonts and looking at them sideways. This is true even in the classics like Futura that designers may think of as “purely geometric.”

You might think of Futura as the prototypical geometric sans, with perfectly circular shapes – but it is actually a good example of how even strictly geometric fonts must include subtle optical compensations to look geometric in practice.

Of course, geometric type is not meant to be geometric – it’s meant to look geometric, when in actual use. The way that is achieved will vary from project to project – and like any creative project, the specific solutions will depend on the creator.

If you try to draw a font without compensating for optical issues, it will look bad. Circles will look wide and diamond-shaped, horizontal strokes will appear too thick, and places where strokes join will look overly thick. Correcting for the issues caused by how our eyes perceive type is called optical compensation. It’s an area of type design that is not always intuitive but is essential to engage with when making type.

If you draw a font from only geometric shapes – with no optical compensations – it tends to look bad. The design of a geometric font is largely the exploration of how much optical compensation is needed to meet a particular goal.

I could show how you might adapt the above example into a better font with just a few optical corrections ... but this post isn’t really about that. The point is, once you know the problems to avoid, you can start to evaluate fonts by how they individually solve those problems. There are many good geometric sans-serif fonts in the world; Name Sans is my current entry into the field. Of course, I am not just trying to make the most-geometrically-strict font with Name Sans. Rather, I have sought to use geometry where it works is attractive but not distracting – while also making a font that is versatile, bringing in elements of “grotesque” fonts where they can improve goals like visual consistency and readability.

I doubt it is possible to precisely determine the design goals of the designers of the original Subway mosaics, but my speculation is that they had similar goals: make letters that were geometric, but also natural.

Some fonts prioritize strict geometric shaping, and that can work. But, such typefaces are accepting a trade-off. If a typeface upholds strict geometry over other goals like optical consistency, it will inevitably take on a decorative aesthetic.

One important decision in any geometric font is whether letters like b, d, p, and q are drawn with circular bowls. If they are, it can look attractive but also sacrifices versatility. It will always look a little too art-deco or disco to be used for serious communication. Even though I love typefaces like Avant Garde, this ultra-geometric style basically always communicates some blend of nostalgia and whimsy. This is fine, but it’s not useful for every project.

Therefore, in Name Sans, I have drawn letters like b, d, p, and q to match the visual average width of n and o rather than to look especially circular. This, in turn, helps to establish a visual rhythm that doesn’t call too much attention to itself.

In Name Sans Display, letters like b and d are drawn to match the visual average width of n and o, rather than to look perfectly circular.

Such considerations are also important between different optical sizes. In the Display sizes, the o can be very circular, but in Text, the o must be made much more similar to the width of n to avoid an excessively-wide appearance in running text.

It might be that our eyes are just used to reading certain fonts, and it may be an effect of our eyes rapidly moving horizontally when we read. Either way, anything close to an actual circle will look oblong in running text, so Name Sans accounts for this. Display styles emphasize geometry at a large scale, while Standard & Text styles attempt to look geometric-but-not-distractingly-so.

In Name Sans Text, the round letters are much closer to the width of n. If they were to keep the circularity of the Display styles, they would look like wide ellipses in running text.

If you overlay the o, n, and b, you can see quite clearly that while o is quite circular, the n stays closer to more traditional proportions, and the b falls in between.

Comparative proportions of n, b, and o in Name Sans Display

Even though I want to capture the charm of the Subway mosaics, charm is not only achieved through decoration. Instead, I seek to create something which balances geometry and nuance, in order to provide genuine utility for a wide range of applications. So, in Name Sans, the not-quite-circularity is just as critical as the circularity.

Sharpness 🔗

A subtle thing I love about the Subway mosaics: the vertices of diagonal letters usually don’t simply have a one-stroke width. Instead, they tend to be closer to about two-thirds stroke thickness. This gives vertices a sense of sharpness and visually suggests that diagonal letters are made in a single motion, rather than from separate strokes.

Most sans-serifs take one extreme or the other on their treatment of vertices. Broadly speaking, they either take the Futura route with pencil-sharp points or the Helvetica route of prioritizing evenness of strokes, proportions, and color without really considering vertices. I like that the mosaics take a practical, in-between approach: they have vertices that are slightly sharp and a little bit blunt. Naturally, I have sought to preserve this in Name Sans.

The sharpness of diagonal letters varies between eras of Subway mosaics, but the “endcaps” of vertices tend to be around two-thirds of the main stroke thickness.

Even smaller-scale mosaic signs were made with care. Most of these include partially sharp vertices on diagonal letters that closely match the look of their larger-scale relatives.

The bluntly sharp vertices from the Subway mosaics are carried into Name Sans.

Sharpened vertices come from a slightly different logical basis than many sans-serifs. Rather than suggesting diagonal letters are made from separate diagonal strokes and attempting to perfectly balance the volume of interior spaces – as a signpainter might create them – these paths are suggestive of the way a person with a pencil might write such characters in a single path. They prize repeated interior volumes a little less and show the letters as “single units” a little more.

The sharp vertices give the impression of letters that are “written” in a single stroke, rather than constructed from multiple lines.

I have extended this quality of sharpness to the meeting points of lowercase letters like a, g, n, m, b, d, p, and q. Rather than trying to suggest a single, monolinear vertical stem on these letters, I have borrowed the idea of sharpness to give a little more whitespace to these corners while also avoiding the need to add to much contrast to the strokes connecting bowls. Would the original architects have done it this way? It’s hard to say – possibly not. But, this approach allows the typeface to work together in a way that maintains a sense of sharpness while also remaining a cohesive sense of each letter being a self-contained unit that works smoothly with its neighbors.

Like every aspect of Name Sans, this approach to sharpness is adapted across optical sizes to be ideal at large, medium, and small sizes. As the opsz decreases, the stem sharpness is dialed up to preserve this visual feature.

The lowercase letters borrow the sharp spur from G to carry a sense of sharpness across the typeface. Like most features of the family, this is adjusted between Optical Sizes.

It’s difficult to put into academic terms, but this slight sharpening of stems also gives me a certain feeling of the sharp edges and slight imperfections of the ceramic tiles used in mosaics – even when (or especially when) it’s used for running text.

The construction of Name Sans delivers a visual texture that captures the unique mixture of sharpness and warmth of mosaic tile signage.

Optical compensations both exaggerated and (almost) ignored 🔗

There is so much that could be included when describing the personality of the Subway mosaics – and many divergent examples that could be highlighted. I suspect that any given type designer might pick up on something different.

Mosaic name tablet 2nd Ave – note the vertically-symmetrical B, circular O, short-armed E, and prominent “kick” on the leg of the R

Mosaic name tablet at 96th St – note the circular, symmetrical counters in 9 and 6

For me, though, a core aspect of the personality in the mosaic lettering is the way the optical compensations are handled – beyond just how circles look.

In type, optical compensations tend to follow predictable patterns (at least once you know what to look for). Horizontal strokes are a little thinner than vertical strokes. Joining strokes are narrowed to avoid looking too thick. The bottom “halves” of certain letters are a little bigger than the tops. As mentioned above, “circles” are never really circles. There are these and many, many more techniques that you discover while drawing type.

The mosaic letters often either completely exaggerate or completely disregard conventional rules. The tiles don’t tend to modulate thickness between vertical and horizontal strokes because they are (more or less) square. But also, visually symmetry is handled in unusual ways. For example, the S tends to exaggerate its form by being much wider on the bottom than at the top, while the B sometimes contrasts this with two bowls that completely match in size. The E has a middle bar that is super-short, while the 5 forgoes a typical slanted top-left.

These quirks are some of what make the mosaics so endearing to me. In the context of mosaics, the lettering can get away with a lot of liberties that might look bad elsewhere.

In Name Sans, I’ve had to moderate some of the extreme quirks of the mosaics to make sense in a digital typeface. But, especially in the Display styles, I’ve preserved a lot of the unconventional traits. I’ve kept vertical and horizontal strokes as nearly-monolinear as they can be without looking “reversed.” I’ve kept a taper in the proportions of S. I’ve kept the B almost vertically-symmetrical. I’ve kept a short mid bar on the E. I’ve kept an upright 5. I’ve kept certain whitespaces, like the counter of the n, perfectly symmetrical – except in the lightest styles, where this starts to look asymmetrical. For every visual quirk in Name Sans, there are mosaic letters that led me to make that decision.

Name Sans plays with symmetry and asymmetry in proportions and counter spaces. Larger sizes emphasize visual quirks in proportion, symmetry, and rigidity of the Subway mosaics. Smaller sizes adapt many of these mannerisms into more typical shaping.

The Subway mosaics can get away flaunting convention because they are large and seldom include very much content. In making Name Sans, I have found that the larger optical sizes can come close to matching that uncompromising approach.

Meanwhile, many of the optical conventions bucked by Name Sans Display are normalized a little bit in smaller optical sizes: horizontal strokes get a bit thinner, the S and B become a bit more traditionally balanced, the 5 gets a bit of a slant, and so on. This makes Text styles a little more familiar to read, while still keeping things lively.

A blend of rigidity & fluidity 🔗

Often, the most striking feature of the Subway mosaics is how they seem to defy the physical limitations you might expect of rectangular tiles. The way that letters will gracefully, fluidly curve shows that the mosaic letterers were occasionally just showing off. This is even more striking in the serif styles of lettering and in other signage sprinkled throughout the system, but that is a topic for another project.

A smaller directional sign at an exit from the Barclays Center station, for a church that unfortunately was demolished in 2016. This sign isn’t really a part of my current project, but it is a pretty awesome example of what a skilled mosaic artist can do with letters and tiles.

But also, there are plenty of moments where the grid of tiles is embraced. The rectangularity of tiles influences the letters they form. As you can imagine, the dimensions of tiles often dictate the thickness of letters and the placement of cross-strokes. An even more-obvious obvious example of following the grid is found in flat-sided round letters. In a broader sense, though, the exclusive use of uppercase letters is also an example of the grid of tiles influencing the forms designed. Uppercase letters simply don’t require as many complex curves and details as lowercase letters.

Bottom-heavy S shaping and a leg-kicking, grotesque R at Spring St.

A compact, flat-sided O matched to otherwise (mostly) normal characters at Fulton St.

Without direct examples, I have had to invent a lowercase for Name Sans. In part, I have done so by looking for examples of similar styles of letters in sources from a roughly similar time as early Subway stations. One particular source of inspiration is the 1912 catalog of the American Type Founders. This includes several “gothic” (AKA grotesque) typefaces which, although clearly not the model used for the Subway mosaics, do share some similar ideas. Aside from similar overall letterforms, strict geometry, and low-contrast strokes, some of these gothics include flat portions of letters. These flat portions are placed where curves would normally be “shallow” or used as optical corrections, like the top of the f and r and bottom of the t and y.

Inland Gothic No. 8, from the American Type Founders 1912 Specimen Book of Type Styles. Includes flattened portions of g, t, r, j, and y.

Times Gothic, from the American Type Founders 1912 Specimen Book of Type Styles. Includes smooth counter connections and pairs circular round characters with others with are more compact.

These flat portions or lowercase gothic letters remind me of the flat-sided letters used in some of the Subway mosaics. Seeing them makes me think of how one might realisticaly approach shallow curves in tile mosaics. In Name Sans, I have embraced flat portions of letters, juxtaposing these against other moments of fluidity, geometry, and sharpness. I see this as following the example of the original mosaic lettering. Am I also influenced by ideas from the 100+ years since the first Subway mosaics? This is inevitable in any historical fiction. But, I also suspect that what I’m designing might be fairly unsurprising to a mosaic artist from a century ago.

Flat portions of Name Sans echo the rigid shaping of Inland Gothic No. 8, while also echoing the grid-oriented physical construction of Subway mosaics.

Text styles moderate certain flat segments – like the bottom of the lowercase g – where a bit of added normality improves readability in long-form text.

To an extent, I must admit, the decision to incorporate flat segments was also influenced by certain instances of vinyl Helvetica station signage. I find it endearing that the S has a flat segment in its spine, and that the t sometimes ends in a horizontal tail, rather than its more-typical little upturn. I can’t deny that Name Sans has modern influences – another reason it is an interpretation rather than a revival.

Stylistic Set 1 references the rigidity found in mosaics lettering with flat-sided caps.

“Obviousness” and evolution 🔗

What is “simplicity”? It’s a much-debated question, but – at least when it comes to type – is somewhere between impossible and counterproductive. Is “simplicity” an absolute minimum of shaping detail? Partially yes – but if taken too far, that definition might lead to letterforms without necessary optical compensations, which looks terrible in practice. Is “simplicity” repeating what we are already used to seeing and reading? Partially yes – but if taken too far, that definition would conclude that we already have exactly the type we need and would forgo the possibility of ever making things better than what we already have.

What is “obviousness”? That is a more straightforward question. It assumes an individual perspective, unlike notions of simplicity, which often seek to impose a universal, dogmatic view. What is obvious to one person is not necessarily obvious to another. More importantly, what is obvious is dependent on a given project & context. In designing Name Sans, I have tried to make decisions according to what the obvious, elemental forms of letters are – while also keeping in mind my experience and understanding of the Subway mosaics.

A primary example: the terminal angles and aperture tightness of sans-serif letters have a big impact on the tone of a typeface. What is the most obvious way to handle this aspect of a design? What would be obvious within the mosaics?

In early versions of Name Sans, the apertures of letters like C, S, and a were very “closed” in Display styles, and much more “open” in Text styles. The logic was that, with tighter spacing in the Display styles, tighter apertures kept letters more self-contained. But, as I contended with coming up with an explanation rooted in actual examples from Subway mosaics, I had to admit that this solution was too much of an invention of my own. I was too closely following type trends of the last few years – these tight apertures were hardly something that would be obvious to the folks making signs many decades ago.

So, I adjusted my terminals to be at a more obvious placement and angle. I prioritized what would make strokes appear to end with square terminals at a roughly 45° placement – using my eyeballs rather than an actual measurement. This small adjustment made the characters in Name Sans much more similar to the overall appearance of Subway mosaics.

In earlier versions of Name Sans, opening shapes of many characters were tight, in response to other popular & historical grotesque typefaces. They have since been widened to more closely reflect observed lettering of the NYC mosaics.

There are a few exceptions to the open apertures. The Black & Ultra weights, which are pretty unabashedly of my own invention, exaggerate the system into purely display territory. Here, the apertures do close off to avoid overly large whitespaces in text. Likewise, some tabular figures are fairly wide across all weights, so numbers like 2 and 3 have more-horizontal terminals in their tabular versions.

Apertures were opened up – but only a bit – in Ultra weights. Counters were adjusted from circular to elliptical shaping to present of more-serious tone.

An example, though with slightly different logic, is the way lowercase are constructed. These have joints that have smooth rather than sharp connections. Because the lowercase had to be invented from a relatively-sparse set of examples, one of the bigger decisions of the project was whether to connect bowls to stems with a smooth connection, as in “neo-grotesque” fonts like Helvetica, or whether to connect these with sharp connections, more in line with more “humanist” gothic fonts like Franklin Gothic.

Uppercase letters don’t have that many opportunities to show this decision. The G does have such a joint in some forms, but on the whole there are few connections that relate to the more “handwritten” logical basis for the Latin lowercase. However, numbers offer a few more opportunities for insight into what might be natural for the typeface.

The problem is, there are numbers in Subway mosaics that suggest both strategies. 8th Street uses a number 8 that has a humanist construction – a “single path” in a rotated ∞ shape. Meanwhile, 96th Street has numbers with delightfully-circular counters – more of a grotesque approach. So, while you might expect the mosaic artists to only create shapes that were convenient to lay in tile (presumably, humanist forms without smooth joints), they show time and again that they were interested more in aesthetics than in convenience.

Because these numbers existed as direct examples, I have chosen to follow both potential routes – Name Sans includes a 6 and 9 with circular counters, but bucks the typical geometric-grotesque approach, using a typically humanist form for 8.

While many numbers and letters in NYC Subway mosaics fall under shapes that would be categorized as “grotesque,” there are also examples like this 8 which follow more “humanist” tendencies.

In a nod to the subtle variety of lettering styles in NYC mosaics, the 6 and 9 of Name Sans have a “grotesque” structure with smooth counters, while the 8 has a more typically “humanist” construction, as if written in one smoothly-curving path.

But again, the lowercase did not have precedents, and therefore, I simply had to choose what looked more obvious in text. I will freely admit that, because I spend hours of every day reading fonts like Helvetica and Apple SF, my eyes are biased. It could be that I chose to follow these examples because I found them visually familiar and knew others would as well.

Excuse me while I get a little bit theoretical

I do have a theory of why smooth-joined lowercase forms have “won out” in so much of today’s typography: with smooth connections, letters feel like self-contained units. When it has a smooth connection between its steam and its bowl, a character like n is a single shape in and of itself, even though it has a complex shape. If, however, an n has a sharp connection, it presents itself as two shapes connected.

It’s not that I think smooth connections make letters “self-contained” at the expense of forming cohesive wordshapes for reading. I still hold the ideal that “A typeface is a beautiful collection of letters, not a collection of beautiful letters.” (Thanks, Matthew Carter!) I am also not disputing the value of a humanist construction for letters. Rather, this is my understanding of why smooth connections help give a font a stable, sturdy presence, while sharp connections tend to present more of an active, forward-moving tone. Both approaches have merits, and both strategies (if executed well) can lead to highly-readable type.

Earlier versions of Name Sans Text included sharp joints on many characters. These were ultimately smoothed out to better match the aesthetics of Name Sans Display at smaller sizes and to maintain high-quality outlines in intermediate styles.

The idea of considering letter construction as rooted in physical tools isn’t my own. In reality, the theory is really just my extrapolation of Gerrit Noordzij’s theory of The Stroke. In The Stroke, Noordzij argues that most type can be thought of as originating in the strokes of a writing tool. Noordzij breaks this down into categories which include expansion (in which the stroke’s width modulates according to pressure, as exemplified by a pointed-nib pen) and translation (in which the stroke’s width modulates according to a pen’s orientation, as exemplified by writing with a flat-nibbed pen). In expansion writing – the structural basis for typefaces from Didot to Helvetica – the pen makes the core of most letters which a single stroke, traveling down, up, over, and down, allowing for continuous strokes with smooth joins. In translation writing – the structural basis for typefaces from Palatino to Verdana – the pen only travels in a downward or sideways direction, lending to separate strokes with sharp joins. (Rotation is another category mentioned. But, as with any model, Stroke Theory is a simplification. The reality of writing is much more complex, and fascinating concepts like single-stroke signpainting and brush calligraphy – which mix expansion, translation, and rotation – are mostly left out. Still, it provides one useful perspective by which to consider the design of letters.)

Translation vs Expansion models of type, as shown by Name Sans Text in versions 0.3 vs 0.5

A much more basic explanation is possible, too: sharp connections add extra angles to letters, which add up to more visual complexity on the zoomed-out level of words and text. In the case of Name Sans, it feels best to avoid this type of visual complexity.

(Just in case anyone is reading this and happens to be considering font defaults for document-creation software: In the case of a font intended for books or multi-page documents, I would instead lean towards a humanist model. Perhaps this is also because I am used to that, but perhaps also because its dynamic presence helps my eyes maintain forward momentum in text when there is truly a lot of it.)

All that is to say: Name Sans might have a smoothly-joined lowercase because this style is perpetually popular and I am crassly chasing after money (I am running a business to sell a product to buyers, after all). But, Name Sans also has a smoothly-joined lowercase because it relates back to the idea that each letter should be a single, self-contained unit, so that the typeface as a whole can have a stable, direct voice. Either way, this is the obvious choice – at least for this project.

A varied but harmonious set of possibilities 🔗

The thing that made this project “impossible” – the diversity of styles and forms in the Subway mosaics – is something I have worked to bring into the project through its range of styles, its nature as a variable font, and its OpenType features.

Stylistic Sets are an option that a font can include to allow users to activate various stylistic variants of characters, like (depending on the typeface) a single-story a or serif I. Stylistic sets can be something of a sore subject to type designers, because these extra features can make a project (sometimes significantly) harder to complete – and then often go totally unknown to the actual users of a font. (This is partly due to their often-terrible UI in design software.)

Some type designers will even suggest that stylistic sets indicate a lack of decisiveness on the part of a creator, almost to the point of it being a moral failing to include too many of these options. “Pick the best letterform for each character and stick with it,” they advise, “that’s your job as a type designer.”

There is certainly some merit to pushing back on overly-enthusiastic inclusion of stylistic sets and features for the sake of features. But, sometimes, it’s nice to have a tool that can be adapted to the needs of different jobs.

In the case of Name Sans, I would see it as a major missed opportunity to disregard the many, many stations that have rectangular caps for their mosaic signage. So, rectangular caps can be activated with Stylistic Set 1.

I would also see it as a missed opportunity to not bring in my favorite leg-kicking R from stations like Spring Street and Bowery. But, I have had to face the fact that an R with a curly leg doesn’t always work, and probably doesn’t work most of the time. It’s often just too interesting, to a fault. So, the default R of Name Sans has a simple shape with a straight leg, while the cooler “grotesque” form can be activated with Stylistic Set 2.

On top of all that, there are several stylistic sets that are just nice to have in any geometric sans. There is a single-story a and a double-story g, plus simplified versions of t, j, and y.

A type tester is available at name.arrowtype.com to help preview some of the typographic features and stylistic sets of the family.

Size-specific letterforms

In earlier versions of Name Sans, the Optical Size axis automatically switched between forms of characters R, I, g, and l, opting for the forms that worked best in most Display vs Text scenarios. This deliberate inconsistency was partly a nod to old grotesque typefaces that included very different letterforms in different “cuts” (literally, different styles of wood or metal cut for different widths and sizes).

In previous versions of Name Sans, there were stylistic sets to turn off this size-specific swapping behavior. In v0.5, however, I have opted to keep a single set of defaults across all sizes – with stylistic sets to turn on the automatic swaps.

Why the change? For one, having stylistic sets to turn off behavior got very confusing to coordinate between variable and static fonts – even for me, as the font maker. But also, I had to be honest with myself: if I were a graphic designer using an unfamiliar font, I would probably be confused (and maybe a bit annoyed) if it had a few letters that radically changed shapes at different sizes.

At the same time, as a type-minded designer, I really like having a font that changes shape for different sizes. It’s useful if small or running text has a more-recognizable g. It’s pretty cool if a headline has a wonky R. So, for folks who want to use Name Sans in this kind of “expert” mode, Stylistic Sets 19 & 20 will turn on these size-specific substitutions.

Optional size-specific forms are available in Stylistic Sets 19 & 20 – and automatically activated by Optical Size in Name Sans Variable.

Extra quirks worth mentioning 🔗

In the mosaics, the Z (when it does appear) tends to have a little angle at the bottom right, even though this calligraphic touch isn’t found in any other uppercase letter. I’ve kept this in Name Sans. To carry this trait into the system just a little further, I’ve matched this adapted this angle for the top of the t.

In Stylistic Set 1, Rectangular Caps, the U has a bottom which is more square than the bottoms of letters like O that you’d think might match. Again, this comes from mosaic examples.

In the bolder Display styles, the y has a smooth connection between from its left side down to the descender. This is straight off of Helvetica – even though it’s a bit tricky to incorporate into the family because it must swap to a sharp connection in lighter weights, it looks too nice to leave out.

Name Sans sneaks in a few extra quirks from the Subway mosaics, like a calligraphic exit stroke on the Z (echoed by the t) and a flat-bottomed U in Stylistic Set 1. An alternate ß, in an “tailed-z” form borrowed from Berlin street signs, is also available in Stylistic Set 10.

Simply put, Name Sans is not an accidental design. Every visual aspect of it ties back to mosaics (or occasionally newer) signage in the Subway. I am still learning, and there are still a few decisions that I am turning over in my head and in my sketches, but I am becoming more certain that I have found the right way to balance the many influences of Name Sans into a varied but cohesive type family.

There’s so much more, but... 🔗

Like Name Sans itself, this blog post is only a partially-complete draft. There is so much more I could say about the typeface, the ideas I have tried and abandoned, and the things it can do. Some of these are better outlined in the PDF Specimen and in the slides on Future Fons. But also, I am still in the midst of discovering what Name Sans is! To me, that’s the fun of it.

There are a lot of things I know at this point: I am working on Italics along with a few more typographic features, and I will continue to refine shaping, spacing, and kerning across the project.

(Spoiler alert: the italics will be pretty boring. They may have a single-story a on by default, but will otherwise be a sloped (and optically corrected) version of the uprights. I am working to keep these as geometric as possible, so they can work seamlessly with the intent of the family as a whole.)

I plan to finish and fully release a 1.0 in the coming months. When I do, I plan to also release a refined version of this essay.

So, if you managed to actually read (or even skim!) this post and have any questions for me, please let me know.

If you’ve already picked up a license for Name Sans, I really appreciate you coming along for the journey! If you haven’t, it’s still at a greatly reduced price while it’s in pre-release (if you do the math, it’s currently about $4.03 per style). By purchasing a license through Future Fonts, you will be securing future updates for free, for life. If you do pick up a license, I hope you reach out to me if you put Name Sans to use! I love to see when people get value out of my type – it makes this whole, slightly ridiculous effort feel worthwhile.

Oh – and finally, please subscribe to my newsletter if you’d like to be alerted when Name Sans 1.0 is released. There just might be another 8,000-word treatise on geometry and historical fiction along with it.

Footnotes

The Latin Script is the writing system familiar to anyone who writes English, Spanish, German, French, or any other language using a similar A–Z alphabet. And actually, Name Sans does go beyond the character set of many fonts, with a total of 728 glyphs which support over 200 languages used through Europe and the Americans, plus Vietnamese. ↩︎
The idea of typefaces as “raw materials” is borrowed from Klim Type Foundry’s article A typeface is not a tool. Of course, a typeface is both a raw material and a tool, but that debate is for another day. ↩︎
Wikipedia: NYC Subway History ↩︎
Wikipedia: Heins & LaFarge ↩︎
The OpenType Specification is the technical spec which defines the underlying structure of modern digital fonts. ↩︎

Hosting licensed fonts on AWS S3 for open-source websites

2021-01-27T00:00:00Z

In some situations, you may need to use a font on the web, but may not be able to host it alongside your web code. In this case, you can host the font on AWS and call it in as a URL in your @font-face CSS!

For example, you may wish to use a web-licensed font with a project that is openly-hosted on GitHub or with a project made on a service like CodePen or JSfiddle. If your font license allows it, this can be a nice solution to an otherwise tricky problem. Note: licensing will vary between typefaces and type foundries – read your license or email the type foundry if you aren’t sure!

With the S3 Buckets feature of Amazon Web Services (AWS), this is relatively easy & very inexpensive – unless you are making a hugely-popular website, perhaps. You can (and should) configure it to only work on specific web domains, so you don’t break your licensing or end up paying for other people to use your font hosting! Here’s how.

Make your S3 Bucket 🔗

Register for AWS, then Sign into the Management Console, search for buckets and click on Buckets S3 feature
Click Create Bucket
Give the bucket a name (e.g. arrowtype) and select a region that you think is closest to you / most of your users
Uncheck Block all public access and check the box for “I acknowledge that the current settings might result in this bucket and the objects within becoming public.”
Maybe enable versioning
Scroll to the bottom and click Create bucket

Upload your font 🔗

Go into your new bucket, and click Upload then Add files, then select and upload your woff2 font file.
Click on the file within the bucket, then find Object actions > Make Public, so you can access this from your CSS later (don’t worry; the next step will prevent other sites from using it)

Edit CORS on the bucket 🔗

Navigate back to the top level of your bucket
Click the “Permissions” tab.
Scroll to the “Cross-origin resource sharing (CORS)” section, then click Edit.
Set CORS permissions to allow your specified URL(s) to access the objects in the bucket, similar to the JSON shown below.
- You can use a wildcard (*) to allow subdomains, like https://*.arrowtype.com.
- I also include http://localhost:8080, the URL which my local-development builds get served to. Replace this with the localhost port number(s) you need to support.

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET"
        ],
        "AllowedOrigins": [
            "https://*.arrowtype.com",
            "https://arrowtype.com",
            "http://localhost:8080"
        ],
        "ExposeHeaders": []
    }
]

Get your font object’s URL 🔗

Go back into the bucket’s “Objects” tab, and click on the file name of your font.
Find and copy the “Object URL,” which will look something like https://arrowtype2.s3.amazonaws.com/name_sans-variable.woff2.

Note: because of the CORS configuration for this URL, you can’t use it on other websites, though you could use it in local development if you really wanted to ... but honestly, please just buy your own license if you want to use it – while it’s still in early access, it’s available at a steep discount! Or, use another font – there are many great type options in the world, both free and paid!

Set your CSS so local fonts don’t interfere with your development 🔗

In your CSS, you can use a font’s basic family name in order to just use a local copy of that font. This can make fonts appear more quickly for users, if those users already have that font on their system. However, especially with newer fonts, this may cause problems. How do you know that your users will have the latest version of a font? Often, the OS will serve an unintended font style, even if it does have the latest version.

So, I often make sure to use a name that specifically won’t call a local file. I do this either by removing spaces or adding a suffix like ”VF“.

@font-face {
  font-family: 'NameSansVF';
  font-weight: 1 1000;
  src: url("https://arrowtype.s3-us-west-2.amazonaws.com/name_sans-variable.woff2");
}
html {
 font-family: 'NameSansVF', sans-serif;
}

Your font should now work locally and also in deployment. Of course, the only way to know is to deploy the site and test it on a few different devices!

Additionally, the font is (relatively) safe from being directly used on any site that just copies your CSS. You can verify this out by trying it on CodePen, where it shouldn’t work (unless you allow CodePen URLs in your CORS settings).

To update the font 🔗

If you need to update the font version on S3 in the future, you can simply repeat the process of uploading a file.

Just remember to also follow the Make Public steps, or things will break!

But what if fonts were already in a public Git repo? 🔗

This is a pretty big problem, but luckily, it’s not too hard to fix.

You can use a tool called BFG to remove them – even GitHub recommends this tool.

Make a backup copy of your project before using the BFG, in case you mess something up!
Download the latest release from the BFG website.
Open a terminal, navigate to your project’s root, point to the downloaded BFG file, and use the --delete-files option to delete the font filename you’d like to keep private:

cd ~/code/blog-11ty # change to the root of your web project
java -jar ~/Downloads/bfg-1.13.2.jar --delete-files name_sans-variable.woff2

Use git push --force to force push the edited Git history to your repo.

Happy webfonting! 🔗

This specific workflow is fairly new to me. Did I forget to describe a step? Did I say anything inaccurate? Feel free to let me know! I’m on Twitter, and this blog has open Issues on GitHub.

Getting the most out of RoboFont

2020-12-11T00:00:00Z

Type designers are lucky to have a variety of extremely-capable tools for creating new fonts. My favorite of these is the font editor RoboFont, along with its ecosystem.

I covered some of the reasons I like RoboFont in my earlier post, Getting Started in Type. This post actually started as a section of that article, but I have since realized that I would like to add more extensions and more details. If you haven’t already read that article, there are lots of helpful tips there, so consider giving it a look, too!

First things first 🔗

Like most powerful software, RoboFont has a lot of functionality, and you will save time by doing a bit of reading before diving in. It is extremely useful to get familiar with the RoboFont Docs (even if you just skim parts of it at first). If you are new to RoboFont or just wondering what it’s all about, start with the RoboFont Introduction.

As a new user, you will probably want to define the default character set for new fonts. Here’s how. Glyph Browser, an extension mentioned below, further extends this part of the process.

My favorite RoboFont extensions 🔗

Extensions are a big part of the RoboFont experience. Most RoboFont extensions can be found on Mechanic.

You can get more-detailed documentation about RoboFont extensions at robofont.com/documentation/extensions/.

However, it can be overwhelming to know which extensions are available, and which ones you actually want to use. After working for about three years almost daily in RoboFont, here are the RoboFont extensions that I find most useful.

Mechanic, by Frederik Berlaen and Antonio Cavedoni

Mechanic is an easy way to manage (most) RoboFont extensions. It’s pretty essential, as it allows you to easily find and install most of the other extensions listed here. Extensions mentioned below but not available via Mechanic are linked to, but the ones not linked to are simplest to find & install via Mechanic.

Add Overlap, by Alexandre Saumier Demers

Adds corner overlaps to selected points. I like Okay Type’s fork of this, which adds a little UI at the bottom-right corner of Glyph Windows which allows positive, negative, or zero overlap to corner points.

Add Segment Guideline, by Jan Šindler

This is a very simple but useful way to add a guideline to a selected segment. I’ve set it to the shortcut Command /, and I use it constantly – especially when drawing glyphs with diagonal strokes.

Batch, by Frederik Berlaen

This is a simple UI to help you build fonts from RoboFont. I do almost all of my font builds with FontMake, but this is a whole extra skill to learn, and probably not necessary for every font project.

CornerTools, by Loïc Sander

Want to add a bunch of rounded corners or inktraps to a font? This is a fast way to do it! This is a super nice tool to modify corners. Read the project readme for instructions.

DesignSpace Edit, by Erik van Blokland

This will help set up and edit correctly-formatted DesignSpace documents that you can build with Batch or FontMake, for font projects involving interpolation to create static instances and/or variable fonts. I often start here to make a new DesignSpace, then use a code editor to make edits more efficiently.

EditThatNextMaster, by Erik van Blokland

A common early complaint about RoboFont is that it’s a bit tricky to move between sources for a multiple-master font project. This solves that by assigning a hotkey to move between views of open UFOs.

Eyeliner, by Ryan Bugden

Simple but essential: this makes it easy to see when a point is on a guide or metric line.

Glyph Browser, by Erik van Blokland

This is an essential tool to make it easy to add specific glyphs with correct unicodes & naming. It allows you to either search by typing a glyph name (e.g. paragraph or by character (e.g. ¶).

GlyphMirror, by Rafał Buchner

This draws mirrored versions of your drawing in a background visual, and these can be flipped in different ways and moved around. This makes it fast and easy to achieve and check symmetry, when you want it.

Properties, by Jérémie Hornus

This displays distances between selected points, lengths of selected segments, and more.

Overlay UFOs, by David Jonathan Ross

This displays glyphs from the same or other open UFOs while you draw. Helpful to draw and check related shapes within a single font (e.g. n and h), to check related shapes between different sources of a big project, and to have a guide for shaping in less-familiar characters.

Outliner, by Frederik Berlaen

THis is helpful if you want to draw a single line, then expand it, e.g. as a quick way to start a Comic Sans-style font.

Popup Tools, by Tal Leming

This is a little pop-up panel that allows the alignment & distribution of selected nodes & contours. It’s something I’ve wanted maaaany times, especially as someone who has spent a lot of time in design tools like Figma, Sketch, & Illustrator, where I used these functions constantly. But, I got so used to drawing without it, I am not yet sure whether it will be something I use a lot.

Ramsay St, by Frederik Berlaen

This will show related glyphs in the glyph view, on either side of the glyph you’re currently drawing. I used it a lot at first, but I hardly ever use it now – I’ve moved to using the Space Center quite a bit more for this purpose.

ScalingEditTool, by Timo Klaavo

This is a super-necessary tool to move points in a way that is less disruptive to attached curves. You kind of have to try it to understand it, but when I draw, I constantly go between the default Edit Tool and the Scaling Edit Tool. (In fact, the ease of shifting between tools with number keys is one reason I enjoy drawing in RoboFont! It’s weird at first, but much more ergonomic once you get used to it.)

ScaleFast, by Loïc Sander

This one is extremely awesome for scaling glyphs to speed up the process of making things like superiors & inferiors, small caps, legal symbols, and more.

Shape Tool, by Frederik Berlaen

It’s sort of hilarious that this isn’t built into RoboFont, but it also says something about the thinking behind RoboFont as a tool. This extension lets you draw circles/ellipses & squares/rectangles. It’s not built into RoboFont because you might want to tweak the circle-drawing algorhythm yourself, e.g. to draw the slightly-boxy “circles” necessary to make a geometric font that actually looks circular (I haven’t done this, but I probably should try it sometime).

Space Station, by Tal Leming

I only just discovered this one, but it’s a godsend. It enables you to allow a systematic approach to spacing. A really useful aspect of it is that it allows you to import/export simple configuration files, which have a simple syntax which makes it easy to say which glyphs should match the sidebearings and/or widths of which other glyphs. Instead of approaching the problem in a way that is too automated, it encourages you to think systematically about spacing, and is easy to use either purely as a reference/quality-control tool, or as a way to quickly cascade spacing adjustments through a whole font.

Speed Punk, by Yanone

This is one way to consider the smoothness of curves.

Theme Manager, by Connor Davenport and Andy Clymer

This makes it easy to control your drawing theme. I use it to switch between light & dark drawing modes (more info below), to keep my eyes happy at night.

word-o-mat, by Nina Stössinger

This allows you to create strings with desired characters in the Space Center, in order to judge your glyphs in context. Really, really handy.

Paid extensions 🔗

A few very good extensions are complex software in their own right, and these must be purhcased separately. This allows the developers to provide support and to maintain these products, and because these are pretty critical pieces of my workflow, I find that to be a very good deal.

MetricsMachine

Extremely worthwhile, to help with kerning. If you get this, MM2SpaceCenter is a nice (free) add-on extension to give more context in the Space Center as you work on kerning.

Prepolator

Very worthwhile if you are working on fonts which you plan to interpolate. A new version of this is currently in the works, and it automates the process a lot more. It is amazingly helpful for an otherwise annoying task.

Skateboard

Extremely helpful for planning & designing variable fonts.

Additional macOS apps that are especially useful with RoboFont 🔗

VS Code is an excellent code editor, file explorer, Git client, and terminal, all built into one elegant package. I nearly always have a project open in a VS Code workspace while I’m working in RoboFont. This is entirely optional, but if you’re doing a mix of scripting, font building, and Git versioning, it is so handy to one place to many all these technical bits.

Paste gives you access to your Clipboard History, which is helpful in many situations (email, code, interface design, etc etc), but also handy in RoboFont. You can copy a couple of contours, then (if you remember the order you copied things in) paste them as needed. Hard to explain, but very handy.

Divvy allows you to easily set the sizing of windows without dragging things around manually. This is helpful in lots of scenarios beyond type design, but especially nice in a multi-window app like RoboFont. Set up some global shortcuts to make this even quicker! There are other "window manager" apps for Mac, but this one offers my preferred balance of simplicity and power.

Dark Mode in RoboFont 🔗

Sometimes, it’s nice to work in the evening without blasting your eyes with a ton of bright light. Luckily, RoboFont settings allow you to get a pretty serviceable dark mode in two steps:

You can use this script as a “Start Up Script” (see script for instructions) to automatically set a light/dark mode each time you start RoboFont, based on your macOS preferences. If you change the macOS preference and want to update light/dark mode, you can also run the script without restarting RoboFont.
If you also want a dark mode for the Glyph View (if you want dark mode, you will want this too), you can also install the Theme Editor extension, then use my “Dark Connor” theme or make your own.

Three drawing tips 🔗

So much can be (and is) written about drawing type, but here are two things that aren’t as obvious:

Most of the time, it is helpful to work with the Glyph View and the Space Center side-by-side. Use Divvy (mentioned above) to set up 50% of your screen with a glyph, and the other 50% with the Space Center, then adjust the glyph while keeping an eye on the glyph in the context of spacing strings, at different scales, and/or more! I didn’t do this for a long time, but then I picked up the tip from James Edmonson (OHno Type Co) on Instagram, and it changed my life.
Get familiar with using the Transform (T) tool, along with the modifier keys. This can be very unintuitive at fist, but becomes pretty powerful over time. I will try to make a video or say more about this at some point, because it can be easy to miss but seriously helpful.
A really handy feature of RoboFont (especially for early-stage drawing & exploration) is the Test Install, which allows you to quickly install the font you are working on, then immediately use it in other apps to test it out, make proofs, etc. Sometimes, this won’t work if you have special feature syntax in the “Features” tab. I often use minimal to no features here, then add them in a separate build process. But, this varies a lot from project to project.

Ask for help! 🔗

If you get stuck on a problem, chances are, someone will be happy to help you out. Sometimes, just the act of clearly writing out your problem will help you solve it on your own! This applies to basically all aspects of computers and software, but is particularly true in learning & using RoboFont and its associated tools.

Generally, if you run into an unexpected issue, open the Output Window (Python > Output Window, or Option+Command+o) and check for error messages.

The RoboFont Forum has lots of existing questions & answers, and new questions are welcomed, and generally answered pretty quickly!
Google your errors (if you have an error message, try pasting in the relevant part – usually the last line or two)
Use GitHub Issues (this can be a little more advanced; try to find the relevant repo for a particular tool, if you have an issue with it)
Twitter has it’s problems, but you can also learn a lot from the people there. You can mention me, @ArrowType, and I will either try to chip in or mention someone who might know more.
Type Crit Crew is a collective of type designers (myself included) who have made free office hours bookable by folks who are seeking type critique or advice. Getting critique and talking with experts can be a bit daunting, but folks here are super kind, and you can learn so much in this way!

Happy RoboFonting! 🔗

There is a lot more that could be said about RoboFont, but hopefully this post is able to help you learn a few useful things you didn’t already know. Enjoy!

Exploring Higher-Order Interpolation

2020-11-08T00:00:00Z

Ever since Underware Type started exploring what they call HOI (Higher-Order Interpolation), I’ve been amazed by the creative possibilities of this approach to interpolation, and I’ve wanted to try it myself.

For a long time, I didn’t get it. Then, I started to understand it, but felt like actually making it work would be nearly impossible (or super inefficient, at best). But, I’ve taken another look and got a functional test working, so I’ve documented & shared my findings. I still feel like it would be nearly impossible to use in designing full typefaces. So I am doubly impressed that Underware has made it work, and hope that Underware will succeed in licensing their internal tools to allow others to put HOI into practice as well.

→ Full post at github.com/arrowtype/NLI-test

→ Web demo of NLI in variable TTFs

Setting up FontForge on a Chromebook with ChromeOS and Linux

2020-11-01T00:00:00Z

You might think you have to spend a lot of money on a powerful Mac computer & software like Glyphs or RoboFont to get started in type design. While these things are very nice, it’s not a requirement. Instead, you can get a Chromebook for about $150 to $250, then use open-source software like FontForge.

Set up Linux (beta) 🔗

Not all Chromebooks will be able to run Linux out of the box, so check out the supported devices before buying a Chromebook, if this is a thing you are seriously considering doing.

To quote the official ChromeOS Linux instructions, here’s how to install Linux on a Chromebook:

At the bottom right, select the time.
Select Settings.
Under "Linux (Beta)," select Turn On.
Follow the steps on the screen. Setup can take 10 minutes or more.
A terminal window opens. You have a Debian 10 (Buster) environment. You can run Linux commands, install more tools using the APT package manager, and customize your shell.

Install Flatpak 🔗

Note: to copy on a Chromebook, use Control+C. To paste in the terminal, you must use Control+V, then right-click on the terminal.

First, follow the instructions to install Flatpak on ChromeOS.

Note: for step 4 of the instructions above, you will probably have to add sudo to make it work:

sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Install FontForge 🔗

Then, install FontForge:

sudo flatpak install flathub org.fontforge.FontForge

Note: If you run without the sudo, you might get an error like this:

stephen@penguin:~$ flatpak run org.fontforge.FontForge
error: app/org.fontforge.FontForge/x86_64/master not installed

Off to the races! 🔗

For tips & resources on getting started in type design generally, check out my blog post Getting started in Type Design (and possible next steps). This advice does skew towards Mac & RoboFont, but it also includes some useful information about type design & development in general.

For guidance specific to using FontForge, check out fontforge.org/docs/tutorial.html and Designing with FontForge.

Making better zips

2020-08-25T00:00:00Z

Making zip files from folders is a very common and very handy thing to do – so often, sending someone one file beats sending a whole collection of files! But, if you’re only ever making zips on a Mac, you may not realize that you’re also zipping up a few metadata files, and that these might confuse (or at least annoy) folks on other operating systems.

The Problem 🔗

I only learned this recently: if you are on a Mac and make a zip of a folder in a regular way (e.g. by right-clicking a folder, then selecting ‘compress’, or with a basic usage of the zip command-line utility), it includes obnoxious, unnecessary files for folks that decompress those zips on Windows computers.

The top level will have an empty _MACOSX folder
Every other level will have a .DS_Store file

The _MACOSX folder is often empty, and multiple sources point to it being a resource fork, without really saying why it ends up in zips. (If someone knowledgable would like to explain this to me, feel free!) For the purposes of this post, it is also unnecessary to say what it is or why it ends up in zips, other than that it does, but that it doesn’t need to be there.

The .DS_Store saves your preferences for file viewing in Finder, such as the placement of files in the “icon” view or the sorting in the “list” view. However, these generally aren’t very helpful in zipped folders, and if you send these zips to Windows users, they are especially unhelpful.

A command-line solution 🔗

To avoid this, you can compress a folder on the command line. Use cd to navigate to its parent directory, then use this command (replacing arrowtype-name_sans-v03 with the appropriate folder name):

zip arrowtype-name_sans-v03.zip -r 'arrowtype-name_sans-v03' -x '*/.DS_Store'

This command is somewhat unintuitive and may not work as expected if you change or leave out the single quotes. The best way to be sure it worked as you expect is to try opening it in Windows (whether on an actual PC or via a virtual machine using software like VMWare or Parallels).

One good way to avoid remembering this or worrying about syntax is by automating it with a shell function in your shell profile.

Automating it with a function

The function below will make a clean zip if you call if with a path, like zipit path/to/folder.

function zipit {
  currentDir=$(pwd)                             # get current dir so you can return later
  cd $(dirname $1)                              # change to target’s dir (works better for zip)
  target=$(basename $1)                         # get target’s name
  zip -r $target.zip $target -x '*/.DS_Store'   # make a zip of the target, excluding macOS metadata
  echo "zip made of " $1                        # announce completion
  cd $currentDir                                # return to where you were
}

It may seem a little bit complicated, but due to the way zip works, it is best to change to a target’s folder before zipping it.

Of course, it is worth making sure the terminal has this function in memory for it to work, so you should store this in your .bash_profile file (or .bashrc, depending on your approach). Then, you can call it from any terminal session.

The Result 🔗

When you exclude the .DS_Store files, it avoids both problems, and the result is much cleaner:

An easier solution 🔗

I mentioned this article in a Twitter thread, and several people mentioned the approaches they take to this problem.

A notable easy solution is Keka, which is a native Mac app which can make clean zips, password-protected zips, and more. So, if you have $2.99 and you want a solution available via right-click or drag-and-drop, this is probably worth it.

Of course, if you are already using a shell script to set up a build, the function may be the simplest & most efficient way to do this. ~~Or, if you are using a Python-based build flow, that also got a reply in the thread.~~ This comment was later deleted, after Twitter was ruined by a certain shithead billionaire. If you are looking for a Python approach, here’s a GitHub Gist with a quick attempt (feedback is welcome!).

Happy zipping!

Getting the Most Out of Variable Fonts on Google Fonts

2020-08-01T00:00:00Z

I’ve been following CSS-Tricks for many years, so I am very excited to have finally written an article for publication on the site.

TL;DR: You can do a lot more with Google Fonts URLs than you might think, especially if you’re calling in a variable font like Recursive. This article explains what is possible and shows how to craft custom Google Fonts API calls (which is a lot less scary than it sounds).

css-tricks.com/getting-the-most-out-of-variable-fonts-on-google-fonts/

An Intro to FontTools

2020-06-16T00:00:00Z

This tutorial was made for a presentation at the 2020 Typographics TypeLab.

It exists in its own repo at:

github.com/arrowtype/fonttools-intro

Using DrawBot in VS Code

2020-06-15T00:00:00Z

This tutorial was made for a presentation at the 2020 Typographics TypeLab.

It exists in its own repo at:

github.com/arrowtype/drawbot-vscode

Creative Explorations in Variable Fonts – A Type@Cooper Lubalin Lecture

2020-05-12T00:00:00Z

The Lubalin Lecture Series from Type@Cooper has been one of my favorite parts of NYC ever since I first moved here in 2014. They include thoughtful lectures from many of my favorite designers, technologists, and historians in type design. They are free to attend, professionally recorded, and posted online for anyone to watch for free.

I was really honored, then, when I had the chance to deliver a Lubalin Lecture of my own. One challenge: it was originally scheduled for early 2020 (not the best time for in-person gatherings), then moved to May 2020 as the very first online-only Lubalin Lecture.

I spoke about the current state and future possibilities of variable fonts, my background as a designer, my current projects, and the design & development process behind Recursive.

In my lecture, you can probably hear a bit of uncertainty about the state of the world, the state of myself, and of the process of recording such a video for a future, remote audience. All the same, I’m proud that I could record & share some of what I had learned up to that point, and I hope it helps others to hear the experience of someone who is still at the (relatively) early stages of learning in type design.

Best of all, I’ve really enjoyed seeing how the lecture series has evolved since my own. A couple of favorites:

Here’s the lecture 🔗

Creative Explorations in Variable Fonts with Stephen Nixon from Type@Cooper on Vimeo.

Getting started in Type Design (and possible next steps)

2020-05-01T00:00:00Z

So, you’re interested in type design, but you are still figuring out how & where to start or get to the next step. This post is a non-exhaustive attempt to share an overview of how you might learn some basics, how you can get started with font editing software, and where you might consider growing your skills after that.

This post reflects my bias and (some of) my personal experience, and it completely skips important topics like formal education, calligraphy, sketching, bezier drawing tips, and more. But, I have a lot of thoughts to share on beginner (and intermediate) resources, so this post will serve as an evolving collection of those thoughts.

General learning 🔗

Useful Internet resources

The format of this post is somewhat informed by James Edmonson’s (Ohno Type) blog post Getting Started in Type Design. It includes some useful topics I haven’t included in this post. Also, The next two resources in this list are borrowed directly from it.
- Spacing & Proofing, also by OHno Type, are two excellent, practical posts for subjects beyond drawing that are super significant to good type design.
- More recently, The Ohno Blog added the excellent Ohno Type School series. I don’t fully agree with 100% of the opinions offered within it, but Ohno is brilliant, and this series is crammed full of entertaining jokes and useful insights.
Type Basics, by Underware. This doesn’t have a flashy layout, but it is a series of extremely helpful drawings with important lessons for type design.
Type Mechanics, by Tobias Frere-Jones. More useful explanations of some visual things that are important to know, but not always obvious.
I have collected a few useful spacing tests at https://github.com/arrowtype/spacing
There is a ton of practical advice for technical aspects of type design available in the documentation & tutorials provided by various font editing apps. More on this below.

Useful books

For the very basics of letter-shaping, the first book I read in type design was really helpful: Designing Type, by Karen Cheng. It goes through each letter, showing their general forms via measurements of different pieces of glyphs from classic typefaces. This measurement-based is not necessarily useful if you have been designing type for a while – type design is more about testing what you make and trusting your own eyes than it is about following formulas from the work of others. Even so, this book helped me gain an overall awareness of what is “general practice” that I found really helpful as a beginner. And sometimes, even today, when I don’t know a convention offhand (e.g. a question like "How big, exactly, should the quote marks be for a display serif?"), I will take a look at a few relevant fonts to understand precedent.
For more practical information around how to actually draw, space, and kern a typeface, take a look at How to Create Typefaces, from Sketch to Screen.
For deeper (but still approacheable) reflections on theory, The Theory of Type Design, by Gerard Unger is a great book with a beautiful set of visual examples and references.
For one useful theory of approaching type design in a systematic way, The Stroke, by Gerrit Noordzij is a classic.

My favorite font editors: Glyphs & RoboFont 🔗

Making type is involves many things. Digital drawing is only one of the areas to master, but it is a core aspect. When I started out as a student in graphic design, I remember thinking, “Wait, Adobe doesn’t just make a type editor??” I was daunted by what seemed like a confusing world of indie apps, and not sure what to use and how to get started. Here is what I would tell someone in that position, today.

Glyphs & RoboFont are the two most-commonly used editors in professional type design, and also the two editors I have the most familiarity with. This post isn’t really a comparison of the two; I 100% recommend either of them.

Generally, Glyphs is more approacheable and feels more “Mac-like” as an app: it is quite approachable and does some helpful things for you. RoboFont is a bit more intimidating to get started with, but provides more flexibility because it is less “opinionated” about what tools you need.

I got started in Glyphs, and I now use RoboFont more. I use RoboFont largely because I like the way it encourages me to think about my workflow and consider what a given type family should be like. RoboFont is somewhat nicer for scripting (partly because it uses Python3), and its format is nicer for Git versioning. I also really like its approach to spacing.

To be honest, my initial motivation to use RoboFont was that most of my heroes in type use it. A couple years in, however, I have become more fluent in drawing with it, and I like it for many reasons – here’s more on my favorite extensions & tools to use with RoboFont. But, there are also many professionals who use Glyphs to make amazing type. Some studios even use both, though this takes some scripting to handle well.

I have a lot of love for both apps!

Alternative editors 🔗

Glyphs Mini has many of the features of Glyphs, with the main exception that it only allows 1 master per font (meaning that if you want to make multi-style typefaces, you will want to upgrade. If you are just drawing a single font, doing lettering, or making a logotype, this is about 5x better for drawing letters than Adobe Illustrator
FontLab 7 has some amazing features and I’m sure people are doing good work on it, though I don’t have much personal familiarity with it. Unlike RoboFont & Glyphs, it is available on Mac and Windows, so if you’re on a Windows machine, this might be the app for you.
FontForge is an open-source font editor which is cross platform and freely available for Mac, Windows, and Linux. I also don’t have much familiarity with this one, but if you are just looking to explore type design without a big initial investment, this might be the perfect solution.

Getting started in Glyphs 🔗

Glyphs does an amazing job in tutorials & support. Check out https://glyphsapp.com/tutorials for advice on getting started. The Glyphs Forum provides excellent support, often faster than seems reasonably possible. There are great extensions for Glyphs, but I don’t really know much about these – see https://glyphsapp.com/extend for some good suggestions.

Getting started in RoboFont 🔗

Due to its unopinionated nature, RoboFont can an intimidating program to get started in,. If you are just getting started (or if you’re just curious to see what I like), here’s some basic advice that may help get you off the ground.

The docs are pretty good at https://robofont.com/documentation/introduction/. Read through these, and keep clicking to the next page. Don’t get distracted by all the links in each page on the first read through – consider clicking them on subsequent reads.

If you have questions, the RoboFont Forum is very helpful: https://forum.robofont.com/. They usually answer questions within a day (many questions, of course, are already answered if you search for them).

RoboFont Extensions

In an earlier version of this post, I had tips here on some of my favorite RoboFont extensions. However, I have since added more extensions and detail in a separate post on RoboFont Tips.

Other useful tools: 🔗

Alphabet Type’s CharSet Builder is a really handy tool to create character sets (an important early hurdle in RoboFont)
FontGoggles is a really good tool to quickly view fonts, useful to quickly test font builds. It can also be useful as a way to quickly compare how various fonts handle the design of certain characters, etc.
Type-X is a tool I designed and built in collaboration with Roel Nieskens. It allows you to quickly & easily test any font on your system on (almost) any website. This can help you to judge your work in different web contexts (and can be a fun motivator to improve what you’re working on).

Technical areas 🔗

Version control: Git is pretty challenging to get started with, but extremely useful for all areas of technical design & code.
- Git for Humans is a a great introduction to using Git.
- GitHub is the most popular Git website, and they also have a nice getting-started guide.
Scripting: scripting makes it possible to work efficiently with complex fonts, and not have to rely on someone else building everything for you.
- RoboFont has a good guide to getting started, including a great guide to starting with Python, the most common scripting language used for font design & development (and many other things, like software development, data analysis, and more).
- DrawBot makes it possible to create graphic designs & animations with Python. Not only is this a fun way to learn Python, but it can be a genuinely useful tool to generate proofs, books, or animations that (sometimes) would be impossible to create with more-general design tools
- On the Glyphs side, they provide a very handy 4-part Scripting Glyphs tutorial.
Mastering: A topic as big as type design itself. Here are a few places you might get started.
- OpenType Cookbook is a friendly introduction to scripting OpenType features. It is very approacheable, and helps answer questions like “How can I add automatically-swapping alternates to a font?” and “How can I make ligatures work how I want?”
- The OpenType Spec answers basically every question about what is possible in fonts, such as “What are the possible OpenType feature tags and what do they mean?” and “What are the valid values for font variation axes?”
- FontMake is a great way to get started into building fonts in a way that gives you more control than tools like Batch can (you can even use shell scripting as a quick way to create handy workflows to build & sort fonts).
- FontTools provides a bunch of Python-based tools to help handle font files – of note, TTX makes it easy to inspect built OTF/TTF font files, TTFont can make it efficient to edit font data, and