A Not-So-Brief Explanation of Chartwell
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:
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%.
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.
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.
Because of the somewhat primitive nature of OpenType language, some of the code got a little lengthy. To help cut down on errors, and an effort to preserve my sanity, I wrote a few javascript functions to output some of the OpenType feature code.
I Love Typography, OpenType How To
I Love Typography, Engaging Contextuality by Nick Shinn
Adobe's OpenType Resource
Typotheque OpenType Feature Support Chart
RoboFab
yousharknotpass
vaporwave
tangentwithtanner
pixelskylines
izzy806
s-u-f-j-a-n-s-t-e-v-e-n-s
areudirty
dailybridgerton