SUMMARY If a program outputs a sixel graphic, and then uses ascii control sequences to move the cursor, the behaviour of cursor up is dependent on how many lines were already written before the program started. Cursor up will only work correctly if there were already lines present. To illustrate this, think of a neofetch like program, that first prints a graphic, then text right of it. If the program is started as first line in the whole konsole session, the output will look like this: |-----------| |-----------| |-----------| |-----------| Text 1 Text 2 Text 3 Text 4 If the program is started after a few lines were printed (some enters before running it is enough), the output will look like this: |-----------| |-----------| |-----------| Text 1 |-----------| Text 2 Text 3 Text 4 If the program is started with some lines before it (e.g. run multiple times). The output will be correct: |-----------| Text 1 |-----------| Text 2 |-----------| Text 3 |-----------| Text 4 Once this specific amount of lines is reached, the output will always be correct. The amount of lines is dependent on the height of the picture. I added an example minimal c program (+image) as an attachment, because code is better than words. Sorry for the dependency on imagemagick. Compile instruction is at the top of the c file. STEPS TO REPRODUCE 1. Compile and run the attached c program 2. See how the height of the image and the text lines misalign 3. Run it a few times without clearing 4. See how the alignment gets better and better until it is correct OBSERVED RESULT Alignment wrong in the first few runs EXPECTED RESULT Alignment always correct. This type of program output interpretation shouldn't give different results based on what was written to the console before. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.17.1-arch1-1 (64 bit) KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.2 Konsole Version: git
Created attachment 148092 [details] A c program that produces this bug
Created attachment 148093 [details] The image needed by the program
Note: The horizontal alignment is always correct. That this doesn't line up here is fault of the website
Thanks for reporting this. This bug is introduced in https://invent.kde.org/utilities/konsole/-/commit/0653603b11ac9530a219bf561e845e8884017216 . But it is actually the result of trying to support three graphics systems, with three cursor moving and scrolling sets of rules with as much shared code as possible.
Git commit 9ae57f4e1de920d1a30b8f64448fd6c186a36730 by Kurt Hindenburg, on behalf of Matan Ziv-Av. Committed on 19/04/2022 at 16:28. Pushed by hindenburg into branch 'release/22.04'. Fix cursor position after drawing Sixel graphics Moving all cursor and scroll handling to addPlacement. This requires the moveCursor parameter to have three possible values, since Sixel cursor movement is not the same as Kitty/iterm2. This also unnecessitates addPlacement return value. M +19 -21 src/Screen.cpp M +14 -14 src/Screen.h M +1 -6 src/Vt102Emulation.cpp https://invent.kde.org/utilities/konsole/commit/9ae57f4e1de920d1a30b8f64448fd6c186a36730
Git commit ad1421f8b87b219d38f08d7ba794fe2f4addd75d by Kurt Hindenburg, on behalf of Matan Ziv-Av. Committed on 19/04/2022 at 18:40. Pushed by hindenburg into branch 'master'. Fix cursor position after drawing Sixel graphics Moving all cursor and scroll handling to addPlacement. This requires the moveCursor parameter to have three possible values, since Sixel cursor movement is not the same as Kitty/iterm2. This also unnecessitates addPlacement return value. (cherry picked from commit 9ae57f4e1de920d1a30b8f64448fd6c186a36730) M +19 -21 src/Screen.cpp M +14 -14 src/Screen.h M +1 -6 src/Vt102Emulation.cpp https://invent.kde.org/utilities/konsole/commit/ad1421f8b87b219d38f08d7ba794fe2f4addd75d