Ligature Icons
Icon fonts have fallen out of favor in recent years because SVG support has gotten good enough to be viewable by virtually everyone using a browser. There’s a good reason for the switch to SVG other than that, of course. Icon fonts are generally used in the conventional manner of assigning an icon to a character in a font, using the character in the markup, and then styling the containing element to use the icon font. It never should have been considered a viable method of displaying icons on a webpage. It littered the markup with stray characters that most of the time bore very little semantic meaning to the icons that would be displayed in an ideal setting. It also was an issue when screen readers were involved, creating odd — and sometimes comical — interjections of random characters that were read out instead of an icon. A simple img element would be preferable to that.
SVG icons work really well today as long as you embed the SVG into the document. If sourcing a SVG through an img element by its identifier various problems begin occurring in different browsers — except Firefox which handles everything you throw at it. Embedding SVG into every document isn’t efficient and isn’t friendly to the browser’s cache either. If there are only a few icons this is okay, but for several it’s not a good option at all. What if there were a way to use icon fonts and have them be both semantic and degrade gracefully? There is, and I’ve used them on this website for almost five years. I only know of one write-up about ligature icons which is from CSS Tricks a couple of years ago about how Google’s Material Design icons were ligature icons. It kind of fell flat because it didn’t go into any detail of how to make them. I’ll outline a way to do so here.
Ligatures
I hope all designers are aware of ligatures. Some people reading this might not be, so I’ll explain a little bit. They’re combinations of letters into a single glyph like the ones displayed above. The most well known of the bunch of course is the ampersand which originated as a ligature of “et” which is Latin for “and”. Aside from the ampersand and other characters like the German ß that became so commonplace they just became yet another symbol used, they haven’t been available for use on the Web except when someone has discovered the wonders of Unicode and decided to paste in Unicode representations of them like many do on their Twitter profiles. Automatic insertion of ligatures is supported by a vast majority of browsers now and have been for some time.
This is interesting and all, but how are developers and designers going to create icon fonts? Well, the usual approach to this would be to use specialized font software to create them such as Fontlab or FontForge. In fact software like that is how I created my font originally, but I discovered another way that doesn’t require much in the way of super specialized software like a FontLab or FontForge.
Math?! Ew!
Before getting into how to create them I should explain a bit about how fonts work internally. Internally fonts use a measurement called UPM which is short for units per em. In metal type it was the size of the box the letter rose out of, and in digital type it’s the resolution of the font itself. Most font formats cannot use floating point numbers in the positions of points, so a font with 1000 UPM has 1000 units2 to use within that box, but unlike metal type digital type can excede the box. I used 1000 UPM in my icon font. 2048 is a common UPM size; it provides more resolution for the font, and it’s common because in the old days where processing power and memory wasn’t remotely as abundant as it is today it was convenient to have a nice, round number in binary. Today we can use whatever we want. Actually, it might even make sense to use something which is proportional to the size of your icons; for instance if your icons are 24×24 then the UPM would be 2400. I haven’t personally experimented with this yet, but it makes sense.
What? SVG?
Indeed. You can author fonts in SVG 1.1. They have been removed in SVG 2.0 which I see as a shortsighted mistake; that’s for another time, but what I’ll show here says a bit of why it’s a mistake to deprecate SVG fonts. Chrome and Firefox have removed support for SVG fonts, so why bother with them? It’s what the icon font will be authored as, not what it will be delivered as. At the end of this process a TrueType font will be generated.
Yeah, I know. That’s a lot to take in one go. That’s okay. I’ll explain. Assuming basic knowledge of SVG file structure the first thing that should be unfamiliar is the font element.
In the excerpt above the font element has an id attribute and a horiz-adv-x attribute. The id attribute is the same as it is in HTML. The camel case structure of the id isn’t what is found in XML or HTML because it is used by software (to be detailed later) to generate name tables for the resultant TrueType font. The horiz-adv-x attribute is the default width in UPMs of a glyph; in this case it’s zero.
The font-face element defines the names and metrics for the fonts. The font-family, font-weight, and font-style attributes should all be self-explanatory. The units-per-em attribute shows exactly what was mentioned earlier. Lastly there’s the ascent and descent attributes. In a normal font they’re used to define the top of the ascenders and the bottom of the descenders; in this icon font they’re used to force the baseline in the center of the icon and to help with some residual math necessary when exporting SVG later.
There is one more name to use in a font for our purposes and that’s the font-face-name which goes inside a font-face-src element. It specifies the full name for this font which includes both the family name and its style name. Now, onto the glyphs that are within the font element.
As can be inferred by its name, the glyph element defines an individual glyph of the font. The particular example above is a ligature because its unicode attribute contains multiple characters. The glyph-name attribute is important for our uses because it is used to name individual glyphs which are used in the TrueType font’s ligature feature table. The horiz-adv-x attribute is the same as the one mentioned before, but here it is defined just for this glyph. Lastly, the d attribute contains path information in SVG’s esoteric way.
At the end of the font element there’s a series of glyphs which look like this. They are glyphs for the individual characters in each of the ligatures’ unicode attributes. There must be characters to replace present in the font, after all. The glyph contains no geometry and is intentionally empty.
Creating the Icons
While it definitely is possible to write SVG path data by hand I’m not going to do it, especially when it can be exported from a vector application such as Adobe Illustrator or Inkscape. In my explanations below I am going to be using Illustrator, but everything here is possible — and perhaps even easier — with Inkscape. Illustrator is what I personally am more familiar with, so I will be using that.
This is where the math, stuff about UPM units, and the ascent and descent attributes come together. Using this approach each icon must be a compound path and in one color. It would be helpful to have all points be integers, but it’s not absolutely necessary as the converter software will fix that; it’s still a good idea to change them before to eliminate potential problems.
Is this a mistake? Unfortunately, no. In the example above I’ve created 1000×1000 point artboards for each of the icons because I use 1000 UPM in the font, flipped them vertically, and then adjusted their positions within the artboard upward by 250 points (1/4 of UPM). In Adobe Illustrator CS5, Adobe flipped the vertical ruler direction to where down was positive and up was negative. In fonts it’s the opposite, so that’s why the icons are flipped. I’m not awfully sure about the other. I did a lot of testing, and this is what ended up working. Adobe Illustrator copies objects to the clipboard in SVG. You would think that would be the obvious way to get SVG path data from these, but you’d be wrong. Objects copied to the clipboard do not seem to care about ruler direction, ruler origin, or even its position within 2-D space; typical Adobe. Instead, export the artboards to SVG files and then copy the icon path’s d attribute to the corresponding glyph in the icon SVG font.
And, Finally…
If the SVG specification authors and browser vendors weren’t shortsighted this would be the end of the font generation process. We would have a font format as editable as a text document — perfect for icons. Sadly, we must instead carry on. The last step of the font creation process involves converting our icon SVG font into a TrueType font. The requirements are as follows:
- Node.js, a requirement for svg2ttf as it is written in Node
- svg2ttf, the CLI used to convert the SVG icon font to a TrueType font
- ttfautohint, a CLI used to
perform voodoo on the fontadd hinting to make it display a bit more nicely in Windows
brew install node ttfautohint
npm install -g svg2ttfNode.js and ttfautohint are easily available in your system’s package manager. I use macOS, so above I use Homebrew. You might be using a different operating system, so look up if you even have a package manager or if they are available. If not, they can always be downloaded manually. Svg2ttf is available via npm which is installed with Node.js. With all the requirements met converting the font is simple:
svg2ttf --copyright "© 2018 Dustin Wilson" icons.svg icons.ttf
ttfautohint --symbol --hinting-limit=0 --windows-compatibility icons.ttf icons-hinted.ttf
mv icons-hinted.ttf icons.ttfThis above is using a bash shell, so if using Windows or a different shell the syntax might be a bit different. It would be convenient if the output of svg2ttf could be piped to ttfautohint, but the author of svg2ttf didn’t provide standard output capabilities. Svg2ttf also injects its own copyright information in the font but thankfully has an option to supply your own. Considering these tools are available with command line interfaces it should be trivial to automate the process further. Generating WOFF files is outside the scope of this tutorial, but the output TrueType file should work in any tools you use to convert other fonts.
Markup & Styling
Using the font is pretty much the same as you would any other font on the Web:
ArtStation
Dribbble
Email
Feeds
GitHub
Last.fm
Mastodon
Twitter
There are a few notable differences, though. Ligatures need to be enabled for the font to do its thing, so I have set font-variant-ligatures on the entire page. Normally if ligatures aren’t supported and @font-face is then users would be presented with a blank footer; that’s not good. There are two @supports for this. One detects if ligatures are supported via font-feature-settings and applies the necessary styling to the footer, increasing the font size and changing the font rendering to a simple grayscale where it can. Normally I’m vehemently opposed to using those properties because on regular text it actually reduces legibility by decreasing the resolution of the type. It’s not necessary on icons, though. The other @supports enables ligatures via font-feature-settings if font-variant-ligatures isn’t supported. In my example the property enables both ligatures and capitals to small caps because elsewhere in the document c2sc is enabled, and font-feature-settings doesn’t stack.
Whew. That was a lot to write. The greatest thing about this approach is that the icons in the footer are just text. They’re selectable and readable by screen readers, and if ligatures aren’t supported it’s still just text. My hope is that this will be useful to designers and developers and give them one extra thing in their Web repertoire because that’s all it is — just one more way of doing something. It won’t work for all cases, but it’s good to know it’s there as an option.