On 2026-10-01 04:21:22 -0400, Thomas Dickey wrote:
> On Thu, Oct 01, 2026 at 02:43:01AM +0200, Vincent Lefevre wrote:
> > This could be a miscalculation of a position somewhere.
>
> something like that. In your example, it's unclear what the actual window
> size is. That matters. For instance, it could be interchanged x/y ordinates
I had tried with different window sizes (not on purpose, though).
I've tried again with 16x48 and 80x16 xterms, and the same issue
occurs.
If there are interchanged x/y, this could be related to the character cell.
The same issue occurs with "xterm -sh 2".
Column $COLUMNS-1 is affected with
xterm -fa "xft:DejaVu Sans Mono:size=10:aspect=0.5"
xterm -fa "xft:DejaVu Sans Mono:size=10:aspect=0.8"
xterm -fa "xft:DejaVu Sans Mono:size=10:aspect=1"
Column $COLUMNS is affected with
xterm -fa "xft:DejaVu Sans Mono:size=10:aspect=1.2"
xterm -fa "xft:DejaVu Sans Mono:size=10:aspect=1.5"
xterm -fa "xft:DejaVu Sans Mono:size=10:aspect=2"
xterm -fa "xft:DejaVu Sans Mono:size=10:aspect=2.5"
("aspect" is the horizontal scale factor of the glyphs).
But this doesn't seem to be interchanged x/y.
[...]
> The new option "brokenCopyArea" which I added in 411 uses the data
> in the FIFO directly.
FYI, the same issue occurs whether I use
xterm -xrm "*brokenCopyArea: false"
or
xterm -xrm "*brokenCopyArea: true"
> I've seen none, but that TrueType font is also a factor. The experimental
> VS15/VS16 feature (inactive by default) seems to be the only aspect which
> might affect TrueType display. I don't see that in your screenshot, so
> I'm not expecting it to be relevant.
I recall that the issue also occurs with
xterm -report-fonts -fn 6x13 -fa ''
Isn't 6x13 a bitmap font?
FYI, with -report-fonts, I can see about fNorm:
fNorm: 6x13
all chars: no
default char: 0
direction: 0
ascent: 11
descent: 2
first char: 0
last char: 255
maximum-chars: 256
missing-chars: 33
present-chars: 223
min_byte1: 0
max_byte1: 0
properties: 23
min_bounds:
lbearing: 0
rbearing: 0
width: 6
ascent: -1
descent: -10
max_bounds:
lbearing: 2
rbearing: 6
width: 6
ascent: 11
descent: 2
Per-character: 222/255
I've also tried with FVWM2's and FVWM3's default config.
* With the xterm started from FVWM's menu, I cannot reproduce the
issue, but the xterm has a thick scrollbar on the right, so the
scrollbar appears where the last columns would have been, and
this would explain why the issue does not occur.
* With the xterm started from this xterm, it is $COLUMNS-2 that is
affected. The font is
-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
but what is also probably important is that the xterm has a
thick scrollbar on the left.
> With that in mind, you might find some easy way to reproduce the
> problem and provide a detailed explanation of how others can repeat it.
Have you tried with FVWM?
I think that this is related to the width of the font and the scrollbar
related properties: presence or position (left or right) and its width.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
