GNU bug report logs - #52493
29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong

Previous Next

Full log

Message #347 received at 52493 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Eli Zaretskii <eliz <at> gnu.org>
Cc: rpluim <at> gmail.com, 52493 <at> debbugs.gnu.org
Subject: Re: bug#52493: 29.0.50; Setting Inconsolata up in init.el makes
 default face rendered wrong
Date: Tue, 10 Jan 2023 13:05:54 +0100

[Message part 1 (text/plain, inline)]

>> 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.  If we do not scale, the grid will have a resolution
of two characters.  What would you prefer?

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

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

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

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

martin

[x_scale_font_only.diff (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.