visual glitches in PNG and SVG when using `▄` character

[philschatz]

Thanks for a great recording/playback tool! It's much nicer than posting GIFs for terminal recordings.

I noticed that in some cases the ASCII characters do not line up properly in the PNG and that the font adds additional padding around the ▄ character.

The issue I am running into is that I use ▄ to show 2 "pixels" with different colors. Unfortunately, that results in several graphical glitches on the web and is even weirder in the PNG screenshot. See example below:

Screencasts

Here is a screenshot of the "glitchy" SVG:

Here is the mangled PNG screenshot:

And here is an example of using (space) instead, which works but results in a 4x larger recording:

I will keep using a for my demos and recordings (more are at https://github.com/philschatz/puzzlescript-cli) but thought I would post in case others are running into similar issues.

[ku1ik]

This is a tricky one. Browsers display these block characters inconsistently, and since we use text only at the moment for anything that's displayed, there's no easy way. One aproach would be to render all the special "drawing chars" separately, not through text but with small SVG elements. That would require a change to the way we render (not a huge change, but still not trivial).

(btw, the web player doesn't use SVG - it uses HTML with a bunch of styled <span> elements)

[dimo414]

Just wanted to call out this issue shows up even in "featured" casts like https://asciinema.org/a/423213. Also, is this a dupe of asciinema/asciinema-player#71?

[ku1ik]

It is related to line height, and terminalLineHeight option added in asciinema/asciinema-player#175. It's worth a try but this would a best-effort option as it won't guarantee the same exact alignment of blocks (vs line height) across all platforms and browsers.

The only sure way of making blocks align would be to render them with canvas overlay or something in that vein, instead of relying on browsers' text rendering capabilities.

[ku1ik]

Block alignment can be fixed by setting terminalLineHeight: 1.1 option when using standalone player.

I'm moving to asciinema-server repo as we need to expose this on asciicast settings page there.

[ku1ik]

There's new option on asciicast settings page now - Terminal line height:

I've set it to 1.1 on @philschatz's recording, and to 1.2 on the mentioned featured recording. IMHO they look pretty good now.

[dimo414]

Cool! https://asciinema.org/a/i1NFHEiodvDBQlx5mvKIWw3yV looks much better than the screenshots above, though there are still some artifacts. However https://asciinema.org/a/423213 still has clearly visible artifacts.

[ku1ik]

Yeah, there are still the vertical lines in the first one. This is not related to line height but likely to text spacing in a browser. Not sure if can be fixed without reimplementing the renderer with canvas...

The second one looks fine on my machine (Firefox on Arch Linux):

I guess there are text rendering differences between platforms/browsers that it would be hard to completely mitigate.

[ku1ik]

The above screenshot was for line height 1.2 that I set on the recording earlier. I've now adjusted it to 1.15, let me know if it looks fine for you now.

[dimo414]

Yeah unfortunately still seeing artifacts (I'm using Chrome on Windows, fwiw).