Chartwell is a family that explores the use of OpenType to interpret and visualize data. The font format is highly portable and can be used in any application that supports standard ligatures. The data also remains editable allowing for easy updates.

Just what I needed a week ago! Darn, I'd love to understand how this actually work. The number of shapes must be huge if there's going to be one from 1 to 100, one from 1 to 99 ... one from 2 to 100, one from 2-99 ... &c.

Thanks for pointing out the typo and Quartzo. I was not aware of his work. It's very interesting to see another take on how the graphs could be implemented, and also the potential for designing a robust OT family for a specific industry.

The reason I went with horizontal bars, was so you could chain them together to create infinitely long values if needed. Vertical bars could be useful too though, if you wanted to have the graph in a textbox next to "plain text," or if rotating isn't convenient.

Then the advocate for the guy with a tail and pitchfork shows up. this is a well designed and apparently well executed idea that off-loads the difficulty of text-to-graphics from the input to the output. E.g. though the examples show nice little input and nice big output, the reality is that the input and output sizes are the same. So, one must make sure the composition remains in opentype savvy environments or else an output font must be created/subset to contain the right graphic. I don't think this is a big problem, since spell checking and other character specific functions are not likely to used after composition except in dynamic web environments.

The other devil of an issue here, I'm sure you've all thought of is color, since nearly no one wants black and white, or monotone graphics of this kind.

@dberlow
Thanks for the thoughts. It's good to hear some critical feedback. Yes, in the examples, the output has been scaled up. This was just a design decision to keep the examples simple, but perhaps it would be worth noting in the examples to be completely transparent. I'm OK with these only working in OT savvy environments. I see these as more of a tool to help designers create charts in their native design files.

As far as the scaling issue goes, it's pretty easy to change the pt size, just like any font.

This definitely is not ready for the web. I've got some ideas on how to use JavaScript to do the work of OT, in browsers not that don't support ligatures. But I think rendering is an issue, even on a Mac. The glyphs have to line up perfectly, or else you end up with gaps between values. I really don't have the manpower, or technical know-how, to manually TT these, because of the sheer number of glyphs.

As riccardo pointed out, these aren't limited to black and white. You can give it any color you like. Whatever color is applied to the number, the related ligature glyph will take on that color. The decision to go with b&w was again, purely a design/brand decision. Treating it much like a standard type specimen, I thought it was best to keep it simple and show that these hold their own, even without color.

This is very ingenious, but it seems to be taking a sledgehammer to crack a nut.
What is wrong with, for instance, Adobe Illustrator in a workflow? Illustrator charts and graphs may be edited from data, preserving live dimensionalization, transformations and gradients: Chartwell presents a primitive and largely obsolete "Illustrator 88" style. Or is there some retro appeal to that simple look?

First, I should say that I approached this from an experimental angle. I was trying to see how far I could push OT to manipulate input data. Making it useful, was something I definitely wanted to achieve, but it was slightly less important to me.

Illustrator does have useful chart and graph building tools. I think many people aren't aware of them, or just don't want to deal with them. Personally, I find them clunky and don't use them.

But say you are putting together an annual report in InDesign and don't want to have to go back to InDesign to make tweaks to the charts? Just one potential workflow time-saver I see.

There are a ton of options for making charts out there, and Chartwell isn't meant to be the end all solution. It's just another option, that may, or may not make sense with what you're trying to do.

Ultimately though, the next step will be pushing these into non-standard, and less mathematically calculated shapes. Taking advantage of the fact that I can draw any shape I want. Something that excell, and other chart making software isn't really built to do.

This reminds me of experiments I did a while ago, to try and program arbitrary nut fractions.
I gave up as it was getting too complex, but having seen Chartwell, I think I could get it to work now.

I can also see this technique being used to create multi-colour fonts: one would apply color to the parts in the default "exploded" view, and apply "ligatures" (or whatever feature is deemed appropriate) to bring the parts together. It would be smoother and more precise than the system presently employed by multi-color fonts, which IIRC all rely on layering of text boxes.

>>to use JavaScript to do the work of OT, in browsers [] that don't support ligatures
>this is a real challenge. I wish you great success.

It's actually not that difficult. Just like OT 'sub x y by x_y' you can do a similar find/replace with Javascript. However you have to point to unicode, rather than glyph names. The problem is though, that I'd have to go back and give the glyphs a PUA, then organize those those into javascript arrays, which would serve the purpose of classes. Not a quick and painless task, but definitely possible.

And like pointed out above, there are already much better systems for displaying graphs on the web. I think exploring this would only be useful if I end up doing a non-conventional graph design.

>On parts not connecting, are the glyphs overshooting the widths, or right on the width?

I just did some tests, using the native ligature support in Firefox 4, and am actually kind of surprised at how well it renders in Mac. Windows is pretty rough though. Screenshots below. Also

I had been working with a (relatively) small number of glyphs, using kerning to position numerators, the horizontal bar, and denominators, but was running into problems with some applications failing to recognize three glyphs superimposed, by means of negative sidebearings and large kern values.

Having seen the vast number of glyphs you have employed, I now think that a more robust solution to creating a large set of nut fractions would be to combine denominator and bar, so that one hundred glyphs would cover the "bottom" of all fractions up to hundredths, then one hundred numerators could be kerned to fit above, in two classes.

I'm not sure there would be much call for such fractions by people using general layout apps, though. If such fractions were required, they would be using a math app anyway. But you never know.

So in this example, we'd end up with space @num_one @num_two @num_three @num_four / @denom_four @denom_three @denom_two @denom_one

Now we've got to center everything. It's probably easiest to just center everything around the numerator, but that may give you issues crashing into previous text. I'll let you figure out how to solve that problem, but I'm sure it's possible.

So first make the bars, with their varying widths to cover your options. If you give the fraction a negative left sidebearing, you can center it under the numerator. Then give it a negative right side-bearing, this can be used to center the denominator.

A basic swap, with exactly the same number of digits in num/denom, you could do something like this.
Sub @num_four fraction' by frac_four;
or
Sub fraction' @denom_four by frac_four;

However to be a little more flexible, supporting varying numbers of digits, create four different versions of the fraction_four. each one with a different right sidebearing, to center the denominator. Then...

Sub @num_four fraction' @denom_three by four_frac_three;

And cover all possibilities.

Like I said, I haven't tested this, but maybe it will help? If it works, it could sove having to make ton of extra glyphs. The only glyph that would need alternates is the fraction bar.

As I said, having the compound fraction composed of (at least) three superimposed glyphs, some with large negative sidebearings and kerning, created instances that were not correctly rendered in some layout applications.

That is why I'm contemplating combining denominator and bar. More glyphs, but perhaps more robust.

Have you tested Chartwell in a variety of layout applications and platforms?

It's been tested in CS4 on Mac, CS5 on Windows 7, also Illustrator CS on Vista.

I don't have a budget to license and test all possibilities, but fully plan on troubleshooting or refunding if problems do arise. One of the reasons I decided to launch this on my own, without MyFonts, was so I could keep a close relationship with customers and provide upgrades easily.

I've had no complaints so far, other than a naming issue, now resolved.

There's no kerning in Chartwell, except in the alphabet, and I don't think the sidebearings are absurdly large. I would be interested to know what applications and systems you were having trouble in. Was the problem only appearing when glyphs had both kerning and a negative sidebearing?