linefont: Font for rendering line chart data | Hacker News Reader

linefont: Font for rendering line chart data

github.com

Not to be too negative, but this seems quite inaccessible to anyone using a screen reader or other non-visual output device. Unlike with SVGs or images, there seems to be no way to provide an alternative representation?

Similar to the inaccessibility of icon fonts, but those tend to use private use character codes rather than actual readable text; reading the example page [1] with a screen reader is... not a great experience.

[1]: https://dy.github.io/linefont/scripts/

Are there any other html attributes that could hint to a screenreader what to read or ignore? I can think of more than a few examples when plaintext in a page really should be provided an 'alt' equivalent, if not outright ignored (eg., ascii art, binary strings, etc)

Yes, "alt" equivalent for "textual data representation" is ARIA role="img" with aria-label [0]:

    <span role="img" aria-label="[what assistive technologies should present]">[rendered content]</span>

e.g. recommended for marking up obscure emoji [1].

Anyways, I see absolutely no reason why these projects (wavefont and linefont) build on top of plain ASCII (so the actual data sound as garbled nonsense) and not ligatures of actual figures, so what they "encode" as

abz

could easily be something represented like, for example

  :1 :2 :26

or any other human-readable sequence of characters what would match defined ligatures in the font, or be presented verbatim if the font failed to load/work.

[0] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [1] https://adrianroselli.com/2016/12/accessible-emoji-tweaked.h...

The reason for textual range is maintaining textual selection / editing interactions and 1:1 character<->value matching, so by deleting one character you delete one value.

It is almost same as your suggested representation, just do `String.fromCharCode(values.map(v => v + 0x100))` or manually as `&#x1XX;&#x1XX;&#x1XX;` in HTML.

Related, from the Variable Fonts submission [1]: https://v-fonts.com/fonts/wavefont

[1] https://news.ycombinator.com/item?id=39162937

What's the benefit of using a font instead of vector primitives for rendering a line chart?

It would be an easy way to implement sparkline type charts inline. That is, you could easily mix text and sparklines without having to deal with block elements in html. I can imagine that would make it easier to have the text flow/reflow. I'm certainly going to try it.

Much simpler code and the ability to treat it like text in the browser. This is after all just a font and serializing an array of numbers into a string for this would be a one-liner function.

Responsive charts can be a pain and writing CSS for text is trivial compared to fumbling through yet another ridiculous API and needing a build step.

It looks like the one-liner function comes from their npm library... which requires a build step?

At that point you could just use an SVG charting library. Good charting libraries will have code snippets readily available for line charts that you can copy/paste. SVG can be styled with CSS just like text.

"Simpler code" seems like the main benefit but it comes with a big "weirdness" factor as the tradeoff. I'd bet there's a super lightweight SVG charting lib somewhere out there which is about as simple as this while being much more standard. i.e. supports line charts only, and has the simple type signature `(number[]) => SVGElement`.

Not just simpleness but also performance profit, since the premise is fonts are the most optimized rendering stack everywhere.

Btw that one-liner function is helper, you don't have to install it it, just do `String.fromCharCode(0x100 + value)` to render character.

Its been years since posted here, but this is an alternative sparkline font using contextual alternatives -- https://github.com/aftertheflood/sparks

It seems that in order to plot a time series, one has to pre-process the data to get some glyhps that get rendered.

With modern font stacks, wouldn't it be possible to process comma-separated values directly? There are fonts [0, 1] that censor words without any need for pre-processing. I think this would be beneficial for accessibility.

[0]: https://vole.wtf/scunthorpe-sans [1]: http://projectseen.com

The problem replacing digits like 99,98,100 etc with ligatures of corresponding height is that it would lose 1:1 matching of value to character, so textual selection / operations would be screwed.

Cool! I am going to experiment to see if I can render a line chart column in my data grid product DataGridXL (https://datagridxl.com), which is text-only for performance reasons.

Thanks, I hate it

It would be more intellectually interesting if you told us why you hate it, and perhaps suggestions on how to improve it, or better alternative solutions.

I'll add that "hate" is an overused word that tells us almost nothing, other than your displeasure. Show, don't tell. Instead of telling us that you hate it, show us some concrete facts and specific details. "Avoid describing the author's analysis and instead describe the scene or subject in such a way that readers can draw their own conclusions."

This is a common phrase to denote something weird, unusual, or "cursed"

Thanks I hate it. ;)

That usage of “hate” needs to die.

Reply on news.ycombinator.com