sixel: How to fit sixels to cells; discussion
There are various possibilities for determining/setting the ratio of sixels to screen pixels/text cells:
- Pixel perfect. Sixels are mapped directly to screen pixels. Aspect distortion is avoided, but if the application wants to fit images to text cells, it has to calculate the sixels:cell ratio itself. The terminal must make its cell and pixel dimensions available to the application. This seems to be the most common approach in the modern era, exemplified by e.g. xterm, mlterm, mintty and VTE master.
- Hardcoded cell dimensions. For instance, the terminal and applications assume cells are always 10x20 sixels. There is no need to communicate the terminal's pixel dimensions, but since it will likely employ a differing cell size, one should expect aspect distortion (e.g. circles will become ellipses) and scaling artifacts; the final image resolution may be lower or higher than the screen resolution.
According to their GitHub tracker, MS Terminal may only be able to support 2) due to (as I understand it) an inability to access the terminal's pixel size from applications. 10x20 is also the cell size historically used by VT340, but other glass ttys may differ.
VTE's implementation can support any ratio, and even different ratios for each image if the cell size changes mid-session (images' cell extents are always preserved). It wouldn't be hard for us to support both 1) and 2), but we'd need a protocol extension to know when to apply each. In the case of 2) it would probably be a good idea to add a scaling method selector (two modes; smooth and nearest-neighbor), because there are applications that will prefer their graphics pixelated rather than blurry. Cf. the image in #253 (comment 964414).
The sixel protocol currently supports scaling and aspect modifiers, but these are relative to the sixel dimensions (e.g. "make pixels twice as high on display").
This comment also belongs here: #258 (comment 968268)
@chpe, @jerch, @dettus: Thoughts?
We may also want input from maintainers of other terminals who may not be on GNOME Gitlab, especially if we go the protocol extension route.