Reminiscent of Sparks[0], a sparkline font which also allowed for data presentation through fonts. It was previously discussed on HN[1].

[0] https://github.com/aftertheflood/sparks [1] https://news.ycombinator.com/item?id=23093815

There are others in a similar vein, too, such as FF Chartwell and Amazing Infographic. See for example https://www.planetquark.com/2018/01/15/charting-graphing-and....

That is a very creative hack, but please never use it, as it destroys accessibility: screen reader will read all these brackets and numbers.

How about something like https://stackoverflow.com/a/54153662

  <span class="graph" aria-label="A graph showing the price of Bitcoin in USD for the past 8 hours" role="img">{11:30}§2b|2i|3t|3c|2o|0i|1n|0{06:30}[35551[34323]</span>

That describes the container, but doesn’t describe the content. A proper label would be something like “A graph showing the price of Bitcoin in USD for the past 8 hours. The price rises from x to y in the first 2 hours, then slowly decreases to z.”

Not an accessibility expert, but that sounds like an analysis of the data, which does not communicate the same as a chart itself. Fine for a blurb to go alongside it though.

But for hard graph data, I would expect "14:00 $123.456; 14:05 $999.999" etc.

No, I think I disagree. If the raw data told the story then there wouldn’t be a need for a chart for sighted users. The chart helps a sighted user get a feeling for the data, and the alt text needs to do the same.

Are there accessible ways of visualizing data?

well yes for people who have accessibility issues but are sighted, probably such things as color blindness needs to be taken into account, or dyslexia if there are text labels on part of the visualization.

For people that are not sighted the accessible way to present the data is probably a block of text their screen reader can read.

Yep. I block remote fonts by default and for a moment it all seemed very weird.

Why do you block fonts?

Bandwidth and privacy.

That was VERY interesting until I read that it only supports integer values 0-3 inclusive for the graph.

It makes perfect sense why that is necessary, but now all the "magic" is gone :(

I agree that it would be nice to support wider ranges, but for simple overviews I think clamping to 4 values can be enough. I don't think this is meant for precision anyway, just like sparklines: http://tools.aftertheflood.com/sparks/

I can't believe all this effort went into it and then it only has four steps. Looks magic still, but the utility seems to be gone.

Since it likely relies on ligatures, I guess the number of values is dictated by the limit on the number of ligatures in the font format. (Dunno what the limit is, though, and whether more values could be supported.)

If you're holding a hammer ...

https://en.wikipedia.org/wiki/Law_of_the_instrument

Whilst this tool is neat, it's not as useful as a hammer. If anything it's an embellishment - just use it to add a bit of gloss to a drab academic piece of stats, but that's its only function.

What's the advantage of such a font? Won't it create issues of its own? For example if my mobile phone's browser wraps text to the next line, wouldn't it "break" the graph?

There are no advantages. It’s heavy, limited, not very readable. It just looks beautiful and demoes OpenType’s features and the author’s capabilities.

Maybe someone will find it useful, but we’re talking about 10 people on earth. Even if you’re just using it for the style on a magazine ad (i.e. without real data points) its very unique look means you can only use it once and the it wears off.

I think it has limited use, but they explicitly mention lack of space as a motivation. You wouldn't use this for long lines.

I'd still recommend a SVG graph behind an outlined text instead of this.

The work is impressive though.

That wouldn't interact with the text, like the graph coming through the hole in the D (under one line, over the other). At minimum you would need one SVG above and one below the text, or have the text as part of the SVG and lose any real accessibility benefit over this font.

Sources are available on github: https://github.com/figs-lab/datalegreya

Not a fan of using such a thin font weight for text; it makes surrounding text harder to read than a thicker font.

"embedded displays", you say?

…those don't necessarily have a TrueType renderer, let alone an OpenType one…

("embedded" = your washing machine, HVAC console, etc. Of course they can have OTF support, but they can also be some shitty 4-bit CPU with bitmaps for fonts.)