Seems like a spark or sparkline describes a bar graph, rendered inline in regular text.
There is some font magic to render {30,60} as small bars in the text.
Nice, but the terms were new to me. Would have helped to explain them first.
This tool doesn't really create sparklines, but it does create small charts, although given it is delivered via custom font, it's usefulness is limited.
* And anyone interested in displaying information is doing themselves a disservice without a copy of "The Visual Display of Quantitative Information" by Tufte.
> This tool doesn't really create sparklines, but it does create small charts
The gif at the top doesn’t demonstrate everything included. From the text:
“There are currently three variations: bars, dots, and dot-lines (line charts with tiny dots at the joints between segments), each of which has five weight variants.”
I’d call delivery as ligatures a trade-off. Much easier to make it scale with text on the web when embedded inline, it’ll match the text colour for free, and the underlying numeric data are trivially retrievable and machine-readable. Compare the example on the Sparkline wikipedia page, which don’t scale with the text and are almost invisible when using their own dark mode.
While I like the idea of using it in a graphics application, I have to say that I do not see the advantage of using it in a web application instead of a simple CSS solution.
Can someone enlighten me as to what advantage a font solution would have for displaying bar charts?
For one, it remains readable for users using accessibility devices. You can do the same for the simple CSS solution, but based on experience, nearly no one does. Accessibility should be mandatory, but unfortunately it's often at best an afterthought.
For audio applications, high performance display updates are important.
The richer the font, the higher-performance the GUI in these cases.
Render 4,000 independent graphic objects as quickly as possible? May as well let the operating systems text rendering pipeline do all the work .. as long as the typography is rich, it can result in a superlative user experience.
That's ridiculous, by this measure font ligatures are also contributing to fraud. Or, heck, even fonts themselves, who stops a font from displaying A as B?
No, treating some letter sequences like fi and ffi so that the letters stick together in a certain way is not "by this measure".
> who stops a font from displaying A as B
It's noticeable; a B consistently occurs everywhere there is an A, wherever that font is used. You can't perpetrate an easter egg whereby a certain A is replaced.
We could prepare a page where every glyph appears, and detect substitutions via OCR.
With text replacement, we could look for a particular sentence, and change a word in it, without playing any games with glyphs at all. It will be undetectable in a document in which the target sentence doesn't occur.
Anyway, we can't think about not using fonts. Fonts are necessary for rendering text.
Fonts that substitute arbitrary text are not necessary. Just because I need fonts doesn't mean I need term-rewriting fonts.
We don't have to accept one threat just because there is some inevitable minor threat. That's the Package Deal informal fallacy, or something along those lines.
> No, treating some letter sequences like fi and ffi so that the letters stick together in a certain way is not "by this measure".
Except ligatures are not limited to fi and ffi. They can be used to change appearance of any sequence of characters, including words.
> It's noticeable; a B consistently occurs everywhere there is an A, wherever that font is used.
I'm not talking about substituting a single letter. I'm talking about outright obfuscation of a entire texts.
> You can't perpetrate an easter egg whereby a certain A is replaced.
Quite the opposite, it is trivial to apply different fonts to different parts of text, so you can keep some parts of text normal, and some parts (like numbers and data) obfuscated. In HTML you may notice some abundance of <span>s, sure, but in PDF? Literally no way, unless you copy-paste everything and compare it.
And this is not a hypothetical scenario or a 'minor threat'. Russian government used precisely this technique to obfuscate data in their online voters turn-out reports: (source in Russian, not found it reported in English) https://habr.com/ru/news/578846/. Have they used more subtle scrambling of only digits and not also mixing letters: who knows how long it would take for anybody to notice. From a technical perspective it's not so different from contextual alternates - both require custom made fonts.
There are other ways to alter document presentation too. Especially in CSS, you can create pseudo-elements, not present in the original HTML, or hide parts of HTML, or use a media query which checks if the page is being printed or not!
> We could prepare a page where every glyph appears, and detect substitutions via OCR.
Why the extra step? Why not take the OCR of potentially compromised document and compare it with its raw content? It would detect every substitution, whether it's ligatures, alternates, media queries etc. Why not inspect the font file for defined alternates directly?
A secret division, crime fighters, working hard to keep fonts safe from misinformation, they work behind the screen, tirelessly, without thanks. We call them:
I suspect that your puerile mockery will come to a swift end when you discover you signed some contract that you read on the screen, but whose wording was altered by the printer.
This is not a realistic scenario whatsoever. Printers tend to print fonts pretty accurately to their on screen presentation. Even using contextual alternates, the perpetrator would have to change the font before printing. But if the perpetrator has this opportunity, they do need the font at all, they can just change the content. For example, CSS media queries that I mentioned in the other comment can show one paragraph on the screen and another when printing. You don't even need to put both in the HTML - CSS ::before and ::after will happily do that for you.
It's also not very wise in general to not read the final printed version of the contract before signing
Seems like a spark or sparkline describes a bar graph, rendered inline in regular text. There is some font magic to render {30,60} as small bars in the text.
Nice, but the terms were new to me. Would have helped to explain them first.
Sparklines are not bar graphs, they're lines, hence the name. If you have a copy of Tufte*, you can find them on page 171.
Tufte has written up a history here: https://www.edwardtufte.com/notebook/sparklines-history-by-t...
This tool doesn't really create sparklines, but it does create small charts, although given it is delivered via custom font, it's usefulness is limited.
* And anyone interested in displaying information is doing themselves a disservice without a copy of "The Visual Display of Quantitative Information" by Tufte.
> This tool doesn't really create sparklines, but it does create small charts
The gif at the top doesn’t demonstrate everything included. From the text:
“There are currently three variations: bars, dots, and dot-lines (line charts with tiny dots at the joints between segments), each of which has five weight variants.”
See also their examples page: https://beta.observablehq.com/@tomgp/after-the-flood-i-spark...
I’d call delivery as ligatures a trade-off. Much easier to make it scale with text on the web when embedded inline, it’ll match the text colour for free, and the underlying numeric data are trivially retrievable and machine-readable. Compare the example on the Sparkline wikipedia page, which don’t scale with the text and are almost invisible when using their own dark mode.
> hence the name
That explains the "lines" part, but whence the "sparks"?
Thankyou! I was starting to question myself looking at those small bar-graphs. That's not a spark-line!
Cool, I guess, but no spark-line.
Sparklines have been around (in modern usage) for nearly 20 years (coined by Edward Tufte in 2006.
Also, Google is a thing.
Given that the OpenType font format is Turing-complete [0], I would challenge the “without code” claim. ;)
[0] https://litherum.blogspot.com/2019/03/addition-font.html
There has also been a commercial offering in this space for a while: FF Chartwell (https://typographica.org/typeface-reviews/chartwell/)
Very cool, but …
I don’t understand how the ligature knows to generate a Vertical Bar vs Bar vs Pie Chart since there no identifier to specific which to use.
https://typographica.org/wp-content/uploads/2012/01/ff-chart...
If I'm understanding the article right, they're actually different fonts as opposed to a single font.
There are different font files for each graph type.
Previously:
https://news.ycombinator.com/item?id=23093815 (2020)
https://news.ycombinator.com/item?id=15223212 (2017)
While I like the idea of using it in a graphics application, I have to say that I do not see the advantage of using it in a web application instead of a simple CSS solution.
Can someone enlighten me as to what advantage a font solution would have for displaying bar charts?
For one, it remains readable for users using accessibility devices. You can do the same for the simple CSS solution, but based on experience, nearly no one does. Accessibility should be mandatory, but unfortunately it's often at best an afterthought.
For audio applications, high performance display updates are important.
The richer the font, the higher-performance the GUI in these cases.
Render 4,000 independent graphic objects as quickly as possible? May as well let the operating systems text rendering pipeline do all the work .. as long as the typography is rich, it can result in a superlative user experience.
I wonder what the accessibility implications are.
It would be handy if this could work in markdown, but there’s no standard, I imagine it’s possible somehow dependent on the markdown parser.
Why no demo image in GitHub readme?
There is a gif?
[flagged]
That's ridiculous, by this measure font ligatures are also contributing to fraud. Or, heck, even fonts themselves, who stops a font from displaying A as B?
No, treating some letter sequences like fi and ffi so that the letters stick together in a certain way is not "by this measure".
> who stops a font from displaying A as B
It's noticeable; a B consistently occurs everywhere there is an A, wherever that font is used. You can't perpetrate an easter egg whereby a certain A is replaced.
We could prepare a page where every glyph appears, and detect substitutions via OCR.
With text replacement, we could look for a particular sentence, and change a word in it, without playing any games with glyphs at all. It will be undetectable in a document in which the target sentence doesn't occur.
Anyway, we can't think about not using fonts. Fonts are necessary for rendering text.
Fonts that substitute arbitrary text are not necessary. Just because I need fonts doesn't mean I need term-rewriting fonts.
We don't have to accept one threat just because there is some inevitable minor threat. That's the Package Deal informal fallacy, or something along those lines.
> No, treating some letter sequences like fi and ffi so that the letters stick together in a certain way is not "by this measure".
Except ligatures are not limited to fi and ffi. They can be used to change appearance of any sequence of characters, including words.
> It's noticeable; a B consistently occurs everywhere there is an A, wherever that font is used.
I'm not talking about substituting a single letter. I'm talking about outright obfuscation of a entire texts.
> You can't perpetrate an easter egg whereby a certain A is replaced.
Quite the opposite, it is trivial to apply different fonts to different parts of text, so you can keep some parts of text normal, and some parts (like numbers and data) obfuscated. In HTML you may notice some abundance of <span>s, sure, but in PDF? Literally no way, unless you copy-paste everything and compare it.
And this is not a hypothetical scenario or a 'minor threat'. Russian government used precisely this technique to obfuscate data in their online voters turn-out reports: (source in Russian, not found it reported in English) https://habr.com/ru/news/578846/. Have they used more subtle scrambling of only digits and not also mixing letters: who knows how long it would take for anybody to notice. From a technical perspective it's not so different from contextual alternates - both require custom made fonts.
There are other ways to alter document presentation too. Especially in CSS, you can create pseudo-elements, not present in the original HTML, or hide parts of HTML, or use a media query which checks if the page is being printed or not!
> We could prepare a page where every glyph appears, and detect substitutions via OCR.
Why the extra step? Why not take the OCR of potentially compromised document and compare it with its raw content? It would detect every substitution, whether it's ligatures, alternates, media queries etc. Why not inspect the font file for defined alternates directly?
OK, I changed my mind about ligatures; out with the fi and ffi glued together and all of it.
Concern with what text looks like is just emotional quaintness; it's not worth sacrificing security.
A secret division, crime fighters, working hard to keep fonts safe from misinformation, they work behind the screen, tirelessly, without thanks. We call them:
The typeface police.
I suspect that your puerile mockery will come to a swift end when you discover you signed some contract that you read on the screen, but whose wording was altered by the printer.
This is not a realistic scenario whatsoever. Printers tend to print fonts pretty accurately to their on screen presentation. Even using contextual alternates, the perpetrator would have to change the font before printing. But if the perpetrator has this opportunity, they do need the font at all, they can just change the content. For example, CSS media queries that I mentioned in the other comment can show one paragraph on the screen and another when printing. You don't even need to put both in the HTML - CSS ::before and ::after will happily do that for you.
It's also not very wise in general to not read the final printed version of the contract before signing
[flagged]