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

[martin rudalics]

> OK, I have done so now.

Great.  If possible please keep the Lucid build around for a couple of
days - there are yet a lot of mysteries to solve.

> 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.

Can you try both with unpatched builds?  My unpatched Emacsen start here
(according to xfce/xfwm4, no scaling) as 80x36 the patched ones as 79x35.

> Internally, both think they are 80x36.

Same here.

> 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

Can you show me the text pixels values?  These are the ones we should
compare.  The native values differ because for Lucid the height includes
the toolbar which we draw ourselves into the rectangle the WM allots to
us.  GTK draws the toolbar into its own area which is outside the native
rectangle.

> 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

Here I would have liked to see the value for the scroll bar - vscroll.
I suppose these differ on Lucid and GTK.

> Lucid's menu bar and tool bar look shorter in height, with less padding. The 
font size seems to be equal, however.

When you put the two frames side by side, does the text area start lower
with GTK?  Here they start at exactly the same pixel position.  I attach
a screenshot so you can see.

> And the tool bar icons are scaled on Lucid too.

Is that the reason for the height difference?

> 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.

Lucid builds do not report the "WM hint" values (yet).  What stupefies
me most here is one thing: The Lucid build apparently also resizes in
18x36 increments although your font should ask for 17x37 pixels and we
nowhere do any scaling.  Please show me what the Lucid build outputs
after x_new_font.

> 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?

Maybe.  You could try putting a breakpoint at x_new_font and, whenever
it has triggered a second time in a row after you've done
'set-face-attribute', show me the backtrace for that second time.  Then
we could find out what strange force is triggering that.  If you manage
to do that, we don't need the counter.

> 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.

The first thing to try would be obvious: Does the latter trigger the
"two x_new_font entries in *foo* in a row behavior"?

> 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.

Please send me the *foo* transcript for that.

> 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?

Maybe fontset_from_font does such a thing.  We'd have to find out first
whether the values x_new_font finds for font->average_width and
font_ascent + font_descent differ for the two Inconsolatas.

martin

Lucid vs GTK3.png
Description: PNG image