Visual artifacts in the output when viewing in certain 3rd party applications

[InCom-0]

So nice, would you like me to close this issue or will you do it?

I was able to build a container which accepts input from stdin:

duckdb -csv -c "from 'https://gist.githubusercontent.com/slopp/ce3b90b9168f2f921784de84fa445651/raw/4ecf3041f0ed4913e7c230758733948bc561f434/penguins.csv' limit 10" | \
sed 's/NA//g' | docker run --rm -i incplot sh -c "incplot -w 80 -t 24 | head -n 24"

    197 ┬                                                      ┐
        │⠀⠀⠀⠀⠀⠀⠀⢀⣀⠤⠖⠚⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠦⠤⠤⠤⢄⣀⣀⠀⠀⠀⠀⠀⠀⠀⢀⣠⠴⠚⠒⠒⠒⠒⠒⠒⠤⠤⠤⠤⢄⡀  bill_length_mm
        │⡠⠤⠤⠖⠒⠒⠉⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠉⠓⠒⠤⣄⠴⠚⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀  bill_depth_mm
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀  flipper_length_mm
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
    148 ┤⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
    104 ┤⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
     60 ┤⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
        │⠤⠤⠤⠤⠤⠤⠤⠤⠴⠒⠒⠒⠒⠦⠤⠤⠤⠤⠤⠤⢤⣀⣀⣀⣀⣀⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⣄⣀⣀⠀⠀⢀⣀⡤⠤⠒⠒
        │⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠉⠁⠀⠀⠀⠀⠀
        │⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⡤⠤⠤⠤⠤⠤⢤⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣀⣠⠤⠄
     15 ┼──────────┬──────────┬──────────┬──────────┬──────────┤
        832m      2.7        4.5        6.4        8.2        10

It looks great in the ghostty terminal:

I then attempted in various ways to paste the output into various editors (kate, nano) but was never able to get just the plain unicode text to display with a monospace font (fixed width) in a "fully justified" fashion. Maybe the braille symbols somehow can mess up the total row width. Do you think a monochrome output in plain unicode/extendedascii could be an output option?

For color output in HTML, I tried using aha (https://github.com/theZiz/aha) and I see the same thing there, again perhaps it is something I have not been able to configure with regards to fonts on my system:

duckdb -csv -c "from 'https://gist.githubusercontent.com/slopp/ce3b90b9168f2f921784de84fa445651/raw/4ecf3041f0ed4913e7c230758733948bc561f434/penguins.csv' limit 10" \
| sed 's/NA//g' | docker run --rm -i incplot sh -c "incplot -w 80 -t 24 | head -n 24 \
| aha --black" > aha.html && firefox aha.html

It looks better when the box drawing glyphs are involved, like in this horizontal bar plot, that's why I was thinking the braille glyhps width might be somehow causing that misalignment. For example, try:

docker run --rm -it incplot sh -c "script -q -c 'wget -qO /dev/stdout https://csvbase.com/calpaterson/iris.csv stdout.typescript && cat stdout.typescript' | incplot -w 80 | aha" > aha.html && firefox aha.html

Originally posted by @mskyttner in #1

[InCom-0]

This would appear to be directly caused by Firefox (or whatever other browser/application) not rendering monospace font but rather using some proportional one.

It can be perhaps more clearly seen in the html file attached (assuming similar browser settings), where the 'block characters' that are only 'partial width' (those are at the end of the bars) are simply more narrow.

wget -qO /dev/stdout https://csvbase.com/calpaterson/iris.csv | incplot -w 80 -t 24 | head -n 24 | aha > t4.html

t4.html

Essentially, incplot cannot solve this on its own.
However (having near zero knowledge of browsers and web tech in general), couldn't it be possible to coax aha (or some other tool) to emit html in such a way so that it makes Firefox actually render using some monospace font? On top of that it would of course need to be a font that has all the glyphs that incplot uses ... and also making sure that they actually fit well for this particular usecase, because that is also not given eventhough most modern monospace fonts should probably be fine.

[InCom-0]

Oh ... and regarding monochrome option.

Originally I thought it actually caused more problems than it was worth and it really only makes sense with a single series in the plot.

One thing that would be amazing for 'monochrome mode' would be the ability to use something like this:

However, that is really really not compatible with ANSI and therefore would require an entirely different approach to the whole thing :-).

[mskyttner]

Yes, injecting some static webfont into the html output from aha might work.... as a base64 encoded asset...

ANSI-compatible would be those block elements in Unicode you are using in horizontal bar plots, since those allow for four intensities in shading, besides the full block if limiting to one character "pixels":

U+2591 ░ Light shade
U+2592 ▒ Medium shade
U+2593 ▓ Dark shade

So, 2-bit grayscale if using (only) full block elements is possible (?)

For 1-bit monochrome b/w there are the block element "quadrants" and "eights", not as high res as braille (there you get 2w x 3 or 4h with glyphs for all combos). The "quadrants" can encode a 2x2 matrix, besides the full block there are U+2596 ▖ Quadrant lower left, U+2597 ▗ Quadrant lower right, U+2598 ▘ Quadrant upper left etc. The "eights" block elements don't offer glyphs for all the combos, only those that fill in either x or y directions. So in comes braille which provides monochrome (1 bit of "color") glyphs available for all combos of that 2x4 grid.

The box drawing characters in Unicode come in two intensities, like ┈ and ┉ for example, so combining box drawing + block elements + braille maybe around 1.5 bits grayscale is theoretically possible, slightly more than monochrome, as one probably doesn't want to resort to using multiple characters to provide "shades"? :)

[InCom-0]

Yea, these are certainly possible to use.

When I started with this I actually tested all kinds of different possibilities including the ones you mention. More than anything, the lack of fine-grained 'resolution' is a big drawback in practice ... it might be subjective, but plots produced using some of these options simply do not 'look good' imo, which kind of defeats the main premise of the tool :-)

[mskyttner]

The screenshots you provide look great.

Do you have any recommendations or examples of fonts which work especially well in (and outside of) the terminal application? Which one did you use for the screenshots?

[InCom-0]

Well ... all the modern monospace coding fonts seem to work really well as far as I know (not that I have done some rigorous testing or anything).

The screenshots in the repo are all JetBrains Mono Nerd Font. There are plenty of really great monospace coding fonts available here: https://github.com/ryanoasis/nerd-fonts
Ultimately though this is strongly a matter of personal preference.

[mskyttner]

Regarding the jagged left and right edges of the plots, I tried a number of fonts and with a few of these the issue disappeared, specifically:

• https://www.programmingfonts.org/#adwaita-mono
• https://www.programmingfonts.org/#ioskeley
• https://www.programmingfonts.org/#iosevka
• https://www.programmingfonts.org/#unifontex ("name records are not sorted")
• https://www.programmingfonts.org/#terminus
• https://www.programmingfonts.org/#spleen
• https://www.programmingfonts.org/#old-timey
• https://www.programmingfonts.org/#fairfax-hd

For all the others I would see jaggedness with the (web)fonts.

I tried making a container which can convert the output to various formats and embeds the adwaita-mono webfont (.woff) and plots then look good when included in a webpage.

This https://stackoverflow.com/questions/44359865/pre-not-consistently-monospace-with-braille-characters says there is a "braille space" character which may have a different width compared to regular space characters in fonts, which could perhaps introduce a jaggedness on lines which have both "regular spaces" and "braille spaces" (?)...

Attached is a .html with these experiments for different formats (raster, svg, html, plain text) - no jaggedness when that specific webfont is used (for me, using Firefox)... perhaps that (web)font has the same width for both regular and braille "spaces"?

demo.html

[mskyttner]

With this font the issue also is not present (for me): http://viznut.fi/unscii/

[mskyttner]

So why would the jaggedness not appear in ghostty for me? Possibly due to this: https://deepwiki.com/ghostty-org/ghostty/4.3-sprite-fonts-and-built-in-glyphs#sprite-fonts-and-built-in-glyphs. Something about that app treating braille and other "legacy glyphs" differently, maybe to fix similar issues that would otherwise appear when combining certain established "legacy glyphs" (braille, box drawing etc) with more modern unicode glyphs (emojis etc). Perhaps other terminal emulators do the same, I don't know.

If that hypothesis holds, it would explain why the visual artifacts becomes evident in various other (non-terminal) applications (text editors, web browsers etc) when output from incplot is displayed there (unless a specific font is used which spaces braille spaces equally to regular "ascii" spaces), when those apps respect the "real" metrics of whatever current font is used?

It seems on my system the widths of regular space vs braille space differs among various fonts, judging from the output from this script:

fc-list | grep -o ".*\.ttf" | \
python3 space_widths.py | \
duckdb -c "copy (from read_csv('/dev/stdin') select path: regexp_extract(#1, '(.*)/(.*)$', 2), w_regular: #2, w_braille: #3, diff: w_regular - w_braille, is_equal: w_regular = w_braille where w_braille is not null and regexp_matches(path, 'Jet|unscii|Adwaita') order by is_equal desc, path desc, diff desc) to '/dev/stdout' (format CSV, header true);"

space_widths.py

However some fonts have the same settings for "space widths".

path,w_regular,w_braille,diff,is_equal
unscii-16-full.ttf,8.0,8.0,0.0,true
JetBrainsMonoNerdFontMono-Regular.ttf,9.59375,9.59375,0.0,true
AdwaitaMonoNerdFontMono-Regular.ttf,9.59375,9.59375,0.0,true

Otherwise if not using such fonts, it seems that in order to align when using braille characters within a subregion / rectangle of the "display area" / text canvas, also any space characters outside (left or right) of the (rows) with the rect would also need to use braille space characters (?)

Not even sure if this is the real issue or if something happens in the text editors / web browsers rendering of text that causes the jaggedness.

[InCom-0]

So far this would appear to be a direct consequence of using a font that (even if monospace itself) does not physically include the braille glyphs (or perhaps other ones like the box drawing glyphs) in its own codepage. What happens then (apparently) is that the browser uses glyphs from some other font and this other font is either A) not monospace or B) even if monospace, the specified width may not be the same as in the font the user specified.
https://stackoverflow.com/a/9353011

In effect this is not really related to a (potential) difference between 'braille space' and 'regular space'. It is actually (as above in the first post) that the braille characters are picked from a different font and are wider than all the other characters (including digits and letters).

I will look deeper into this, whether there isn't some way to 'hack' this to essentially coax the browser to always pick the glyphs in such a way that it displays correctly. I actually decided to integrate the option to emit the result as .html into incplot itself (however, this will certainly take some time).

However, don't get your hopes up that this could be solved for the 'universal' usecase :-). Odds are the only realistic way to solve this is simply to only use fonts for which it works ... or potentially hack together some custom fonts that include all the glyphs incplot actually uses and just use those ...

[mskyttner]

Interesting, sounds likely then that some fallbacks are kicking into gear in some apps.

Thanks for looking into it and it would be awesome to have a clean minimal html output stream from incplot, maybe with an option to get something that looks good in a pre or code tag.

Whatever is done with CSS etc at https://www.programmingfonts.org/#adwaita-mono seems to fix the issue for me; maybe it is a textarea that was styled in some way that make Firefox display copy/pasted output from incplot properly, but it seems to depend on the font used in that case.

The ansisvg go utility I think has some tricks (including some grid option) that appear to work well too and it also offers fairly clean small output, but plain html with some css styles would be preferable to SVG since it would be easier to just fish out the "monochrome" plain text by selecting and copy/paste.

In general I think the low res of these text plots is not only a negative since it also limits the design space in a fruitful way too, forcing some hard choices and discipline in order to avoid issues with too small text labels, overuse of colors, occlusion, readability etc. This can obviously give plot designs that can be easy and simple to read and understand.

[InCom-0]

Did some exploration.
Turns out the crux of the issue really is what it seemed, that is: hardly any font (monospace or otherwise) physically includes the 'Braille Patterns'.

Making it work requires 3 things simultaneously: 1) font that is actually monospace, 2) font that is available on the machine rendering the html, 3) font that includes all the glyphs incplot may ever emit. Can't really use 'fallback' fonts for anything because then it all depends on whether it has exactly the right width which it won't have except by chance and it would also be kind of brittle design-wise.

The only plausible way to make that work in a truly universal manner is to actually embed a monospace font that has all the glyphs that incplot might use. One could hypothetically use a system installed font ... but who knows what fonts are actually installed on which system. So one can't really do it, because odds are the html is intended to be rendered on a machine the user doesn't control or know anything about. This is especially the case for the more 'exotic' programming monospace fonts.

Another problem is that font files are not exactly tiny (around 1-2MB). At this moment I think the solution would be just to embed one of the fonts that work. When I get around to implementing the html output into incplot itself, I will probably just make it embed some 'minified' font into it automatically.

Note: All this mostly works in terminals because terminals use a different way to render the text and they keep the width/spacing the same regardless of the fact that they almost always have to pick the braille glyphs from some other font.

Also note: Some terminals try to be smarter and perform custom 'rendering adjustment' to various special glyphs ... so completely identical fonts might actually render differently in different terminals ... but this shouldn't be a real problem here.

In general I think the low res of these text plots is not only a negative since it also limits the design space in a fruitful way too, forcing some hard choices and discipline in order to avoid issues with too small text labels, overuse of colors, occlusion, readability etc. This can obviously give plot designs that can be easy and simple to read and understand.

Absolutely, it is a double edged sword.
One can't really do everything one might want to do ... but at the same time forces one down the few paths that actually work really well.

[mskyttner]

What an interesting idea to emit a minimal webfont file "on the fly" when outputting html.... I would like to have that in incplot!

I made a quick and dirty test taking only the unique unicodes present in an incplot and then subsetting the unscii ttf, generating a custom .woff which is embedded in a webpage with a pre tag which displays the plot.

The .woff emitted was around 2k for that specific plot so maybe not too heavy after all. Since the webfont file (on disk) is not even as large as the 2.6k that the plot itself used (plot_scatter.txt) on disk - 80 chars wide. And I think there is room for minifying/compressing more.

See example output here with some css styles that seem to work for me (Firefox/Chromium doesn't complain):

embedded.html

Generated from a "template" like this one:

template.html

The steps are described here:

unscii-subset.html

The script used to extract unicodes from text (plot) files:

extract_unicodes.py

[InCom-0]

This is excellent! Exactly where I was going with this.

2k or less than 50% of the html file is insignificantly small and it would take way smaller portion of the file if used together with ANSI coloring instruction and/or when applied to bigger plots.

Two more things to consider:

1. We actually almost know all the glyphs incplot may emit upfront. So maybe we might not have to parse the whole thing. The only problem with that is: the labels and series names might include literally anything (eg. emoticons or japanese characters) ... therefore I am not seeing a way to avoid the parsing (which will no doubt add non-negligible computational cost) even if its probably going to be useless 99,9% of time. The good news is that speed doesn't really matter when emitting html.
2. It will need some 'sensible default' font shipped with it that includes virtually everything so that it 'always works' when the user doesn't want to or can't provide his own font ... also it would be real nice if it were 'smart enough' to inject all the missing glyphs into any monospace font the user provides and adjust the widths if need be ... that would be true magic :-)

[mskyttner]

Interesting, injecting/overriding glyphs in someone's favorite monofont sounds like a powerful feature.

Maybe the unicode-range descriptor in CSS can be used to provide a small slice of the more frequently used incplot "pixels", making sure those are present and used in the html, circumventing other local fallbacks to kick in and mess up alignments.

Unicode ranges like braille U+2800 - U+28FF and maybe even box drawing (U+2500 - U+257F), block elements U+2580 - U+259F and legacy computing U+1FB00 - U+1FB3B perhaps then could be bundled for web clients to use.