Sixel should be more universal: in particular I'm wishing that PuTTY and especially TeraTERM on Windows supported it. It would allow non-sw engineers (hence Windows) to see graphics from embedded systems that use serial ports.
Agreed!
So try sixel-tmux: https://github.com/csdvrx/sixel-tmux
> It would allow non-sw engineers (hence Windows)
I run Windows 11 as my main OS. sixel-tmux was written to help the users of non-sixel-aware terminals: every time a sixel sequence is intercepted, it's either:
- rewritten to ASCII art through derasterize if your terminal doesn't support sixels
- passed as-is if your terminal supports sixels
> to see graphics from embedded systems that use serial ports
If you use a serial port software such as minicom inside a terminal running sixel-tmux (ex: Windows terminal) it should work
- Contour https://github.com/contour-terminal/contour
- Wezterm https://wezfurlong.org/wezterm/
Both fast terminals with modern features and cross platform. Also checkout Notcurses:
Here is a video of the Notcurses demo running in a terminal:
AIUI, those are terminal emulators. Programs that let you attach to a text session on the same or another computer.
Terminal emulators are programs that emulate terminals. "Terminals" are a type of hardware. A screen and a keyboard that attach over RS232 serial links, running at maybe 9600 bits per second -- a really fast one might do, ooh, 19200bps -- to a computer. They can only display text.
(Graphical terminals existed but cost as much as a quite nice car at the time, and so remained rare.)
The clever thing in this WordPerfect version can display a "graphical" print preview on a text-only terminal.
This is trivially easy in software, but a pretty amazing feat of coding on dedicated hardware.
Define terrible. Wasteful, yes. But when we run chat programs inside electron apps, does it really matters?
> is the superior approach
My idea of superiority is linked to availability and support. Multiple competing formats are often a problem
> Kitty has an (incompatible) variant
Indeed, the multiple competing formats might each have some specific technical advantages, but networks effect makes your life harder.
From a dev perspective, it's a lot easier to base64 an image you already have, with a base64 that's already in your stdlibs, than to scour github for a passable sixel library to pre-rasterize that jpeg & reformat it as sixel. I say this as someone who's written a sixel conversion library.
> competing formats
It's not a very old format, yet already supported on 4-5 terminals last I checked.
&& find a decent FFI wrapper if my app isn't in C-land
&& read the docs
&& static link hassles so I don't have to sort-out dynamic-link hassles for every platform
|| round-up a collection of dynamic libsixel libs & figure out how to bundle them with my script if I'm not using a compile-to-machine-code language
vs
b64 := base64.Encode(myImg)
fmt.Printf("\x1b]1337;inline=1;size=%d:%s\n", len(b64), b64)
Any hope for standardization?
I do everything I can to help popularize sixels - it could be a default fallback format: sixel-tmux could "rewrite" on the fly sixel sequences into kitty iterm2 or whatever
https://sw.kovidgoyal.net/kitty/graphics-protocol/
If the goal is to hot-patch graphics into existing TUIs, Kovid is probably on the right track with this. It needs to be something richer than what sixel or iTerm2 provide--with pixel placement, play/pause, scaling, etc. Though for a do-over of piping a UI over a (relatively) low-bandwidth wire, I think something like Sun NeWS would have been a simpler & more feature-complete approach.
(disclaimer: I'm the wezterm guy)
† xterm and iTerm2 are the only widely-used terminal emulators nowadays that support sixels. Few Linux users use plain old xterm nowadays due to lack of desktop integration, and iTerm2 is not the OS default terminal (and it supports a better image format anyway). Also note that no popular Windows terminal emulators (conhost.exe, conemu, Microsoft Terminal) support sixels at all.
It's useful cause you don't have to take your fingers off the keyboard to get graphical information.
And yeah. I would be just as happy to use NAPLPS, but Sixel support is what we have.
In fact, mintty already supports it. Only xterm doesn't. Sixel really is just retrocomputing at this point.