contour: XTSMGRAPHICS "Read sixel graphics geometry" returns the different value from xterm.

Just to be clear, I agree with everyone that is saying you should match XTerm’s current behavior if you’re going to implement this sequence. But I’d still recommend applications avoid using it if possible.

The sequence feels weirdly xterm implementation dependent to me, it mostly reflects restrictions/settings on xterm, that other terminals might not have in the same way. In general I think terminal sequences should stay in the general and portable interface realms, and not surface implementation details at all costs, unless the sequence is marked for private usage only. XTSMGRAPHICS fails in that part imho.

I fully agree with this. That’s why I’ve just chosen not to implement it. And if I come across an application or library that depends on it, I’ve encouraged them to avoid that dependency, and support a reasonable fallback.

All good @kumattau! I’m all in for productive constructive conversations. We should just try to not run in cycles. (common problem sadly). Moving over to #680.

@christianparpart @j4james @jerch

I am sorry if I have offended you. I am just worry that the ticket can not be closed due to a discussion not directly related to this ticket.

For now, I created the following discussion about image size supported by the terminal: https://github.com/contour-terminal/contour/discussions/680 Let’s discuss it on there if more necessary.

I think the thing that some terminals limit image size is justified by the following reasons:

* terminal is not graphic library for general purpose

* outputting image is not much important for character terminal

* outputting image is expensive in terms of memory and processing time for character terminal

I think that xterm’s 1000px limit is too small and it is better to relax the limit, but I don’t think xterm should not have the limit.

The points you bring up here, account more towards no graphics support at all - which is perfectly fine for a TE, if its environment has strict resource limits (e.g. embedded stuff, kernel console). Then make it optional, e.g. by a compile switch. But if the switch is on, the TE should imho not restrict the graphics area to a smaller size than the allowed viewport. Machines as of today have enough resources to handle that fairly well, this artificial restriction is just an annoyance to create frictions on app dev and terminal user side for no good reasons anymore.

So either support full width, or disable graphics output at all. Thats my stance here. SIXEL itself allows up to 32k width - which is very easy to handle, if you do processing in sixel bands, not the whole thing at once (only 6 * 32k * 4 bytes in RGBA8888). And thats from a +30ys old semi-spec - and we still have some decades to go, until we hit that screen resolution area (some cinema projectors operate up to 64k already, but that’s not the first audience for terminal output rendering…).

Sorry, I’m not good at English.

I didn’t mean the XTSMGRAPHICS sequence was a bug. I meant the fact that XTerm can’t display certain image sizes is a bug.

I understood that you say XTSMGRAPHICS spec does not have problem but XTerm implementation has problem.

I think xterm implementation is off topic in this issue ticket, but I share my test result of displaying 5000 px width sixel on some terminals.

• XTerm: no image output
• alacritty-sixel: no image output with error message
• contour: 1920px image truncated
• mlterm: 5000px image output
• wezterm: 5000px image output

I think the thing that some terminals limit image size is justified by the following reasons:

• terminal is not graphic library for general purpose
• outputting image is not much important for character terminal
• outputting image is expensive in terms of memory and processing time for character terminal

I think that xterm’s 1000px limit is too small and it is better to relax the limit, but I don’t think xterm should not have the limit.

@hackerb9 to be hoonest? yes. in my case at least. because I looked at ctlseqs.txt and kind of trusted in what it said, given the completeness of that document and the reputation it had, at least the way I perceived it, I did not feel in need to verify every documentation line with its implementation in the xterm source code.

Regardless of that, improving documentation is always welcome. 😃

@kumattau writes:

When XTerm’s spec is respected, should the application like lsix do the following ?

1. get maximum image size by XTSMGRAPHIC Pa=4.
2. get current screen size by CSI 14/16/18, ioctl(TIOCGWINSZ) ws_row and ws_col, and the combination.
3. get the minimum of “maxiumum image size” and “current screen size”.

Good question. When that happens — which shouldn’t be long now that you’ve patched Alacritty and Contour is already fixed — the answer is pretty simple:

1. Get sixel graphics geometry by XTSMGRAPHICS(Pᵢ=2, Pₐ=1)

That’s it.

The purpose of XTSMGRAPHICS with Pₐ = 1 is to provide an explicit way to read the sixel height and width.

Indeed, CSI t is quite convoluted, and even was subject of several security concerns up to CVEs. The WindowOps sequences kinda lost their primary purpose to tune certain desktop integration aspects long ago (mind you, many things simply dont work anymore, as they have no counterpart on modern DEs).

So the shift of meaning is a logical consequence as in any evolutionary system (we are just that atm, as we lack a higher authority giving us red/green lines regarding the terminal interface). The problem we all have with this (at least I find it painful) - there is no strict right or wrong in such a scenario, just a more likely/unlikely, which really sucks in terms of strict correctness (computers still need that, unlikely to change until we have QPU-NPUs).

Regarding XTSMGRAPHICS I think you should not blame yourself too hard (@hackerb9), while I dont like it for leaking xterm implementation details, it certainly has several pros:

• separation of concerns, graphical stuff is a very different and delicate thing for text-driven terminals
• no convolution of other sequences / overloaded meanings (as with CSI t, which happens to work more by accident)
• extensible interface (easy to put other protocols or graphical options there, once needed)
• reporting caps (just a minor nag from my side - would have made SET options non-reporting by default, and hide reporting behind a sequence flag)

So I try to see things more opportunistic here - since XTSMGRAPHICS is already there, and ppl are likely to use it (its still xterm, we cannot ignore that until some other TE dethrones it) - lets use it to our advantage (thats the reason why I proposed in another thread to put a “reload default palette” option there).

Edit: Ah well, I think I will just do that and load the default palette on SET_DEFAULT (technically not quite correct, as it is only meant to change the register numbers, but my impl currently lacks a single sequence for reloading color values only).

I hate to be the one defending the CSI t sequences, because I really don’t like them either, but I’ve tested quite a lot of sixel terminals, and the simple truth is that you get better results using CSI t than you do using XTSMGRAPHICS (at least in my experience). In time that may change, but for now if you want your app to work on as many terminals as possible, I’d recommend making the most of that happy accident.

Yes, the main problem is that, as the title says, XTSMGRAPHICS “Read sixel graphics geometry” returns the different value from xterm. It makes application confused. The terminal can ignore unknown CSI (by not implementing CSI) and XTSMGRAPHICS defines error. So, if implementing XTSMGRAPHICS is difficult for the terminal, it should ignore or return error rather than return unexpected value.

I fully agree with this. That’s why I’ve just chosen not to implement it.

I agree with your way. I think that this is the right way to handle this if the terminal can not support this CSI for some reasons.

I’d still recommend applications avoid using it if possible.

I agree with you about implementing applications.

My 2cents on XTSMGRAPHICS:

The sequence feels weirdly xterm implementation dependent to me, it mostly reflects restrictions/settings on xterm, that other terminals might not have in the same way. In general I think terminal sequences should stay in the general and portable interface realms, and not surface implementation details at all costs, unless the sequence is marked for private usage only. XTSMGRAPHICS fails in that part imho.

Now with xterm things are more tricky - it is treated by many app devs and even terminal devs as the de-facto terminal interface standard these days, which makes it hard to ignore any sequence, xterm comes up with. Thats the reason, why I implemented XTSMGRAPHICS as well, but only parts of it, that could be answered reasonably:

• ReGIS - all nope, answered with GaStatus.ITEM_ERROR
• colors registers - READ | SET_DEFAULT | SET | READ_MAX supported (up to 4096)
• sixel geometry - READ | READ_MAX supported, all others will fail

For sixel geometry READ it returns the current viewport size in pixels, for READ_MAX I had to cheat and return the square* of the pixel limit of the sixel decoder (default 4096x4096). The last thing is somewhat unlucky, as it is not really limited by that (an image can happily run up to 32k pixel width, if height * width stays within pixelLimit).

The impl can be found here: https://github.com/jerch/xterm-addon-image/blob/75deeccd20172e753cf8b38846140462d05b9467/src/ImageAddon.ts#L259

Edit: [*] square root 😸

The Applications just only are forced to work around for supporting various terminals, but the terminals should not expect the application’s work-around effort and should keep the compatibility for the standard as possible.

I’m currently (today) busy at work, I can respond later tonight more detailed. But I absolutely agree with you here that apps should not suffice from implementation semantic differences.