no vertical cursor progression on GLFs (sixel)

[jerch]

Contour Terminal version

0.3.4.223

Installer source

GitHub: release page

Operating System

Ubuntu 18 LTS

Architecture

x86-64

Other Software

No response

Steps to reproduce

Plz see jerch/xterm-addon-image#37 for details on the issue. There is also this testscript done by @hackerb9 to check TE behavior.

Expected Behavior

GLFs from sixel should advance the text cursor to the bottom, if sixel scrolling is on.

Actual Behavior

Currently there is no text cursor progression from multiple GLFs.

Additional notes

(@Utkarsh-khambra This is the follow-up from #820.)

[christianparpart]

Output: Contour

Output: VT340 hardware

Looks like you want the ANSI text cursor to be placed on the next line at the beginning of the image's column. I'm sure I was NOT reading that in the spec, but I'm kinda blind... so I might have misread or skipped that by accident, I guess.

[j4james]

I tried to document the correct cursor positioning in the test case here:
https://github.com/hackerb9/vt340test/blob/main/j4james/cursor_position.sh#L3-L8

On a genuine VT340, after an image is output, the text cursor position is set to the same row as the top of the final sixel line (regardless of whether anything is output on that line). The column position remains unchanged, i.e. it should align with the left of the image.

Note that the "top" part of that statement is important when it comes to supporting aspect ratios other than 1:1, because a sixel line can end up spanning multiple text lines.

[jerch]

Looks like you want the ANSI text cursor to be placed on the next line at the beginning of the image's column. I'm sure I was NOT reading that in the spec

Well it is phrased somewhat fuzzy in DEC 070, here is the relevant paragraph (copied from pdf, so it may contain weird symbols or broken/scrambled words):

11.3 Exiting SIXEL MODE
The Horizontal Active position of the ANSI text is not affected by Sixelel mode and set
exactly to what is was when Sixel mode was entered.

NB: Thats the col direction indentation - col stays where sixel started, no matter what.

The vertical active position of the ANSI text is affected by Sixel mode. The ANSI text
vertical position is updated to reflect the vertical motion commands executed in the Sixel
printing. Note that on line oriented devices, this may leave the ANSI text active position
with a non integer line value, only getting back on line boundaries after an absolute
vertical position command. Also, the vertical positioning commands of Sixel mode use the
ACTUAL grid size, which may be different than the specified grid size. Therefore, software
doing pagination should issue an absolute position command before placing characters to
insure placement as expected.
Some devices may require re-alignment to a grid established for ANSI text after leaving
Sixel mode. In this case, an adjustment less than one character height may occur in a
downward direction. Conforming software will not assume any exact alignment of the
ANSI text vertical position following a Sixel image.

Thats the fuzzy part for vertical progression (tried to highlight the imho important parts). Note that the test of proper GLFs alignment as on a vt340 is not strictly enforced by DEC 070 (last sentence). The matter with DEC 070 is furthermore complicated by vt240 with its "I dont care for text progression at all", which also is not directly reflected by 070 rules.
Also the "top part" behavior discovered on the vt340 cannot really be read from these lines, but it somewhat makes sense, if one sees the sixel cursor to be placed at the first pixel row and "clipping" to text position wherever that first pixel row of the last sixel band ended up (just my interpretation, might be wrong).

[j4james]

Note that the test of proper GLFs alignment as on a vt340 is not strictly enforced by DEC 070 (last sentence).

Yeah, but I don't think the STD-070 documentation is a great reference for sixel, since it seems to be mostly targetting their printers rather than their terminals. There is no mention of the VT340, and some things described there simply weren't applicable to the terminals (e.g. grid sizes), or behaved quite differently (e.g. aspect ratios).

So if you're just going with what is documented in STD-070, you can basically do whatever you want. But you're not going to get much interoperability that way. Back when I was testing the various sixel implementations I think found eight different ways in which modern TEs were interpreting the cursor position! And that's not even counting the different modes that some people invented.

The matter with DEC 070 is furthermore complicated by vt240 with its "I dont care for text progression at all", which also is not directly reflected by 070 rules.

That is actually described in the "deviations" section at the end of the chapter.

I should also add that the final text cursor position is only one aspect of this issue. You also need to consider scrolling, i.e. when and how a sixel image will cause the viewport to scroll. The algorithm for that is quite different from the text cursor positioning, because the image can overflow the viewport before the text cursor would.

There is a separate test case that demonstrates that behavior here:
https://github.com/hackerb9/vt340test/blob/main/j4james/scrolling.sh

And for more info on how exactly it's supposed to work, it's probably best to look at the issue where we figured out all the details.
hackerb9/vt340test#11