We’ve just launched version 2.0 of Sparks, our sparkline typeface (formerly known as AtF Spark, see below). If the first release was an interesting and somewhat quirky proof of concept, this new version is a robust and versatile tool.
The first version of Sparks included six fonts (three bar widths, two dot sizes, and a single dot-line variant) and was never intended to be the end of the road for the project. The dot-line font especially was a rough attempt at building a line chart tool, which was severely limited by our technical know-how at the time. Sparks 2.0 has both expanded the font family into a rationalised set of styles and solved the technical challenges of making a line-chart font.
The expanded family
From early on in the development of Sparks we had it in mind to become part of Google Fonts. After the initial release, we were able to determine a plan for making this happen. That plan included expanding the character set to include a full alphabet with all supporting characters (symbols, diacritics, etc.), rationalising the system of weights and styles, and changing the name from Spark to Sparks (because Spark was already taken on Google Fonts).
All of the fonts in version 2.0 of Sparks now boast a basic character set of 232 glyphs, which includes the complete Basic Latin and Latin-1 Supplement character sets. All of the charting elements are on top of that.
Beyond the character set the Sparks family is now ordered into a rational system of weights, where each variant (bar, dot, dot-line) has five weights, organised as two weights above and two weights below a basic medium weight, like so:
Bar – Extra-narrow
Bar – Narrow
Bar – Medium
Bar – Wide
Bar – Extra-wide
Technical challenges
The largest hurdle we needed to clear to reach 2.0 was the technical challenge of how to build a dot-line font that uses a range of 0–100 instead of 0–9. Because a line chart needs to plot connections rather than just single values we needed to both generate a lot of glyphs while the code that powers the glyph substitutions needed to become a lot more sophisticated.
The glyphs
To create the glyph set we first needed to figure out how to programmatically generate the glyph objects, because drawing 10,201 glyphs by hand was simply not going to happen (there are 101 points between 0 and 100 and each of those must be able to plot a connection to every one of those points, so, 101 x 101 = 10,201). To begin we created a set of 101 basic shapes (0 to 0, 0 to 1, 0 to 2, etc.). A friend of the studio then wrote us a Python script to automatically generate the remaining 10,100 glyphs by manipulating the positioning of the original set (this is possible because .ufo font files are really just a folder of text files so you can open the whole thing in a text editor and, likewise, operate on them as if they were files in a directory using scripting languages). With our enormous mass of glyphs in hand, we set about writing the glyph substitution code for changing numbers into a line chart.
The code
The code for the bar and dot fonts looks something like this:
feature calt {
ignore sub one' two' comma space;
sub braceleft' one' two' braceright' by chart.012;
sub braceleft' one' two' comma' by chart.012;
sub one' two' comma' by chart.012;
sub one' two' braceright' by chart.012;
} calt;
That code is simply swapping a string of number glyphs for the appropriate chart glyph, and each number can only be matched with one glyph.
The dot-line font, on the other hand, needs to know about both the current number and the next number on so that it can plot a line between two points. In theory, you can do this by simply adding a whole lot of the same style of code used for the bar and dot fonts, expanding it to cover all possible pairs of numbers from 0 to 100 instead of just single points between 0 and 100. This expansion would result in 10,201 pairs (101 x 101). With this idea in mind, we wrote a simple script to generate all of the substitution rules and off we go! But wait, not so fast. In practice, this method doesn’t actually work because the OpenType compiler has an arbitrary limit on how many lines of substitution code can be in a single font feature (about 3000, the reasons for which are not worth going into here). So we needed a new approach. This proved difficult.
After several days in a deep corner of the internet and repeatedly testing the max RPMs of our computer fans we eventually figured out how to circumvent the size limit on substitution code by making use of glyph classes, segmenting out the different substitution steps, and then chaining substitutions (numbers to dots, dots to lines). The resulting code comes in under the ceiling for lines of code, is better organised, and actually works. Bonus!
The future
Version 2.0 marks a huge step forward for Sparks both in terms of scope and technical sophistication. We’ve now submitted the fonts to Google for inclusion into Google Fonts and await news on this front. Stay tuned.
