Sixels are too small in Windows Terminal

[veltza]

I recently tried the patched version of chafa-test.zip on a nightly build of Windows Terminal Canary (V1.22.240816001-llm) and found that the -s option doesn't work properly. It prints a sixel that's way too small:

Even if you don't use the -s option, the sixels still stay small and don't fill the entire window like they should:

[veltza]

I just discovered that Windows Terminal uses a virtual cell concept (see PRs 17504 and 17421), where the cell size is always 10x20 from the sixel perspective. I'm pretty sure this is causing the size issues.

[hpjansson]

Yes, I think that's it. And we don't have a way to probe the window's pixel dimensions on Windows (we use ioctl() for this on other platforms), so we're falling back to a bad default assumption of 8x8-pixel cells.

@j4james - what's the best client approach here, in your opinion? Is there a way to probe the dimensions passively? Also, is there something in the environment we can use to differentiate a sixel-capable Windows Terminal from an older version?

[j4james]

@hpjansson As veltza mentioned, the Windows Terminal cell size is always 10x20, and this would also be the case on a real VT340 as well all the commercial terminal emulators that I'm aware of. So that would be my recommendation for the fallback size if you have no other way of querying the terminal.

But if you also want to support terminals that use a non-standard size, and which don't (or can't) set TIOCGSIZE, then I would recommend querying some combination of CSI 16 t (the cell size in pixels), or CSI 14 t and CSI 18 t the (window size in pixels and characters, from which you can estimate the cell size). CSI 16 t is more reliable, but less commonly supported (at least that was a case a few years back when I lasted tested).

It's also worth mentioning that TIOCGSIZE won't always report zero for the pixel fields when they aren't known. I've often seen them reported as a random value > 32000. I haven't looked at your code, so maybe you're already accounting for that. Just wanted to let you know in case you weren't.

[j4james]

Also, is there something in the environment we can use to differentiate a sixel-capable Windows Terminal from an older version?

The sixel-capable version will report the sixel feature (parameter value 4) in the primary device attributes report, the same as most other sixel-capable terminals.

[hpjansson]

@hpjansson As veltza mentioned, the Windows Terminal cell size is always 10x20, and this would also be the case on a real VT340 as well all the commercial terminal emulators that I'm aware of. So that would be my recommendation for the fallback size if you have no other way of querying the terminal.

Yes. I think I'll change the default in the CLI tool (this affects non-sixel modes like symbols too -- but the platforms where square cells can be expected are in a very definite minority). The library will have to keep 8x8 as the default, since it's API.

But if you also want to support terminals that use a non-standard size, and which don't (or can't) set TIOCGSIZE, then I would recommend querying some combination of CSI 16 t (the cell size in pixels), or CSI 14 t and CSI 18 t the (window size in pixels and characters, from which you can estimate the cell size). CSI 16 t is more reliable, but less commonly supported (at least that was a case a few years back when I lasted tested).

Thanks, this is very useful information for when I implement active probing.

It's also worth mentioning that TIOCGSIZE won't always report zero for the pixel fields when they aren't known. I've often seen them reported as a random value > 32000. I haven't looked at your code, so maybe you're already accounting for that. Just wanted to let you know in case you weren't.

I am :-) But I don't think this is something people run into frequently with Chafa, fortunately.

The sixel-capable version will report the sixel feature (parameter value 4) in the primary device attributes report, the same as most other sixel-capable terminals.

I was hoping for something I can grab instantly/passively, like a version string in an environment variable, or a system call.

Tangentially: What do TIOCGWINSZ and tcgetwinsize() report on a Linux host when you're in an ssh session originating from Windows Terminal?

[j4james]

Tangentially: What do TIOCGWINSZ and tcgetwinsize() report on a Linux host when you're in an ssh session originating from Windows Terminal?

Windows Terminal doesn't have a built in ssh client, and a stand alone ssh client will likely just report 0, because it wouldn't have any more knowledge of the pixel size than any other app.

I know there are some terminals on Windows that do have a built in ssh client, and I've seen at least one that reported meaningful pixel values in TIOCGWINSZ over ssh, but not all of them do.

[veltza]

But if you also want to support terminals that use a non-standard size, and which don't (or can't) set TIOCGSIZE, then I would recommend querying some combination of CSI 16 t (the cell size in pixels), or CSI 14 t and CSI 18 t the (window size in pixels and characters, from which you can estimate the cell size). CSI 16 t is more reliable, but less commonly supported (at least that was a case a few years back when I lasted tested).

I don't want to go off topic too much, but do you plan to support XTSMGRAPHICS sequences as well, since they can also be used to query sixel properties?

For example, lsix uses them to query the number of sixel color registers and sixel geometry (or window size).

[j4james]

do you plan to support XTSMGRAPHICS sequences

No.

[j4james]

I am :-) But I don't think this is something people run into frequently with Chafa, fortunately.

@hpjansson I just looked at your code now, and I don't think that would catch the cases that I've seen (assuming I'm reading it right). For me the size has always been greater than 32000 but less than 32767. I've seen this on every terminal I've tested when connected to a telnet server on Ubuntu.

[hpjansson]

Windows Terminal doesn't have a built in ssh client, and a stand alone ssh client will likely just report 0, because it wouldn't have any more knowledge of the pixel size than any other app.

Ok. I was asking because Linux openssh picks this information up on the client side and relays it to the host, so the ioctl reports the same dimensions in the remote session. Maybe it could do this in Windows Terminal too, if it could query the terminal device directly a la ioctl (I suspect the openssh maintainers would be reluctant to emit and parse control sequences for this purpose).

I know there are some terminals on Windows that do have a built in ssh client, and I've seen at least one that reported meaningful pixel values in TIOCGWINSZ over ssh, but not all of them do.

I see. That reminds me I'll have to check how we fare in PuTTY sometime.

@hpjansson I just looked at your code now, and I don't think that would catch the cases that I've seen (assuming I'm reading it right). For me the size has always been greater than 32000 but less than 32767. I've seen this on every terminal I've tested when connected to a telnet server on Ubuntu.

Interesting. I'll lower PIXEL_EXTENT_MAX, then. The case where the user's terminal is maximized on a desktop more than four 8k monitors wide is likely rarer anyway :-)

[j4james]

I was asking because Linux openssh picks this information up on the client side and relays it to the host, so the ioctl reports the same dimensions in the remote session. Maybe it could do this in Windows Terminal too,

But openssh would pick up this information the same way you would when running locally. On Linux that's assumedly achieved with ioctl, but Windows doesn't have that. On Windows they assumedly get the char size with one of the win32 console APIs (maybe GetConsoleScreenBufferInfo), but there isn't an equivalent API for the pixel size. If there was, you could've used that too.

[hpjansson]

Indeed. I guess I'm saying it's high on my wishlist. Thanks for the tips (and congrats on getting sixel support merged).

[hpjansson]

Test archive including this fix and the one for #210: chafa-test-gh211.zip

Hope this solves the issue. Thanks for submitting it, @veltza!