ponder acquiring cell size in pixels (plus maybe pixel aspect ratio)

[dankamongmen]

To do sixels correctly, I think we're going to need to know the cell size in pixels. We can guess until then, but i don't think there's any scale-free relation (i.e. it will depend on font size). If we do end up finding this information, it might also be useful for general blitting purposes, who knows?

[dankamongmen]

yeah, this definitely appears the case. making the font bigger leads to more sixels per cell, argh.

so with regards to #200...i'm thinking however many sixels we end up attributing to a cell, we'll want to write them into the EGCpool entry indexed by the cell as a unit. what value that EGCs can be as large as one wants in notcurses! =] when rasterizing, when we hit one, output "\ePq". when we hit a non-sixel while in the sixel state, output "\e\".

[dankamongmen]

Given that glyph widths are already kinda nonrigorous, being able to print short or wide really doesn't seem that much of a problem, though we then still have the issue of sixel vs cell vertical height...

[dankamongmen]

ws_xpixel and ws_ypixel from termios will certainly be helpful, when they're available.

[dankamongmen]

I've run through most of the terminals and recorded whether they implement those two fields for TIOCSGWINSIZE. There are also the XTWINOPS controls:

          Ps = 1 6  ⇒  Report xterm character cell size in pixels.
          Result is CSI  6 ;  height ;  width t

[dankamongmen]

This is going to be important for #1380, so doing this work in dankamongmen/pixel-geometry.

[dankamongmen]

 notcurses 2.2.2 by nick black et al
  54 rows (26px) 80 cols (13px) (67.50KiB) 16B cells 256 colors+RGB
  compiled with gcc-10.2.1 20210110, little-endian
  terminfo from ncurses 6.2.20201114
  avformat 58.45.100 avutil 56.51.100 swscale 5.7.100

xwininfo:

  Width: 1044
  Height: 1415

1044 / 80 == 13.05
1415 / 54 == 26.20

but some of those pixels are surely border and title, so this seems correct!

[dankamongmen]

I kinda doubt that any terminal failing to fill in TIOCSGWINSIZE implements this fairly esoteric DEC property. In any case, all terminals supporting pixel blitting do seem to be filling it in, so I'm calling this done. =]

Relying on TIOCGWINSZ can fail for the terminal multiplexer case. The "inner" (child) terminal might be run via 'script' (or in my case ptypipe) where xpixel/ypixel might be 0. The aspect ratio can also change after-the-fact; mintty has a Font change reporting feature for applications to use but I don't know if anyone else is supporting it.

So far all of the sixel-supporting terminals I have run across have XTWINOPS support.