[HN Gopher] Sparks - A typeface for creating sparklines in text ...
       ___________________________________________________________________
        
       Sparks - A typeface for creating sparklines in text without code
        
       Author : OuterVale
       Score  : 51 points
       Date   : 2025-04-02 06:44 UTC (3 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | schobi wrote:
       | 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.
        
         | packetslave wrote:
         | Sparklines have been around (in modern usage) for nearly 20
         | years (coined by Edward Tufte in 2006.
         | 
         | Also, Google is a thing.
        
         | xnorswap wrote:
         | 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.
        
           | esperent wrote:
           | > hence the name
           | 
           | That explains the "lines" part, but whence the "sparks"?
        
           | TomasEkeli wrote:
           | 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.
        
           | mechanicum wrote:
           | > 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.
        
       | zeristor wrote:
       | 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.
        
       | kazinator wrote:
       | [flagged]
        
         | renerick wrote:
         | 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?
        
           | worthless-trash wrote:
           | 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.
        
             | kazinator wrote:
             | 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.
        
               | renerick wrote:
               | 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
        
           | kazinator wrote:
           | 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.
        
             | renerick wrote:
             | > 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?
        
               | kazinator wrote:
               | [delayed]
        
       | dvh wrote:
       | Why no demo image in GitHub readme?
        
         | s4i wrote:
         | There is a gif?
        
       | o1o1o1 wrote:
       | 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?
        
         | Etheryte wrote:
         | 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.
        
       | cromulent wrote:
       | Previously:
       | 
       | https://news.ycombinator.com/item?id=23093815 (2020)
       | 
       | https://news.ycombinator.com/item?id=15223212 (2017)
        
       | cjs_ac wrote:
       | There has also been a commercial offering in this space for a
       | while: FF Chartwell (https://typographica.org/typeface-
       | reviews/chartwell/)
        
         | tiffanyh wrote:
         | 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...
        
           | kbhomes wrote:
           | If I'm understanding the article right, they're actually
           | different fonts as opposed to a single font.
        
       | jszymborski wrote:
       | I wonder what the accessibility implications are.
        
       | layer8 wrote:
       | 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
        
       ___________________________________________________________________
       (page generated 2025-04-05 23:02 UTC)