No, not ASCII graphics, see the screenshot here:
http://en.wikipedia.org/wiki/W3m
How is that even possible?
I checked the source and it only prints character sequences. However, I am unable to find any reference to graphic drawing or image embedding escape sequences in xterm documentation or elsewhere.
w3m also seems to be the only software doing this.
There are vector graphics in Tektronix emulation, but this is done in VT mode.
Maybe I am looking for the wrong thing?
Any idea?
It's a cheat.
Note that this feature works only in "supported terminals" -- and by that it meant xterm, and rendering directly on the xterm window via xv.
Or not! Just checked the sources, the file that interests us is here. It's still a hack -- via X11 and GTK!
There is MLTerm, which supports Sixel format (not ReGis commands). It's available for both Linux and Windows.
Otherwise, according to man xterm on Ubuntu 12.04, xterm supports Tektronix graphics, which (the man page does tell) use ReGIS commands or Sixel bitmap format, depending on compilation options (I believe it's Sixel for the XTerm in the Ubuntu package repository).
One thing to know, is that ReGIS is an instruction set, while Sixel is a bitmap format.
As a side note, there exists a Python package to use Sixel aware terminal emulators: PySixel.
I'm interested in the topic too, and may update this answer in the future, with other relevant terminal emulators entries.
Higher-end models of Dec VT terminals support ReGis and Sixel graphics commands. If the xterm emulation is good enough, maybe that's how it was done?
Xterm supports the sixel and ReGIS protocols which allow rendering graphics directly in the terminal using escape sequences. However, Unicode interferes with 8 bit escape sequences, so you may need to convert them to 7bit sequences.
https://en.wikipedia.org/wiki/Sixel
https://en.wikipedia.org/wiki/ReGIS
Related
I'm using python3 with ncurses (curses) inside a docker container.
The problem is that mouse events are not accurately reporting x position in terminals that have more than 222 cells width. At first glance this is an obvious limitation because as far as i can see the position is sent in a single byte.
However Midnight Commander accurately handles large terminals. After some digging i could not find how to properly handle mouse with curses (this example does not work properly). Everything i tried with curses failed to work with large terminals. It seems that midnight commander is using gpm, but i could not find any way to use that in python.
q1: How can i handle mouse in large terminals in python3 directly, preferably with curses?
q2: Taking midnight commander as an example, will printing the escape sequences directly in stdout make the mouse work as expected ?
q3: Is there any other terminal gui library that handles mouse properly for python ?
It's not a direct limitation of the python interface to curses, but rather a feature of the underlying curses library, terminal description and the terminal:
For ncurses, that's the extended mouse feature which is standard in ncurses with ABI 6 (available since 2005, standard in ncurses 6 in 2015), noting that some distributions still provide ABI 5.
The terminal description has to use a feature which ncurses recognizes as implying the support for SGR 1006, and of course
The terminal itself has to support that feature (see note in ncurses database from January 2018 pointing out a few of the xterm imitators which do not).
When I'm writing a program for use on the command line, I notice that there's some limitations. For instance, I can't draw a 1-pixel-thick horizontal or vertical line like tmux does when it separates panes in a window. I can only move the cursor down, not up like VI seemingly does. I can't refresh information on the top of the page if the cursor is at the bottom.
So, when programs like tmux and vi do this, I have to wonder if they are:
drawing the screen from top to bottom every update (which I think is highly unlikely because otherwise I could scroll up in my terminal and see each redraw)
using some library that enables graphics in the terminal, like SDL, which I also think is unlikely.
using some standard syscall I don't know about
or finally
taking advantage of some feature of Linux/Unix of which I'm completely unaware.
So, how do these programs generate such a rich UI in such a seemingly limited shell? So long as the answer gives me just enough fodder to go on a Google rampage, I'll be happy.
I'm also assuming that these programs use some common method to do these things, but if that's wrong let me know.
A typical terminal emulator has a lot more features than are immediately apparent.
Essentially a program just needs to output short sequences of bytes that represent various commands such as move cursor (up|down|left|right), change color, scroll region, erase region, etc.
These commands typically begin with the escape character (the same character that is generated when you press the esc key while typing in a terminal) followed by various other characters, depending on which action is desired.
A good starting point for understanding how it works would be the Wikipedia Article about ANSI escape codes
You can do it by hand by putting the terminal into raw mode and writing directly to the terminal using low-level operations but the standard way to do it is to use the ncurses library.
How font rendering is done in linux, bsd, windows? how they differ?
I am not talking about browser web font rendering.say for example how input system works? I press mouse keys. they trigger evdev drivers of linux kernel, and the kernel manages the higher level ops.
low level font rendering mechanism. how freetype, pango, window manager, interact with each other. another big question? how unicode support is accomplished??
simply, when I type a character in a text editor, what are the paths does the character flow before coming into the screen. how the MS word or LibreOffice render different fonts together in single canvas??
On *nix text-rendering is done client-side nowadays which means apps use whatever lib they like best to transform unicode codepoints to pixels and feed the result to x. The actual libs used wary widely though people has been converging on fontconfig + freetype + freebidi + harfbuzz in the past years, usually accessed through pango-cairo
A summary was posted here a few years ago
http://behdad.org/text/
It's all a devilishly complex process, you have weeks of reading if you want to understand all the steps involved.
text-rendering linux fonts
I've come across both xterm-color and xterm-256color as options when trying to set up my terminal program to use color - i.e. you can set your TERM environment variable to either one.
I was wondering if anyone can describe the difference between the two?
I've searched for documentation on my Ubuntu server as well as my mac but haven't found any. I've only been able to find various binary files in /usr/share/terminfo.
xterm-256color describes Xterm with support for 256 colors enabled. xterm-color describes an older branch of Xterm that supports eight colors. xterm-color is not recommended, since it describes a variant of Xterm that’s less functional and that you’re not likely to be using. Usually you’ll want to use xterm, xterm-16color or xterm-256color.
In particular, xterm-256color is the default for Terminal starting with Mac OS X 10.7 Lion, with the next-best recommended values being xterm-16color or xterm (which only describes support for eight ANSI colors). Prior to 10.7, xterm-color was the default because Terminal didn’t support some critical features described by the recommended Xterm terminfo values, e.g., Background Color Erase (BCE), modern codes for switching main/alternate screens, 256 colors.
Sometimes people explicitly set TERM to xterm-color (as opposed to the recommended Xterm values) to disable functionality or work around incompatibilities between the available terminfo values on a particular computer and the terminal emulator being used.
Note that technically Terminal should have its own up-to-date terminfo values that describe exactly which features it supports, instead of using the values for Xterm, but:
There isn’t one that’s up to date currently. nsterm represents Terminal’s ancestor from NeXTSTEP. Someone apparently has updated nsterm recently (sometime in the past couple of years), but I don’t know whether that has made its way into the ncurses distribution, and it may not be completely up to date with Terminal in 10.7.
A number of programs and shell customization scripts explicitly check whether $TERM starts with (or is equal to) xterm. So some users would still need to know about using the recommended Xterm values with Terminal for compatibility with those.
If you’re not familiar with the terminfo system, take a look at the x-man-page://5/terminfo man page. Also, you can use the infocmp command to view the current terminfo settings or compare two different ones, e.g., infocmp xterm-color xterm-256color will show you all the differences between those two.
It appears that xterm-256color is Terminal.app on OS/X. The differences are not tiny - I infocmp'd xterm-color and xterm-256color on an Ubuntu box and normalized them a bit, and got quite a few differences. I might even say xterm-256color isn't really xterm anymore.
Normally when you use a specific terminal emulator, you need to "just know" which terminfo entry works best with it. They're a matching pair, though sometimes you can, EG, use a vt100 terminfo entry on a vt220 terminal.
On the plus side, almost everything is vt100-compatible today.
According to the ncurses FAQ, xterm-color is long obsolete:
Originally, xterm-color corresponded to the color_xterm from the mid-1990s. That was superseded by XFree86 xterm in 1996.
and the terminal database gives details. It was originally intended as a generic terminal description, but from the outset that never was successful because it did not match XFree86 xterm, in particular the color behavior (i.e., the back color erase feature). No one uses nxterm now.
The xterm-256color terminal description is built up from the (XFree86) xterm terminal description by modifying the color behavior (adding more colors, but not the background color erase feature. Use infocmp to see the difference:
$ infocmp xterm-color xterm-256color |wc -l
122
$ infocmp xterm xterm-256color |wc -l
14
$ infocmp xterm xterm-256color
comparing xterm to xterm-256color.
comparing booleans.
ccc: F:T.
comparing numbers.
colors: 8, 256.
pairs: 64, 32767.
comparing strings.
initc: NULL, '\E]4;%p1%d;rgb\:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\'.
oc: NULL, '\E]104\007'.
rs1: '\Ec', '\Ec\E]104\007'.
setab: '\E[4%p1%dm', '\E[%?%p1%{8}%<%t4%p1%d%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;%p1%d%;m'.
setaf: '\E[3%p1%dm', '\E[%?%p1%{8}%<%t3%p1%d%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;%p1%d%;m'.
setb: '\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
setf: '\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m', NULL.
Because xterm-color was obsolete, it was largely ignored until some (anonymous, of course) developer at Apple decided to reuse it for Terminal.app (in 10.5 Leopard), although it was a poor fit. The nsterm-16color description in ncurses was contributed by someone (apparently outside Apple), to match the 10.5 behavior. Although xterm-color uses 8 colors, nsterm-16color as one might guess uses 16. Perhaps that contributed to users' confusion. In any case, the choice of terminal description for Terminal.app had no effect on Terminal.app other than to set the TERM environment variable, which many applications use to decide how to use the terminal.
Interesting enough, although much of the MacOS userland is from the BSDs, its ncurses configuration is not. MacOS has tic/infocmp utilities, unlike the BSDs (though Apple has not updated it for more than ten years: ncurses 5.7 was released in 2008). In later releases of MacOS, Terminal.app's developers changed the menu to provide "xterm-256color" rather than "xterm-color". That did not improve the user experience because the terminal behavior using the corresponding terminal descriptions was still different. The ncurses FAQ mentions that:
Additionally, Mac OS X 10.7 is reported to use xterm-256color as a default $TERM value. This differs from xterm-color in several ways, in particular, the support for bce. It also differs from the recommended nsterm-256color (infocmp reports 111 differences).
I cannot understand why Apple's default terminal has only 16 colors, iterm2 etc support 256 colors, but X11's terminal supports true color (although its user interface is crappy).
My question is in two parts:
Why, in this day and age, are terminals not able to support higher colors (i.e., higher than 16 and 256)?
The last time I asked this, I only got rude comments like "Why don't you write one yourself"... I'm asking seriously, because I do not know about what goes into the internals of a terminal and why the constraint. Is it simply because there is no demand?
If I'm wrong and there are good terminals that support true color, could you recommend them?
My observations are based on a Mac, but other platform answers are welcome too, because they might be helpful to others.
KDE Konsole has true colour support, i.e. every character can have a different 24-bit colour.
Xterm and most other terminal emulators these days have a palette of 256 colours, whereby each of those colours can be chosen out of the full 24-bit range.
In the older days where terminals originate, they were hardware, and their colourfulness was limited by hardware constraints (i.e. memory shortage). Now we mostly use virtual terminals, which often emulate these older devices in software. So, one point is whether the software terminal actually emulates a device with its historical limitations.
Another point is that there are no conceptual limitations on colours, fonts or anything. This is because terminal is controlled by commands, which are simply special reserved sequences of characters. Commands are not standardized and differ from a terminal to a terminal. And that's exactly why there are virtually no such exotic functions implemented, as it would leave the users with two limiting options:
require all terminals to support the feature (which is not practically feasible)
limit the usage of the software to few particular terminals which do support the feature (which is highly unpleasant).
The third point I'd notice is that such features are not really needed by majority of people.
I know I'm very late for the party, but I found this :
a gist titled "True Color (16 million colors) support in various terminal applications and terminals", which gives information about which terminals support true colour and related discussions in the corresponding communities.
If you're looking for a quick link for Mac OS X, I just got iTerm2 nightly build and it works perfectly with true color:
https://iterm2.com/downloads/nightly/#/section/home
To answer the question about why this is useful: I do research on color, and being able to display colors right in the terminal is super useful for debugging/scripting/you name it.