Show HN: Termtosvg – Record terminal sessions as SVG animations(github.com)
github.com
Show HN: Termtosvg – Record terminal sessions as SVG animations
https://github.com/nbedos/termtosvg
83 comments
Honestly, if you're recording terminal sessions, it's probably fine to not support Edge. I doubt any significant portion of your audience is going to be using it, and even if they do, they're going to be perfectly understanding when you say "sorry, Edge doesn't support SVG animations, use a different browser".
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.
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.
W3C should have a rule that a web browser which does not intend to support the standard may not call itself a "web browser".
Those web browsers would probably also not support your new standard, and continue to call themselves web browsers.
good catch :)
> W3C should have a rule that a web browser which does not intend to support the standard may not call itself a "web browser"
They've got no authority to do that. There is no trademark on 'web' that they could enforce.
They've got no authority to do that. There is no trademark on 'web' that they could enforce.
I'm pretty sure no browser supports 100% of SVG spec.
Facts like these always drives me crazy... these companies (namely Microsoft, but I guess Google/Mozilla as well a bit) have huge teams and resources, and can't build a browser that follows specs that have been hammered out only after years of work.
There's a reason why some bodies ship a reference implementation with the standard. Sometimes what's specified is infeasible, or even impossible (if the spec contradicts itself) to implement.
But what if the other vendors do have an implementation?
This is in the context of an upstream comment (softly) claiming that now browser has 100% SVG support.
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.
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.
Ok, but it's not like Microsoft can't discuss with W3C any problems (in their view) in the standard.
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.
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.
> Ok, but it's not like Microsoft can't discuss with W3C any problems (in their view) in the standard.
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.
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.
Opera (Presto) supported 100% of the SVG standard, if I remember correctly.
That doesn’t mean they can’t be expected to support a meaningful subset. Honestly I don’t even know what they’re thinking here: they have no real alternative.
[deleted]
The least to say. SVG support is abysmal in many browsers. PDF support in browsers seems to be much more complete, even though it's much more complex.
OP here. Sadly, SVG file size is not as small as I'd want it to be. The main problem is that a few attributes (x, y and lengthAdjust) have to be repeated on each text tag to position each character at the right place. I can't use CSS for this since those attributes are not styling attributes.
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...
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...
What about embedding a mini ECMAScript player and apply values to the DOM on the fly ?
I'd rather stick to plain SVG for the animation part, in case ECMAScript is stripped from the SVG for security reasons. ECMAScript might be worth adding for additional features though (play/pause, progress bar, frame seeking...)
Why not `zip blah.zip blah.html` and do it all as a single html doc?
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?
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?
it's actually possible to reduce duplication in this case with the <g> element, see this example;
https://jsfiddle.net/2kc6tqy1/2/
https://jsfiddle.net/2kc6tqy1/2/
> the major issue with SVG animations is that Microsoft doesn't plan to ever include support for them in Edge.
And here I thought the Edge team left behind the mistakes of IE.
And here I thought the Edge team left behind the mistakes of IE.
Edge doesn't have an infinite budget, and they say they've tried to prioritize based on how common the standards are found used in the wild and how active the requests on UserVoice are. Doesn't look like there is even currently a tracked UserVoice for it:
https://developer.microsoft.com/en-us/microsoft-edge/platfor...
https://developer.microsoft.com/en-us/microsoft-edge/platfor...
[deleted]
It's in there under "SVG+SMIL Animation" but the status is "Not currently planned". Here[0] they say that they consider the feature deprecated.
[0] https://developer.microsoft.com/en-us/microsoft-edge/platfor...
[0] https://developer.microsoft.com/en-us/microsoft-edge/platfor...
It is on UserVoice [1], and it has over two thousand votes there. They've marked that as "sorry, no plans," and they've marked previous issues as "by design" [2]. They use Chrome announcing plans to deprecate SVG animations as their primary justification, but Chrome backtracked on those plans after realizing that there were important use cases that mattered to the community [3].
> 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...
> 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 is fascinating the interplay between the Chrome team, and WHATWG on SMIL. It's one of those W3C standards from the W3C's "XML all the things" years that you can tell browser teams aren't entirely thrilled with. Quick searches seem to indicate that WHATWG's overall take seems to be that all SVG animation support would be better in CSS Animation and that they'd also prefer to punt SMIL.
> 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.
> 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.
That it a bummer. Any thoughts on the feasibility of outputting js canvas instead? And the performance file size tradeoffs
My first thought was "this seems neat", and my second thought was: how hard would it be to write a small js script to play back "script"[s] output? Or, to take script output, convert it to some pre-tags and add js animation on top of that...
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.
[s] http://man7.org/linux/man-pages/man1/script.1.html
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.
[s] http://man7.org/linux/man-pages/man1/script.1.html
the timing information you want is what 'ttyrec' is for http://derpi.tuwien.ac.at/cgi-bin/man/man2html?1+ttyrec
I did that in another way: write a demo script, and make it execute in another terminal. Snippet on GitLab [1].
Simply call it with "shell-demo DEMO_SCRIPT", and follow the instructions.
Demo scripts examples are given aside the snippet.
[1]: https://gitlab.com/snippets/1730340
Simply call it with "shell-demo DEMO_SCRIPT", and follow the instructions.
Demo scripts examples are given aside the snippet.
[1]: https://gitlab.com/snippets/1730340
Excellence! The README reads:
"I really like the clean look of SVG animations and I also wanted to see how this solution would hold out against other attempts at terminal recording such as asciinema."
But how does it compare? Is the size smaller, is it more efficient?
But how does it compare? Is the size smaller, is it more efficient?
Animated SVG animations (really just an svg element + animated css) are significantly smaller, more efficient, and crisper than equivalent GIF animations. I wrote about the difference between the two here: https://hackernoon.com/presenting-your-code-beautifully-fdba...
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.
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.
You're competing with webm / mp4 not gif though.
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?
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?
If you click on the example image to view it in a new tab, you can select the text there. It could be improved, afaict you can only select a single line of text at a time and if you select the current line being typed then the selection is cleared when that line is modified.
video codecs are not the right tool for this job. Consider subpixel-AA for fonts, partially transparent backgrounds, 4:4:4 instead of 4:2:0 and the ability to zoom as you mentioned.
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.
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.
Thanks for putting your effort on this! It seems pretty great.
Being an `asciinema + svg-term-cli` user myself, what are the arguments for moving to `termtosvg`?
Thanks!
Being an `asciinema + svg-term-cli` user myself, what are the arguments for moving to `termtosvg`?
Thanks!
Asciinema is not gif. The text be zoomed in and is still super crisp and you can select the text.
This is great for many of the same reasons that asciinema is great -- smooth animation and selectable text. The resulting svg is orders of magnitude smaller than a gif would be.
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.
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.
I wonder if you could just use a javascript button to pause the animation and if that would make the text selectable.
The primary casualty of using SVG animations is IE/Edge support; SMIL is not currently planned: https://developer.microsoft.com/en-us/microsoft-edge/platfor....
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.
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.
Jesus, it's 2018 and they still can't even figure out how to implement animated PNGs? Real browsers had this 10 years ago. What the hell is wrong with Microsoft? Are they really just so incompetent, or is there a more insidious business reason why they don't want more animated formats on the web?
SMIL is something quite different and much more complex, than "animated PNGs"
Firefox had (and pioneered) APNG ten years ago. Safari added APNG support four years ago. Chrome only got APNG just over a year ago.
The example animation looks broken in Safari (including Tech Preview 59), works in Chrome 67 (of course), and in Firefox 61.
[Edit: This seems to be a macOS/driver bug affecting only some models]
[Edit: This seems to be a macOS/driver bug affecting only some models]
It also doesn't work in the Windows default browser, but I think that's an Edge case.
It's broken on my 2014 MacBook Air with Safari 11.1.1. Works OK on Firefox and Chrome.
I don't see any problems with Safari 11.1.1 on macOSX or on mobile Safari on my iPhone.
Right. It works on my 2013 MacBookPro, but the drawing looks incomplete/broken on my 2015 Retina 5k iMac. Both run macOS 10.13.5.
all examples work for safari 11.0.3
Sadly, I will not replace asciinema+svg-term-cli by termtosvg, because termtosvg takes the terminal size into account when recording, not when rendering. It means that I have to resize my terminal before recording, and that I will not be able to resize it differently for rendering. So if lines are wrapped, I cannot change the width to de-wrap them in the resulting SVG.
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.
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.
I'm very impressed - it combines two of my favourite technologies, Python and SVG. Three, in fact - including terminal. I will be watching it and tinkering with it.
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...
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...
Cool. It is not very clear from the description so I will ask:
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".
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".
I think standalone is the most outstanding advantage. Many recordings of terminal are using asciiema or youtube, those links in a github readme.md file is a static screenshot instead of animated one, you have to click the link to watch the animation.
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.
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.
Yes, there is no dependency on a specific player.
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.
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.
What're people using tools like this for? I see the usage surely when demonstrating something in the terminal - and many times used for showcasing projects and tools. Are you using the recordings for other purposes, like to document work and share progress with your team + manager for instance for work you're doing during a sprint (good for demo'ing things at the end of the sprint too).
I did an experiment a couple of years ago where I wanted to see if I could write code 1 pomodoro a day. I recorded myself in asciinema. It's basically several 25 minute pomodoros of me implementing Core Wars (a VM for machine language programs that battle against each other) in Ruby. I hadn't written Ruby in a while and I was more interested in playing experimenting with a TODO list for being efficient with such a small amount of code per day, so the code is not really fantastic. However, if you are interested I did about 60 pomodoros, I think: https://mikekchar.github.io/core-wars-kata/
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.
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.
It's good for right-way vs wrong-way demonstrations. If I just copy the text out of my terminal and say "this is how we used to do it; this is how we should do it/will do it now" and paste it in a jira ticket, not many people will take the time to read and understand. Gifs are more accessible I guess.
Maybe it's just me, but I can't stand having to wait to watch someone slowly type something when all I want to to is know the command or understand what some output should look like.
Similarly, I've never seen this sort of thing used professionally, just on blogs and project demos.
Similarly, I've never seen this sort of thing used professionally, just on blogs and project demos.
It really should have a timelinecontrol ..
The most obvious example is small videos of terminal. That is to say, better quality than GIF and smaller size than MP4 and the like. SVG is also lossless.
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.
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.
A few weeks ago I tried to convert one of my asciinema recordings to a SVG with svg-term-cli [1], but the result had big problems with some browsers, so I took the more mainstream gif approach again.
Anybody tried termtosvg with different browsers yet?
[1]: https://github.com/marionebl/svg-term-cli
Anybody tried termtosvg with different browsers yet?
[1]: https://github.com/marionebl/svg-term-cli
SVG is one of those technologies that never really caught on, even though it would have made life much easier for everyone.
If the standard would have been clear and simple - then maybe yes.
But in my opinion it was and still is, a huge mess.
It somewhat works now, but ... it is a subset, that works. But it is not evil intention(nor the fault of Adobe or now Microsoft), that the love for SVG is not the greatest.
The example recording renders super smoothly in FF v61.0 and Chrome v67.0, but stutters in Safari running on an OS-X 'High Sierra' machine.
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!
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!
[deleted]
You could differentiate more from asciinema by building editing tools around the recording (like cutting or embedding the recording in stock frames like in https://shotsnapp.com)
Have a look here also: https://github.com/cirocosta/asciinema-edit
This is extremely cool, and will be useful.
One bug I noticed is that it seems to break virtualenv which is made with --system-site-packages its not finding the modules
One bug I noticed is that it seems to break virtualenv which is made with --system-site-packages its not finding the modules
Thanks! I will look into the virtualenv problem, but if you can spare the time could you please open an issue and include the exact steps to reproduce the error?
https://github.com/nbedos/termtosvg/issues/new
https://github.com/nbedos/termtosvg/issues/new
Amazing stuff. And in very readable Python!
Awesome! It sounds like browser support may currently be an issue, but I really like the idea :)
This is super awesome, but will there ever be an ability to pause/rewind/scrub?
Well, the animation is inherent to the SVG, so either browsers would need to support that, or some kind of JavaScript library is needed to extract that (probably giving Edge animation support while it's at it)
If only ffmpeg->mp4 instead of svg...
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.
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.
Pretty Cool
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...
[3] - https://intoli.com/blog/terminal-recorders/