I realize this is already closed, but a much smaller and straightforward input that causes this is just a single line with a backtick followed by a newline.
It seems that the quoting got completely mangled. Attempting to fix that here. On Mon, Jul 20, 2020 at 10:25 PM Ethan Merritt sfeam@users.sourceforge.net wrote: And as I said below it seems to work fine, so I'm not sure what it is that you would like to change. Sorry, I've kind of lost the thread here. Comes from trying to pick up in the middle of a train of throught from 4 years ago. I agree that 256 colors is enough for practical purposes. It is possible to get xterm built and configured to handle...
[formatting was mangled; fixed in next post]
It seems that the quoting got completely mangled. Attempting to fix that here. On Mon, Jul 20, 2020 at 10:25 PM Ethan Merritt sfeam@users.sourceforge.net wrote: And as I said below it seems to work fine, so I'm not sure what it is that you would like to change. Sorry, I've kind of lost the thread here. Comes from trying to pick up in the middle of a train of throught from 4 years ago. I agree that 256 colors is enough for practical purposes. It is possible to get xterm built and configured to handle...
On Mon, Jul 20, 2020 at 10:25 PM Ethan Merritt sfeam@users.sourceforge.net wrote: And as I said below it seems to work fine, so I'm not sure what it is that you would like to change. Sorry, I've kind of lost the thread here. Comes from trying to pick up in the middle of a train of throught from 4 years ago. I agree that 256 colors is enough for practical purposes. It is possible to get xterm built and configured to handle that but it doesn't seem that most distros ship it built that way. Honestly...
On Mon, Jul 20, 2020, 02:36 Ethan Merritt sfeam@users.sourceforge.net wrote: The trick of reusing colors won't work either because XTerm emulates the indexed color hardware -- changing color #2 from red to green will retroactively change prior uses of color #2 in the same image (or all images if the private colors setting is disabled). This matches what a real VT241 or VT340 would do. That may be so, but it's a foolish motivation. It is hard to imagine that anyone prefers accuracy in emulation of...
XTerm does support sixel transparency -- it has since the earliest versions of support for sixel graphics. Checking patch 304 from 2014 (the earliest version I have on hand) shows it: if (Pbgmode == 1) { context.background = COLOR_HOLE; ... So if it isn't working, there's either an XTerm bug, or something about the way the background mode is being set that is non-standard.
On point (2), the truncation is happening in XTerm. There is a maximum width and height in XTerm (to avoid huge memory allocations). These can be configured with: XTerm.VT100*maxGraphicSize: 1024x768 The default if not set is 1000x1000.
Hi Ethan, Sorry for the response four years later, but I just found this thread. XTerm does support any number (up to 32k) of colors, but you have to tell it how many to emulate. This is because the actual terminal hardware would "wrap around" when given color indicies above the maximum, and XTerm emulates this behavior. For 256 colors, you can start XTerm like this: xterm -ti vt340 -xrm 'XTerm*numColorRegisters: 256' The trick of reusing colors won't work either because XTerm emulates the indexed...
I just tried gnuplot 5.4.0 with the sixelgd driver with xterm 331 and it seems to work for me with both "test" and "plot sin(x)". The output seems to initialize each color before using it, so I'm not sure how this is different than normal sixel output. $ xterm -ti vt340 -xrm 'XTerm*numColorRegisters: 256' Output attached below. On the other hand, the other sixel driver (sixeltek) seems to miss setting the foreground color in some cases.
I'm aware of the X visual types. To me, TrueColor isn't about the number of bits in the representation of the color. The meaning is that each component of the color (RGB for color displays) is a separate part of the representation, so the pixel value can be computed from them in a predictable (and linear) manner. No need to consult a lookup table. XTerm can run on displays which are DirectColor, TrueColor, PseudoColor, and all of the grayscale equivalents. It has some internal color management and...
Like I said though, it doesn't support truecolor (which would effectively give a large predefined palette), but it supports arbitrary numbers of colors with that X resource setting (no compilation flags needed). Do you have a reference for the truecolor spec? I can look into adding it to XTerm. It wasn't in DEC's sixel implementation. -Ross On Tue, Jul 14, 2020 at 4:10 AM Ethan Merritt sfeam@users.sourceforge.net wrote: That's an xterm bug. I have never had any luck building xterm to support additional...
XTerm supports any number of colors for sixel graphics, if configured. For example, with 4096 colors: XTerm*numColorRegisters: 4096 The colors are always indexed, so there's no true color support. I'm somewhat doubtful about the utility for such a thing: any true color palette in 256 bits would have to be something painful like 3 bits red, 3 bits green, 2 bits blue. The default palette just has 16 colors matching those on the VT340 if in vt340 mode, but I recommend setting any colors used and not...