Show HN: Termtosvg – Record terminal sessions as SVG animations
github.com
github.com
As others have mentioned, the major issue with SVG animations is that Microsoft doesn't plan to ever include support for them in Edge. This means that you either need to create fallbacks specifically for Microsoft browsers, or to disregard that portion of the market on your website. It's a real shame because SVG/SMIL allows you to create high quality animations which require a fraction of the bandwidth that would be necessary for comparable GIF or video files.
[1] - https://github.com/sangaline/svganimator
[2] - https://intoli.com/blog/designing-the-wayback-machine-loadin...
Shitty of Microsoft, though. If they aren't going to support it, it's not going to be widely deployed. I expect better of the new and improved Microsoft.
They've got no authority to do that. There is no trademark on 'web' that they could enforce.
I think sometimes this is because the full spec is infeasible to implement, at least in a performant manner, and rather than implement a fully compliant but slow mess, they implement a partially compliant but usefully fast subset.
Providing a reference implementation allows a standards body to learn early that what they are speccing is counterproductive in one manner or another, prior to releasing it and getting vendor feedback.
Anyway, I totally agree that there should be a reference implementation. Imho, preferably in a purely functional language, to keep it as clean as possible.
Oh, I'm not defending Microsoft specifically, they're generally pretty horrible on this front. All the browser vendors have components in various states of compliance though, and some components seem to sit at a certain level for years.
Using SVG definitions efficiently to avoid duplication is also not as easy as I thought it would be.
I have a few ideas on how to reduce file size, this is the next improvement I'm planning to work on.
For the examples shown at [1], file size ranges from 56kB to 252kB, the worst case scenario being lots of single characters with different colors.
[1] https://github.com/nbedos/termtosvg/blob/master/examples/exa...
http://pieroxy.net/blog/pages/lz-string/index.html
https://github.com/pieroxy/lz-string/blob/master/libs/lz-str...
~5kb gets you an lz-decoder, and you should be able to pull a bunch of trickery with blobs and compressed strings to get somewhere?
And here I thought the Edge team left behind the mistakes of IE.
https://developer.microsoft.com/en-us/microsoft-edge/platfor...
> In the 15 months since we announced our intention to deprecate and eventually remove SMIL, we’ve heard a variety of opinions from members of the community. We value all of your feedback, and it's clear that there are use cases serviced by SMIL that just don’t have high-fidelity replacements yet. As a result, we’ve decided to suspend our intent to deprecate and take smaller steps toward other options.
I understand that they don't have an infinite budget, but it really seems like they made their mind up here years ago and haven't been interested in listening in the community since then. It's also a bit circular to "prioritize based on how common the standards are found used in the wild" when they're single-handedly responsible for preventing developers from using SVG animations "in the wild" in the first place.
[1] - https://wpdev.uservoice.com/forums/257854-microsoft-edge-dev...
[2] - https://developer.microsoft.com/en-us/microsoft-edge/platfor...
[3] - https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
> It's also a bit circular to "prioritize based on how common the standards are found used in the wild" when they're single-handedly responsible for preventing developers from using SVG animations "in the wild" in the first place.
It certainly is a chicken-and-egg bootstrapping problem. Though the increasing prevalence of "Works Best in Chrome"/"Works Only in Chrome" dominance may suggest that Edge is still in a position to follow the trends than attempt to lead them on ancient W3C standards like SMIL.
[0] https://developer.microsoft.com/en-us/microsoft-edge/platfor...
I suppose the main barrier would be lack of recorded timing information in script logs, so either pre-procesding or pause for input (say 50ms/keystroke + 200ms pr return/line-feed) and/or output (say 50ms pr line feed).
Although, now I see there's a -t option for a timing file.
So would seem one should be able to take logs from script, and produce svg, gif, png, webm, mp4... js output.
Simply call it with "shell-demo DEMO_SCRIPT", and follow the instructions.
Demo scripts examples are given aside the snippet.
But how does it compare? Is the size smaller, is it more efficient?
As I explained in the above article, this is already possible with asciinema + svg-term-cli (https://github.com/marionebl/svg-term-cli).
The one downside with animated SVGs is that they're not as compatible to be included anywhere as GIFs since they're really just html snippets.
Editing the HTML attribute to width=2000% is pretty sweet however because it's a vector.
I'm guessing if the example wasn't in an image tag I could select the text too?
Block artifacts are really annoying when you try to read something on screen recordings.
And svg texts can be made selectable when not loaded as images, so you could copy straight from the recording.
Being an `asciinema + svg-term-cli` user myself, what are the arguments for moving to `termtosvg`?
Thanks!
How hard would it be to add some sort of pause button to aid in selecting from the capture? Also, it appears you can only select when you are viewing the image directly, not when it is embedded via an <img> tag. Is that fixable? I guess maybe an <iframe> might work, but I haven't played with it yet.
It would be good to adjust the failure mode so that if SMIL is not supported then at least a meaningful frame (probably the last, though scrolling makes it difficult to decide!) is shown, rather than just a blank rectangle.
[Edit: This seems to be a macOS/driver bug affecting only some models]
Asciinema does not care about your terminal size when recording. In fact you can even reduce it or hide it (if you automate the input). Then you render it with svg-term-cli with the width you feel it is best.
It's written in modern Python and well documented. However, some functions are a bit monolithic: https://github.com/nbedos/termtosvg/blob/master/termtosvg/te...
What are the advantages over "asciinema"?
At the moment I only see that it does not require a specific player (javascript for the web), on the other hand it seems you are not able to pause the "execution".
You can view the animation without javascript enabled, and it's media type is image, you don't even need to convert it to base64 to use it. It's like gif but relatively smaller and with more colors, and it's Scalable Vector.
The output is an SVG animation so you can modify it as you want. For example you could add a last frame with the logo of your project.
Not being able to pause the animation is annoying, I will probably add some way to it with ECMAScript in the future.
It's a super old version of asciinema (I haven't bothered to update it). Also, I recommend increasing the playback speed using the '>' key a couple of times so you don't have to suffer from my pathetically slow typing.
Similarly, I've never seen this sort of thing used professionally, just on blogs and project demos.
One thing you could do with this is making SVGs from applications such as htop (or _any_ terminal application), and then serving those over WWW. You can then view those in a web browser by going to a certain date (some HTML/JS would be used to neatly organize them in a good UI, or allowing things such as looping and going forward or backward, but you could also use data analysis on the SVGs).
Sure, you could export log data and then use MRTG/RRDTool or something like that and it'd work just as well. My point is that you need support for that (via e.g. SNMP); with Termtosvg you abstract all terminal applications.
Anybody tried termtosvg with different browsers yet?
That said, I'm absolutely loving this as the file size and the memory footprint of this SVG is super-small relative to what a .gif of the same content would be. Great work!
One bug I noticed is that it seems to break virtualenv which is made with --system-site-packages its not finding the modules
I had just thrown together a typescript bash script to record IRC with timing for later playback and sync with a podcast, the trick is the rendering step: in theory it could be done on a canvas with native ffmpeg drawtext, but the invocation is super gnarly.