bug#60585: 30.0.50; global-text-scale-adjust shrinks window (was not before), was: Re: bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong

[Dmitry Gutov]

On 28/01/2023 17:36, martin rudalics wrote:
>  >> This shows how scaling strongly affects whatever GNOME displays here 
> and
>  >> what Emacs uses internally.  It might be illustrative to put two 
> equally
>  >> sized frames above each other - one from a GTK and one from a Lucid
>  >> build - and look at what size hints GNOME displays for each of them.
>  >
>  > Let me know if you really need that -- I'd have to compile Emacs in 
> two separate directories.
>
> One of these days please do.  Eventually we need someone to tell us how
> Lucid builds scale and whether the results look different from the GTK
> builds.  If nobody knows, we could try to guess from what Lucid and GTK
> frames look like on your display.

OK, I have done so now.

First of all, they start up with different dimensions: Lucid's is a bit 
shorter and narrower. GNOME says Lucid is 78x34 and GTK3 is 79x35.

Internally, both think they are 80x36.

The end of *foo* for GTK3 contains:

xg_frame_resized old native pixels 1488x1296 new native pixels 1488x1346
xg_frame_resized old native pixels 1488x1296 new native pixels 1488x1296
xg_wm_set_size_hint scale 2 char width 18 toolbar 0 vscroll 32 fringes 
16 borders 0 text width 720 base width 33 width inc 9
    char height 36 menubar 50 toolbar 0 hscroll 0 borders 0 text height 
648 base height 43 height inc 18
xg_wm_set_size_hint scale 2 char width 18 toolbar 0 vscroll 32 fringes 
16 borders 0 text width 720 base width 33 width inc 9
    char height 36 menubar 50 toolbar 82 hscroll 0 borders 0 text 
height 648 base height 84 height inc 18
xg_frame_set_char_size old native pixels 1488x1296 new native pixels 
1488x1296 outer pixels 744x714 outer rest 0x0
    base_size 33x84 size increments 9x18 WM hint 79x35

And for Lucid, it contains:

EmacsFrameResize old native pixels 1474x1332 new native pixels 1474x1354
EmacsFrameResize old native pixels 1474x1332 new native pixels 1474x1354
adjust_frame_size old native pixels 1474x1332 new native pixels 
1474x1354 old text pixels 1440x1296 new text pixels 1440x1296 old text 
chars 80x36 new text chars 80x36

(I avoid inserting the full contents for brevity, they are several times 
longer in both cases.)

Lucid's menu bar and tool bar look shorter in height, with less padding. 
The font size seems to be equal, however. And the tool bar icons are 
scaled on Lucid too.

I tried to resize them, but (as long as pixelwise resizing is disabled), 
they don't match exactly. But if I line them up very close, GNOME says 
Lucid (which is slightly larger) is 81x37 and GTK3 is 80x36. Here are 
respective logs:

GTK3:

xg_frame_resized old native pixels 1506x1296 new native pixels 1488x1296
adjust_frame_size old native pixels 1506x1296 new native pixels 
1488x1296 old text pixels 1458x1296 new text pixels 1440x1296 old text 
chars 81x36 new text chars 80x36
    base_size 33x84 size increments 9x18 WM hint 79x35
xg_frame_resized old native pixels 1488x1296 new native pixels 1488x1332
adjust_frame_size old native pixels 1488x1296 new native pixels 
1488x1332 old text pixels 1440x1296 new text pixels 1440x1332 old text 
chars 80x36 new text chars 80x37
    base_size 33x84 size increments 9x18 WM hint 79x36
xg_frame_resized old native pixels 1488x1332 new native pixels 1506x1332
adjust_frame_size old native pixels 1488x1332 new native pixels 
1506x1332 old text pixels 1440x1332 new text pixels 1458x1332 old text 
chars 80x37 new text chars 81x37
    base_size 33x84 size increments 9x18 WM hint 80x36

Lucid:

EmacsFrameResize old native pixels 1492x1354 new native pixels 1492x1390
adjust_frame_size old native pixels 1492x1354 new native pixels 
1492x1390 old text pixels 1458x1296 new text pixels 1458x1332 old text 
chars 81x36 new text chars 81x37
EmacsFrameResize old native pixels 1492x1390 new native pixels 1510x1390
adjust_frame_size old native pixels 1492x1390 new native pixels 
1510x1390 old text pixels 1458x1332 new text pixels 1476x1332 old text 
chars 81x37 new text chars 82x37
EmacsFrameResize old native pixels 1510x1390 new native pixels 1510x1426
adjust_frame_size old native pixels 1510x1390 new native pixels 
1510x1426 old text pixels 1476x1332 new text pixels 1476x1368 old text 
chars 82x37 new text chars 82x38

Which is to say Lucid's log is slightly inaccurate here because, again, 
GNOME reports that window to be 81x37.

>  >> For the rest, the transcript nowhere shows that the GNOME hints jump by
>  >> two or more after 'set-face-attribute'.  Can you spot such behavior?
>  >
>  > The jumps in the log look smooth, but one set-face-attribute
>  > evaluation creates several log entries. After I resize the frame to
>  > 118x35 and evaluate the s-f-a form, all of this is printed in the log:
>  >
>  > x_new_font old char size 17x37 new char size 17x37 text chars 112x35 
> old text pixels 1904x1296 new text pixels 1904x1295
>  > xg_wm_set_size_hint scale 2 char width 17 toolbar 0 vscroll 32 
> fringes 16 borders 0 text width 952 base width 32 width inc 8
>  >      char height 37 menubar 50 toolbar 82 hscroll 0 borders 0 text 
> height 647 base height 101 height inc 18
>  > xg_frame_set_char_size old native pixels 1952x1296 new native pixels 
> 1952x1295 outer pixels 976x713 outer rest 0x0
>  >      base_size 32x101 size increments 8x18 WM hint 118x34
>  > xg_frame_resized old native pixels 1952x1296 new native pixels 1952x1294
>  > adjust_frame_size old native pixels 1952x1296 new native pixels 
> 1952x1294 old text pixels 1904x1296 new text pixels 1904x1294 old text 
> chars 112x35 new text chars 112x34
>  >      base_size 32x101 size increments 8x18 WM hint 118x34
>  >
>  > x_new_font old char size 17x37 new char size 17x37 text chars 112x34 
> old text pixels 1904x1294 new text pixels 1904x1258
>  > xg_frame_set_char_size old native pixels 1952x1294 new native pixels 
> 1952x1258 outer pixels 976x695 outer rest 0x0
>  >      base_size 32x101 size increments 8x18 WM hint 118x33
>  > xg_frame_resized old native pixels 1952x1294 new native pixels 1952x1258
>  > adjust_frame_size old native pixels 1952x1294 new native pixels 
> 1952x1258 old text pixels 1904x1294 new text pixels 1904x1258 old text 
> chars 112x34 new text chars 112x34
>  >      base_size 32x101 size increments 8x18 WM hint 118x33
>  >
>  > ...and the frame is 118x33 at the end, naturally.
>
> This means that if you are sure that you have called it once only,
> 'set-face-attribute' manages to run set_new_font_hook twice.  Which
> would be a real pain.  Maybe someone has an idea.  Otherwise I have to
> invent a counter, increment it in 'set-face-attribute', print it in
> x_new_font, have you test it again ...

I'm pretty sure, yes. I performed that experiment and observed the log 
several times.

Would a counter really help? I guess you'll be able to confirm what I'm 
saying, but then what? Would that bring any new information?

Should we try to circle back to finding the difference between 
"InconsolataLGC" and "Inconsolata LGC"? The latter doesn't exhibit most 
of the problematic behaviors we have been discussing here.

And when s-f-a is evaluated at dimensions 118x35 with the latter family 
name, it first corrects the dimensions slightly to 118x34 (with like a 
few pixel difference in height, 2 or 3), and then no subsequent 
evaluations of s-f-a change frame dimensions, no matter how I resize it 
with a mouse first.

Visually, the resulting text seems identical between these two fonts. 
Maybe the former font name is somehow "autocorrected" into the latter? 
And that triggers some kind of callback internally that can additionally 
resize the frame?