melatonin_audio_sparklines VS FFmpeg-SIXEL

You found the Achilles' heel of my project! I don't mind the fonts being different sizes or not monospaced, but the fact that there's a difference in height in the font rendering between ⎺ and ‾ on different platforms is a bummer. I have a flag in the C++ implementation so they can still be rendered "correctly" in IDEs like Xcode [1].

I felt doomed to Unicode in this case because of the number of places I wanted them to show up (CLion lldb integration, GitHub actions output, terminal). I would have loved to actually render graphics! I actually never thought about how they would render on a blog article, I wouldn't generally wouldn't use them for blogging...

1. https://github.com/sudara/melatonin_audio_sparklines/blob/ma...

Nice! I became obsessed with rendering sparkline representations of chunks of audio for the same reason: to inspect failures when writing tests / refactoring. https://github.com/sudara/melatonin_audio_sparklines

Also:

https://github.com/saitoha/libsixel

contains img2sixel, which lets you dump images to the terminal. It can also do animated GIFs.

Video:

https://github.com/saitoha/FFmpeg-SIXEL

GUI apps:

https://github.com/saitoha/SDL1.2-SIXEL

and more, linked from the libsixel repository.

> I don’t see why sixels couldn’t work.

Sixels will work: they are fast enough to allow youtube video playback !!!

https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/README.md

But the problem is NOT THE FORMAT, the problem is the lack of tooling. links and w3m are among the rare text browsers that can display images in the console.

It's just a matter of the browser sending the image to something in some format, but if that hasn't be thought about as a possibility (say, for text reflow issues) it's going to be far more complicated than just adding a new format, as you will have to work both on say the text reflow issues (ex: how do you select the size of the placeholder, when expressed in characters?), and the picture display.

Personally, I do not care much about sixels, kitty or iterm format - all I want is to see some kind of support.

Yes, it would be better if that support was for the option that has the greatest chance of succeeding, but even that is a second concern: in the worst case, we can write transcoders to whatever format people prefer!

But when there is no "input" to transcode, you have a much bigger problem!

> an off the shelf ASCII plotting library probably involves less custom tooling

With a terminal like msys2 or xterm, no custom tooling is required: just use the regular gnuplot after doing the export for the desired resolution, font, and font size.

gnuplot is far more standard than plotting library that often require special Unicode fonts on top of requiring you to use their specific format.