Sparks – A typeface for creating sparklines in text without code(github.com)
55 pointsby OuterVale15 days ago10 comments
  • schobi12 days ago
    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.

    • xnorswap12 days ago
      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.

      • mechanicum12 days ago
        > 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.

      • esperent12 days ago
        > hence the name

        That explains the "lines" part, but whence the "sparks"?

      • TomasEkeli12 days ago
        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.

    • packetslave12 days ago
      Sparklines have been around (in modern usage) for nearly 20 years (coined by Edward Tufte in 2006.

      Also, Google is a thing.

  • layer812 days ago
    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

  • cjs_ac12 days ago
    There has also been a commercial offering in this space for a while: FF Chartwell (https://typographica.org/typeface-reviews/chartwell/)
  • o1o1o112 days ago
    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?

    • Etheryte12 days ago
      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.
    • helpfulContrib12 days ago
      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.

  • zeristor12 days ago
    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.
  • jszymborski12 days ago
    I wonder what the accessibility implications are.
  • dvh12 days ago
    Why no demo image in GitHub readme?
    • s4i12 days ago
      There is a gif?
  • kazinator12 days ago
    [flagged]
    • renerick12 days ago
      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?
      • kazinator12 days ago
        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.

        • renerick12 days ago
          > 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?

          • kazinator12 days ago
            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.

      • worthless-trash12 days ago
        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.

        • kazinator12 days ago
          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.
          • renerick12 days ago
            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

          • worthless-trash10 days ago
            Sir your first mistake was that you think that this was mockery.
  • mtillman12 days ago
    [flagged]