[HN Gopher] The Tao of Unicode Sparklines (2021)
___________________________________________________________________
The Tao of Unicode Sparklines (2021)
Author : fanf2
Score : 51 points
Date : 2024-08-25 14:42 UTC (1 days ago)
(HTM) web link (blog.jonudell.net)
(TXT) w3m dump (blog.jonudell.net)
| Tomte wrote:
| It's unfortunate that the fill blocks seem to dip below the
| baseline. It looks untidy.
| divbzero wrote:
| OP discusses the below-the-baseline issue describes it as
| "annoying but not a deal breaker".
|
| If this is a deal breaker because you're aspiring for Edward
| Tufte levels of visualization purity, OP also offers an
| alternative that omits below-the-baseline U+2584 and U+2588.
| The trade off is having fewer unequally sized buckets for the
| data.
|
| (Could there be font faces without this rendering issue?)
| divbzero wrote:
| > _(Could there be font faces without this rendering issue?)_
|
| A comment under OP suggests that the rendering issue is font-
| dependent. When I view a Unicode sparkline on a test page
| [1], the rendering issue occurs using Arial, Courier New,
| Gill Sans, Helvetica, or Times New Roman, but appears to be
| fixed if I use Georgia, Menlo, or Comic Sans.
|
| [1]: https://rosettacode.org/wiki/Sparkline_in_unicode
| Gare wrote:
| On (mobile) Firefox they don't. And all are of equal width.
| rbanffy wrote:
| It really depends on the font choice and terminal engine. Some
| terminals (such as VTE, which is the base for most Gnome
| terminals) renders blocks and boxes without using a font, which
| makes them perfectly fit the character cell.
|
| With Unicode 16, which is coming out very shortly, there will
| be 2x4 mosaics (originally identified on Kaypro CP/M machines),
| which have about half the vertical resolution of the blocks,
| but twice the time resolution (and allows us to leave Braille
| for what it was intended for).
|
| After this post came out, Unicode 13 introduced Teletext 2x3
| mosaics and their "smoothed" versions (with diagonal lines).
| Those are also useful for sparklines.
| nsfmc wrote:
| the unicode angle is great for moving sparklines back into the
| terminal especially making it into a postgres function, since it
| makes so much ad-hoc analysis easier at the point of query.
|
| it also solves the problem where sparklines feel useful to
| somebody reading a summary and not so useful to somebody that's
| just exploring data "in the moment." having it be available in
| postgres is brilliant.
|
| a bit of shameless self promotion, i had done something similar
| ages ago but with a custom webfont and some small js to handle
| scaling of the input dataset, solving the problem of unicode
| graph characters not being baseline aligned well.
| http://nsfmc.github.io/chartjunk/ (turns into dust while looking
| at the last commit date)
| throw0101d wrote:
| Meta: for the old fogies out there, Jon Udell used to write for
| _BYTE_ back in the day:
|
| * https://en.wikipedia.org/wiki/Jon_Udell
|
| He stood up their first web site in 1995:
|
| > _One day this spring, an HTTP request popped out the back of my
| old Swan 386 /25, rattled through our LAN, jumped across an X.25
| link to BIX, negotiated its way through three major carriers and
| a dozen hosts, and made a final hop over a PPP link to its
| rendezvous with BYTE's newborn Web server, an Alpha AXP 150
| located just 2 feet from the Swan._
|
| * https://web.archive.org/web/19990128182622/http://www.byte.c...
|
| * https://twitter.com/judell/status/1278883833903898624
|
| * https://vintageapple.org/byte/pdf/199507_Byte_Magazine_Vol_2...
| sonofhans wrote:
| This is a great hack, but it makes bad sparklines. It's probably
| about as good as you can get with unicode, so props to Jon.
|
| Sparklines have a few important properties which these do not
| exhibit. They're typically higher resolution, with more data per
| inch. Also the slopes from point to point, and the whitespace
| under the typical graph/sparkline, help readability.
| pphysch wrote:
| Beyond Unicode, it should be possible to define a Web Component
| that generates SVG on-the-fly from a datasource.
|
| Imagine: <sparkline src="an image or csv"\>
|
| One cool thing about SVG is it can inherit styles from your
| application, so you can produce e.g. dark-mode aware graphics
| rather easily, also one of the perks of this Unicode approach.
| Izkata wrote:
| FULL BLOCK is slightly shorter than LOWER SEVEN EIGHTHS BLOCK for
| me. They would be the same height except LOWER SEVEN EIGHTHS
| BLOCK has some antialiasing that extends a tiny bit higher while
| FULL BLOCK is a solid edge.
|
| Also none of them drop below the baseline in the main page text,
| only in the code block.
|
| (Firefox on Ubuntu 20.04)
| AceJohnny2 wrote:
| (Safari 17 on MacOS 14) FULL BLOCK is the largest to me, but
| also dips below the line by about as much as it is above LOWER
| SEVEN EIGTHS BLOCK.
|
| And unlike the author, LOWER HALF BLOCK (U+2584) does not dip
| below the line.
|
| Aah, multi-platform font rendering... ;)
___________________________________________________________________
(page generated 2024-08-26 23:00 UTC)