Should we use SVG for screenshots in the README?

[ilyagr]

It seems viable to switch from our PNG screenshots to auto-generated SVG screenshots using tools like https://github.com/slowli/term-transcript, or aciinema + https://github.com/nbedos/termtosvg.

Some of these tools can generate animated screenshots, but I'd prefer to stick with static one for less distraction and more compatibility.

The advantages (hopefully) are a simpler workflow for updating the screenshot and less of an increase to repo size whenever we change the screenshots.

Are there any problems with that? Are there browsers that can't show SVG? I know this repo used Asciinema before and moved away from it, but I don't know why.

This is inspired by the difficulty of updating screenshots for something like #1466 or 5c703ae.

[arxanas]

If I recall correctly, we moved away from Asciinema because we were rendering animation for examples that didn’t require animation to explain, not because SVG etc. was a bad idea.

[ilyagr]

Here are two examples with cargo install term-transcript-cli. I'm impressed.

Looking at their source is also interesting -- they are text and should be compressible by git.

(Note that this is affected by my config; I'd need to add JJ_CONFIG=/dev/null and perhaps impersonate Martin and his computer if I was doing this for real).

I'll see if I can remove the header.

[ilyagr]

One issue is that opening the image in a new tab doesn't show the image in Chrome.

The dev console shows this error:

9265713-7e904105-56ee-4b41-a762-94b242adef7e.svg:67 
Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'none'".
Either the 'unsafe-inline' keyword, a hash ('sha256-3+MP7UGV/RwM1ZTSEYviydIfny9qgoZEjKe6HerBheQ='),
or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers,
style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.
Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

Another issue is that, it seems, the header has to be removed manually. It's easy, though.

[ilyagr]

Final example, with --window option and with the title manually removed.

[ilyagr]

Actually, looking at it more carefully, this tool is having trouble with Unicode widths.

[ilyagr]

Finally (for today), here is termtosvg. It has the same problems with unicode and with being shown in its own tab.

Update: Asciinema has the same problem with Unicode as well. See asciinema/asciinema-player#34.

[ilyagr]

It seems that these SVGs rely on the fonts installed on the system. So, the lines look broken in Chrome on a Chromebook but fine in Firefox on Linux (with whatever fonts I happen to have installed). See screenshots in slowli/term-transcript#51. I haven't found a good way around this. It should be possible to embed the fonts (or even just the relevant parts of them) in the SVGs, but it doesn't seem easy.

Also, these SVGs do not open in Inkscape correctly. SVGs produced by https://github.com/marionebl/svg-term-cli do show correctly, but share the issue with fonts and not opening full-screen when opened via Github.

Here's an example: (pay no attention to jj-old and the difference in the bullets)

I don't know if this is a deal breaker. The upside is that the SVG files are very small and readable in a text editor. (Update: Thought not the svg-term-cli's one; perhaps it ahs some option to not minify)

[ilyagr]

I guess I should mention that if we use SVG, the screenshot in the previous message shows a downside of #1466, since the newer bullets have worse alignment at least when viewing the SVG on my Chrome.

Here's how pieces of the SVG from previous comment look on my machine (PNG screenshots below):

[martinvonz]

I like the idea of using SVG, but probably only if we can get it to render nicely on most systems. If it's easy to embed a font and it doesn't use too much space, then that seems like a good solution to me.

[ilyagr]

Agreed. I couldn't find an easy way to do it yet, only instructions on how to do it manually which don't look very fun.

There's also the notion of optimizing the font (embedding only the characters we need), which sounds great in theory but would be another, likely not very fun, step.

[ilyagr]

I put some more observations about fonts & SVG at #2231 (comment).

In particular, a lot of the font problems also apply to code block sections of the documentation website at e.g. https://martinvonz.github.io/jj/v0.9.0/tutorial.html#the-operation-log.