bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong

[Dmitry Gutov <dgutov@yandex.ru>]

On 10/01/2023 14:05, martin rudalics wrote:
>  >> Here, for example, a maximized frame does not have the "right
>  >> height".
>  >
>  > Yeah ok, but none of the frames were maximized in those scenarios.
> 
> I mentioned it because that's how it usually can be reproduced easily
> with emacs -Q.
> 
>  > And the resizing by mouse "snapped" to the provided grid.
> 
> The resolution of that grid is specified by Emacs via these four lines
> 
>    size_hints.width_inc = frame_resize_pixelwise ? 1 : 
> FRAME_COLUMN_WIDTH (f);
>    size_hints.height_inc = frame_resize_pixelwise ? 1 : 
> FRAME_LINE_HEIGHT (f);
> 
>    size_hints.width_inc /= scale;
>    size_hints.height_inc /= scale;
> 
> If you scale by 2 and you have a font with impair sizes, you lose one
> pixel and the grid will be smaller than the character size.  If we round
> up in the last two lines, the grid will be larger than the character
> size by one pixel.

So... the window manager works with "unscaled" pixels it has to multiply 
by 2? That's why we try to send half the actual value?

> If we do not scale, the grid will have a resolution
> of two characters.  What would you prefer?

The current behavior seems more intuitive. Too bad we can't make it 
behave precisely, but oh well.

>  > I'm probably out of my depth here, but with 2x scaling, shouldn't the
>  > height increment just be 2x larger than the original one? If N is
>  > integer, 2xN must be an integer as well.
> 
> You're scaling down whatever you display probably because otherwise
> displayed objects would appear to small for your eyes.  That is, while
> Emacs lives in a 4000x2000 pixels world say, it's presented to your eyes
> in a 2000x1000 pixels form.

That makes sense.

>  > Pixel dimensions do change in this scenario. But not the reported 
> text height.
> 
> Right.  That's what rounding is all about
> 
>  >> xg_frame_resized old native pixels 1424x1368 new native pixels 
> 1408x1368
>  >> adjust_frame_size old native pixels 1424x1368 new native pixels 
> 1408x1368 old text pixels 1376x1368 new text pixels 1360x1368 old text 
> chars 80x36 new text chars 80x36
>  >> xg_frame_resized old native pixels 1408x1368 new native pixels 
> 1408x1332
>  >> adjust_frame_size old native pixels 1408x1368 new native pixels 
> 1408x1332 old text pixels 1360x1368 new text pixels 1360x1332 old text 
> chars 80x36 new text chars 80x36
>  >>
>  >> represent two mouse operations that resize the frame by 16 pixels, 
> first
>  >> the width, then the height.  Both are less that the character size so
>  >> while again the size of the frame should have changed, the numbers of
>  >> text characters didn't.
>  >
>  > The frame size didn't change either, however.
> 
> That's not what the numbers say.  The first time, the width changed from
> 1424 to 1408 pixels.  The second time, the height changed from 1368 to
> 1332 pixels.

I was talking about the Scenario 3: the frame dimensions (pixelwise) 
didn't change in it.

>  > All right. Where do we go from here?
> 
> I think you should use the attached in your daily work.  It's the same
> as before with the tracing code omitted.  If there are bigger problems,
> use the former patch and post me the contents of *foo*.

Thank you, but I'm not sure my work is particularly affected by it. 
Having the frame width settle on 80 chars is pretty nice, I suppose, but 
after that I usually maximize the frame anyway. Or make it take half the 
screen.

I believe getting the details right is important, but it's probably not 
worth too much as a personal patch.

It would be nice, though, to avoid the frame size contortions during 
startup. I think it goes through 4 different sizes, at least. This patch 
doesn't seem to change the number of transitions, however.

>  > The usability problems remaining are very minor, so if you're saying 
> Emacs is going right thing, we might as well go with the latest patch 
> and call it a day. Thank you.
> 
> Note that I won't install anything in the near future because I've given
> up synching with the repository.  The last time I did, I spent a couple
> of weeks to fix whatever got broken here.

Is there anything I can do to help? Your patch applies cleanly to the 
emacs-29 branch, at least.

If you send the patch together with a commit message, I can install it 
no problem (to the release branch or to master, whatever it deemed to be 
the best in this case).