bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60585: 30.0.50; global-text-scale-adjust shrinks window (was not bef


From: martin rudalics
Subject: 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
Date: Sat, 28 Jan 2023 16:36:27 +0100

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

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

martin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]