>> For reference let's try to stick to the last x_scale_font.diff patch I
 >> sent you.  What was the "impair" size there?
 >
 > According to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52493#332, some impair sizes were 80x36 minus 1 in any dimension using the mouse.

You mean the ones where you resized a frame with the mouse by 16 or 36
pixels with a character size of 17x37?

 > So, with x_rest.diff, the attached transcript is of:
 >
 > 1. Resizing the frame to 80x36 (according to GNOME).
 > 2. Evaluating the set-face-attribute form twice.
 > 3. Resizing the frame to 80x20 (per GNOME), which is 76x20 according to our internal measurements.

Do you mean that 80x36 according to GNOME is 80x36 according to our
internal measurements while 80x20 to GNOME is 76x20 according to our
internal measurements?

 > 4. Evaluating the set-face-attribute form twice again.
 > 5. Resizing to 80x32.
 > 6. Evaluating s-f-a twice again.
 >
 > In this scenario, step 4 doesn't change the frame size. But if I skip
 > step 1, step 4 (evaluating s-f-a after resizing to 80x20) does change
 > the frame size. And step 6 (s-f-a at size 80x32) does not.
 >
 > So it seems the history of size changes now (?) affects which sizes are "impair".

Didn't we always have that?  The present code simply tries to reduce
some noise when setting the font would otherwise cause a resize of a few
pixels.

 > Also, only height is important now: if height 20 is "impair", then I
 > can resize the frame to any width with this height, and evaling s-f-a
 > will shrink the frame in both dimensions by one char. Same for height
 > 34 in the alternative scenario.

Please try the next patch so at least the initial size becomes
reasonable again.

martin