At long last, the new FF Chartwell has been released! Four new styles of graphs now accompany the family. The fonts have been released through the FontFont foundry; you may have noticed the FF prefixed to the name. It is a great honor to have worked with their awesome and experienced team.
The transition to FontFont brings a new EULA. The biggest change is that webfont licenses are no longer available. All previous licenses are still valid, and support will continue to be provided. You can still access the old documentation here.
There are no immediate plans to release the new designs as webfonts, but that could change depending on demand or more elegant solutions. If you’d like to see webfonts come back, make sure to let FontFont know.
The new fonts also feature a revised alphabet and beefed up character set for wider language support. Previous users should also note that the charts are now activated by Stylistic Slternates and Stylistic Set 1, rather than the ligature feature.
(image courtesy of FontFont)
Another new design for the upcoming polar collection. I’m also throwing around the possibility of including the grid in the font, and adding it to other designs where appropriate. It’s activated as a separate parameter, and includes different threshold options.
A few, more practical, examples of Chartwell, courtesy of Lizy.
Data is not factual!
New style of Chartwell in the works.
If you purchased a license the first time around, you can upgrade with a full discount of your order here.
*These fonts have not been manually TT hinted, mainly due to the sheer number of glyphs. However, for lack of a better term, since a number of tweaks to the glyph metrics and naming required to enable maximum browser support, ‘webfont’ is the only descriptor that felt mildly appropriate. Check the browser samples for rendering performance.
The underlying architecture of Chartwell revolves around ligature substitutions. Most typefaces use ligatures to prevent glyphs from crashing into each other. A simple swap code looks something like:
sub f i by f_i;
So, whenever an “f” appears next to an “i”, the two get swapped out with a pre-drawn “f_i” glyph.
Bars only uses these basic swaps as described above. Its structure works something like this:
sub two three by twentythree;
When “2” and “3” appear next to each other, swap with the “twentythree” glyph that has been drawn to be 23 times as long as the “1” glyph. It’s important to remember that a glyph can be drawn with any vector shape. We aren’t limited to letters!
From here, all we have to do is cycle through the glyph combinations from 1-1,000—the limit I chose for this style—and swap with the corresponding glyphs.
Another thing to note is the negative sidebearings—the space on either side of a glyph. If a glyph is given a left sidebearing of -100 units, it will be positioned 100 units to the left of where the previous glyph ends. These negative sidebearings eliminate the gap that occurs from the indented shape of each glyph.
The pluses serve no purpose other than to make sure values don’t accidentally get interpreted as one. If the example above were written “233635” it would be interpreted as “233 635 51.” If spaces were used, instead of pluses, the values would render correctly, but there would be a space in between each. When ligatures are turned on, the pluses get swapped with empty glyphs, keeping them out of the way.
In Pies, we also start with a straight swap.
Now we need to chain the values together. It’s not possible to rotate a glyph using OpenType. To get around this, all possibilities had to be drawn, and exist as separate glyphs. (i.e. The “1” wedge has 100 variations, each rotated 1% further than the previous. The “25” wedge has 75 glyphs, and so on.
Next, the previous glyph must be detected, so we know how far to “rotate” the current glyph. For this, we can make use of OpenType contextual substitutions. The code looks something like this:
sub twentythree.zero plus thirtysix.zero’ by thirty.twenty;
The ’ mark allows us to designate which glyph will be swapped. So in this case, “thirtysix.zero” will only be swapped when it is preceded by “twentythree.zero plus”. It is then replaced by a 36% wedge that has been rotated by 23%.
Taking this further:
sub thirtysix.twentythree plus fourtyone.zero’ by fourtyone.fiftynine;
Since the “36” glyph is starting at 23%, it will end at 59%. When a “41” follows in this context, it gets swapped with a “41” rotated 59%. From here it’s just a layering of this concept to take care of all possibilities.
It gets complex fast though. There are up to 99 possible starting points for each value. To help keep the code under control, OpenType allows us to make classes, or groups of glyphs, that we can swap out in one bang.
As I mentioned earlier, each value has been rotated for each possible starting point. Each glyph that starts at 0% has been grouped into the “@zero” class. Each glyph that starts at 1% has been grouped into the “@one” class, and so on.
Then glyphs are also organized by where their ending point is. So “40” starting at “0”, and “39” starting at “1”, will belong to the “@fourty_end” class.
To swap out all possible combinations that start at 40% we can use this code:
sub @fourty_end plus @zero’ by @fourty;
"@fourty_end" contains all values from 1-40, that in combination with their starting point, add up to 40%.
"@zero" contains all values from 1-100 that have not been rotated.
"@fourty" contains all values from 1-60 that have been rotated to start at 40%.
From here it’s just a matter of cycling through all the different starting classes.
To finish it off, all rotated wedges have a negative sidebearing, which centers them over the first glyph.
Lines loosely follows the same logic. First, it does a straight swap of the values, resulting in something that looks like a vertical bar graph.
The previous values must then be detected. Again, the code looks pretty similar toPies:
sub twentythree plus thirtysix’ by @thirtysix_eightyone;
The “36” gets subbed out by a glyph that has the front point pulled down to the height of 36. Each value has a pre-drawn glyph connecting to each of the possible starting points from 0–100.
A tricky thing presented by this design is what to do with the first value, since it has no previous point to connect to. There were three options as I saw it.
1. Do nothing, and let the flat bar value exist for the first glyph. Obviously this creates an unnecessary glyph, and extra point along the graph.
2. Start all values at zero (or some other arbitrary number). Again, this didn’t seem right, because not all data starts at zero.
3. Only use the first value as a starting point. So it’s value wouldn’t be visible until a second value was chained to it. This felt the most accurate, allowing you to choose your starting point. This way the values are treated more like points along a line, rather than solid blocks.
Generating the Glyphs
Because of the sheer number of glyphs in each style—Lines alone has over 10,000—an automated production method needed to be developed. Lines and Bars are fairly simple, and calculable shapes. Because of this, I was able to auto-generate the glyphs, using Robofab python framework.
Pies was a bit more of a challenge because of the round shapes. Once each of the 100 sized wedges were drawn, action sets were created in FontLab for rotating and positioning the glyphs.
In case you were wondering how Chartwell performs on the web. On the Mac it renders surprisingly well, but not so great on Windows.
Firefox 4 is currently the only browser that supports Chartwell. FF3.6 does support ligatures, but mangles and breaks the graphs. So, in conclusion, you should find other options for displaying graphs on the web, unless you have an extremely controlled user base.
The “Chartwell Explained” post is taking longer than I had hoped. Until then, here are a few samples illustrating a few of the many possibilities of Chartwell.
I should point out, you can color the values with any color you like. I just happen to prefer the simple b&w style.