5 ms·
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 Wi
by jhallenworld 4y ago
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.
- georgia_peach 4y agomintty (cygwin) supports sixel & iTerm2 format inline png/gif/jpg https://iterm2.com/documentation-images.html https://iterm2.com/documentation-images.html
- jhallenworld 4y agoYeah, mintty is too difficult (the user would need to use picocom or something to connect to the serial port). iTerm2 is MAC only...
- georgia_peach 4y agoRLogin also supports sixel & iTerm2 formats, and has built-in serial support. The default is in Japanese, but they have language packs. https://kmiya-culti.github.io/RLogin/ https://kmiya-culti.github.io/RLogin/
- jhallenworld 4y agoRlogin looks promising. One other requirement I forgot is that it needs to support x/y/z-modem, and Rlogin does.
- junon 4y agoThere have been pushes for sixel for ages. I just don't think it's going to happen.
- georgia_peach 4y agoIt's okay for low-color/solid-run images, terrible for everything else. Nachman's image mime blobs (iTerm2 style) is the superior approach. mintty/mlterm/rlogin/wezterm already support it. Kitty has an (incompatible) variant--same idea, but delivered in chunks.
- csdvrx 4y ago> terrible for everything else 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.
- georgia_peach 4y ago> when when run chat programs inside electron apps, does it really matters? 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.
- retrocryptid 4y agoOr you could just use the libsixel package. Downloading libraries isn't unknown to developers (thinking about `apt-get install libncurses5-dev libsixel-dev` or the like.) Or sysadmins: `apt-get install libncurses5` or `apt-get install libsixel`.
- georgia_peach 4y ago&& find out how to get it on OSes that aren't debian-based && 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) If it's a feature request where I'm really only handling it to shut a few people up, which route am I going to take?
- csdvrx 4y ago> Sixel should be more universal Agreed! So try sixel-tmux: https://github.com/csdvrx/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
- retrocryptid 4y agoThere's been talk about adding sixel support to windows term for a couple years. I went back to BSD as a daily driver as work on this issue started picking up, but it looks like progress is being made: https://github.com/microsoft/terminal/issues/448 https://github.com/microsoft/terminal/issues/448
- k4r1 4y agoYou should try some modern terminals fx.: - Contour https://github.com/contour-terminal/contour https://github.com/contour-terminal/contour - Wezterm https://wezfurlong.org/wezterm/ https://wezfurlong.org/wezterm/ Both fast terminals with modern features and cross platform. Also checkout Notcurses: https://notcurses.com/ https://notcurses.com/ Here is a video of the Notcurses demo running in a terminal: https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
- lproven 4y agoUm. I am not sure if you appreciate the difference. 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.