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 <rudalics@gmx.at>]

 > It becomes ever more difficult to remember the context. E.g. which
 > operations I should do with each build before looking up this or that
 > value.

Same here.  In fact, I think we have investigated most of what can be
done here.  So unless someone has a better idea I'll try to come up with
a patch that comprises most of what I sent you so far and some further
fixes - size hints on xfwm have become off by one here and I don't yet
know what causes it.

So as a general guideline I plan to cook up something like:

- Make the base size hints handle any irregularities caused by increment
   hints not being integral multiples of our line/column sizes.

- Implement correct minimum size hints and make them independent from
   the base sizes.

- Do away with our attempts to override GTK which means to get rid of
   emacsgtkfixed.c/.h.

All this will take some time and testing.

 > These logs are of 'emacs -Q' followed by evaluating
 >
 >    (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")

FWIW, it would be nice to get the 80x36 and 84x36 below

adjust_frame_size old native pixels 1728x1620 new native pixels 1408x1332 old text pixels 1680x1620 new text pixels 1360x1332 old text chars 80x36 new text chars 80x36
     base_size 32x84 size increments 8x18 WM hint 84x36

in synch but I have no clear idea yet how to do that.  IIRC I added the last
line to that comment in gtkutil.c

   /* Use one row/col here so base_height/width does not become zero.
      Gtk+ and/or Unity on Ubuntu 12.04 can't handle it.
      Obviously this makes the row/col value displayed off by 1.  */

some time ago but am not sure whether it explains the problem in its
entirety or something else has to be done too.

 >> I see.  BTW, your Lucid scroll bar doesn't seem to have a ruler (or
 >> thumb, or whatever you call it) nor the arrows at top and bottom.
 >
 > Indeed. Not sure if it's supposed to.
 >
 > The scrollbar itself is not very functional: it shows the scroll
 > progress of the buffer, but to scroll back using the mouse clicks
 > seems impossible (all scrolling proceeds in one direction).

Are these toolkit scroll bars?  What are your build options for Lucid?
Whatever it is, this behavior deserves a separate bug report.

 > First call for "InconsolataLGC":
 >
 > x_new_font old char size 18x36 new char size 21x45 text chars 80x36 old text pixels 1440x1296 new text pixels 1680x1620
 > xg_wm_set_size_hint scale 2 char width 21 toolbar 0 vscroll 32 fringes 16 borders 0 text width 840 base width 34 width inc 10
 >      char height 45 menubar 50 toolbar 82 hscroll 0 borders 0 text height 810 base height 106 height inc 22
 > xg_frame_set_char_size old native pixels 1488x1296 new native pixels 1728x1620 outer pixels 864x876 outer rest 0x0
 >      base_size 34x106 size increments 10x22 WM hint 83x35
 > xg_frame_resized old native pixels 1488x1296 new native pixels 1728x1620
 > adjust_frame_size old native pixels 1488x1296 new native pixels 1728x1620 old text pixels 1440x1296 new text pixels 1680x1620 old text chars 80x36 new text chars 80x36
 >      base_size 34x106 size increments 10x22 WM hint 83x35
 >
 > x_new_font old char size 21x45 new char size 17x37 text chars 80x36 old text pixels 1680x1620 new text pixels 1360x1332
 > xg_wm_set_size_hint scale 2 char width 17 toolbar 0 vscroll 32 fringes 16 borders 0 text width 680 base width 32 width inc 8
 >      char height 37 menubar 50 toolbar 82 hscroll 0 borders 0 text height 666 base height 84 height inc 18
 > xg_frame_set_char_size old native pixels 1728x1620 new native pixels 1408x1332 outer pixels 704x732 outer rest 0x0
 >      base_size 32x84 size increments 8x18 WM hint 84x36
 > xg_frame_resized old native pixels 1728x1620 new native pixels 1408x1332
 > adjust_frame_size old native pixels 1728x1620 new native pixels 1408x1332 old text pixels 1680x1620 new text pixels 1360x1332 old text chars 80x36 new text chars 80x36
 >      base_size 32x84 size increments 8x18 WM hint 84x36
 >
 > The second and all subsequent ones look like this:
 >
 > x_new_font old char size 17x37 new char size 17x37 text chars 80x36 old text pixels 1360x1332 new text pixels 1360x1332
 >
 > x_new_font old char size 17x37 new char size 17x37 text chars 80x36 old text pixels 1360x1332 new text pixels 1360x1332
 >
 > (This is while keeping the frame in its default size; no resizing with the mouse.)

All these show no differences between the two Inconsolatas.  So the
reason why one keeps your frame shrinking and the other doesn't still
remains a mystery.

 > It looks like both trigger two x_new_fonts calls the first time. And maybe resize the frame twice, which could be hard to register with the human eye. But then one continues to do that (under certain conditions), and another stops.
 >
 >> It should be something like not finding a suitable
 >> font with "InconsolataLGC" or at least one that does not ask for
 >> changing the height
 >
 > That's what I was thinking: "InconsolataLGC" falls back to
 > "Inconsolata LGC", but that's not registered in some internal data
 > structure, so whenever a new set-face-attribute call arrives, the
 > comparison fails, and the search is repeated.

You could try with two separate 'set-face-attribute' calls.  That is: Do
the below for both Inconsolata fonts

 > InconsolataLGC:
 >
 > first hit:
 >
 > (gdb) p font->average_width
 > $1 = 21
 > (gdb) p font_ascent
 > $2 = 37
 > (gdb) p font_descent
 > $3 = 8
 >
 > second hit:
 >
 > (gdb) p font->average_width
 > $4 = 17
 > (gdb) p font_ascent
 > $5 = 31
 > (gdb) p font_descent
 > $6 = 6
 >
 > Inconsolata LGC:
 >
 > Exactly the same.

first with only :family set leaving :height alone and then with only
:height set leaving :family alone.  Then do the reverse - that is first
with only :height set leaving :family alone and then with only :family
set leaving :height alone.

martin