Faking pixel dimensions in the `TIOCGWINSZ` struct causes scaling issues for Sixel apps

[j4james]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

Applications that produce Sixel images will often want to scale them to fit a certain area of the display, measured in terms of character cells, i.e. columns and rows. For example, you can use the timg utility to scale an image to fit within 20 columns with a command like this:

timg -f sixel -g 20x snake.png

In order for this to work, the application needs to know the pixel dimensions of a character cell so they can calculate the equivalent pixel size that the image should be scaled to. On Linux, this is often determined by looking at the winsize struct returned by TIOCGWINSZ, dividing the ws_xpixel field by the ws_col field, and the ws_ypixel field by the ws_row field.

However, that doesn't work when connecting with Win32-OpenSSH, because the those fields are hardcoded with fake dimensions (640x480). See here:

https://github.com/PowerShell/openssh-portable/blob/efa17c848b3e579d8a4a0e71edf6d233b5e30917/contrib/win32/win32compat/misc.c#L500-L501

It would be preferable if you simply filled the ws_xpixel and ws_ypixel fields with zero, because applications will typically then fallback to using an escape sequence to query the cell size.

Expected behavior

The rendered image from the example above should occupy exactly 20 columns.

Actual behavior

Depending on the size of the terminal window (in terms of rows and columns), the image can end up much bigger or smaller than expected.

Error details

Environment data

Name                           Value
----                           -----
PSVersion                      7.2.23
PSEdition                      Core
GitCommitId                    7.2.23
OS                             Microsoft Windows 10.0.19045
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

v9.8.2.0p2-Preview

Visuals

This is what the test case above looks like when run directly from within a WSL bash shell (note that it occupies exactly 20 columns):

This is what it looks like when connected to the same system with Win32-OpenSSH (it's incorrectly scaled to 8 columns):