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

[Dmitry Gutov]

On 29/12/2022 11:05, martin rudalics wrote:
>  >>  > It certainly does work. One of the changes I saw right away is the
>  >>  > width of the frame right after startup with my config increased from
>  >>  > 84 to 90 columns.
>  >>
>  >> What are you asking for in your configuration?
>  >
>  > With your latest patch it's slightly different (the max width is 84).
>
> What is the "max width"?  The interesting return values are those of
> (frame-text-width), (frame-text-cols) and (frame-char-width) so we can
> relate the previous ones.

Max among the return values of (frame-text-cols). With the next-to-last 
patch it was 90.

>  > But what I'm also seeing, is that even without your patch the starting
>  > frame width is not deterministic either: the frame resizes a few times
>  > during loading, and may end up at width either 80 or 84. I think I
>  > mentioned similar behavior in some other bug report too.
>
> I'm quite sure that this is due to the scroll bar width and the fringes.
> You could try to make these a multiple of (frame-char-width).  That is
>
> (+ (frame-parameter nil 'scroll-bar-width)
>     (frame-parameter nil 'left-fringe)
>     (frame-parameter nil 'right-fringe))
>
> would have to equal (* N (frame-char-width)) for some N >= 0.

When frame-text-cols is 84, it's (+ 32 8 8) = 48, frame-char-width=17

When frame-text-cols is 80, all the above values are the same.

Oh, BTW, I have menu-bar, scroll-bar and tool-bar all disabled. The 
fringes should be on, though.

>  > So it seems like your latest patch doesn't change this behavior in 
> any significant way. Still either 80 or 84, at random.
> [...]
>  > I'm sure you are right, but before we continue the thorough 
> investigation, do you have any idea why
>  >
>  >   (set-face-attribute 'default nil :height 110 :family "InconsolataLGC")
>  >
>  > exhibits this kooky behavior, while
>  >
>  >   (set-face-attribute 'default nil :height 110 :family "Inconsolata 
> LGC")
>
> No idea.  You could try to step through normal_char_ascent_descent (best
> when called from get_font_ascent_descent) for each of these fonts and
> find out whether and how they differ.

I'm reasonably certain it's the same font.

Evaluating either form ends up with the same face definition, IIUC. At 
least the output of 'M-x describe-face RET default' is exactly the same 
after either (I checked with 'diff'):

           Family: Inconsolata LGC
          Foundry: PfEd
            Width: normal
           Height: 109
           Weight: regular
            Slant: normal
       Foreground: black
DistantForeground: unspecified
       Background: white
        Underline: nil
         Overline: nil
   Strike-through: nil
              Box: nil
          Inverse: nil
          Stipple: nil
             Font: #<font-object -PfEd-Inconsolata 
LGC-regular-normal-normal-*-29-*-*-*-m-0-iso10646-1>
          Fontset: -PfEd-Inconsolata 
LGC-regular-normal-normal-*-29-*-*-*-m-0-fontset-auto2
           Extend: nil
          Inherit: nil

If you think it will help, I can still try stepping through the 
functions you mentioned, but no earlier than tomorrow.

>  > does not? That might point to a weird kludge or workaround somewhere 
> which just needs moving somewhere else.
>  >
>  >> Try the attached which should work for any scaling and tell me what
>  >> happens now - in particular what the initial frame size is and whether
>  >> the frame grows or shrinks repeatedly.
>  >
>  > Now the width shrinks. Not from all starting widths, but from many of 
> them.
>  >
>  > Suppose the starting width is 80 (that's what frame-text-cols
>  > returns). Evaluating the set-face-attribute form changes the frame
>  > size once, but not the width in columns. Successive invocations don't
>  > change the frame size.
>
> So we at least have the improvement that the frame does not change size
> for repeated, apparently idempotent, invocations.  Right?

For some frame widths it does not. For others (for ranges of widths) -- 
it does.

>  > I increase the frame to width 112 with a mouse. Doesn't shrink. 
> 111-108 - nope.
>  >
>  > I resize it to 107 (according to frame-text-cols; the wm reports 
> 109x36), and evaluating the form shrinks the frame by 2 columns. That 
> repeats until frame-text-cols is 96.
>  >
>  > Widths 96-92 don't shrink.
>  >
>  > I resize to 91 - it continues shrinking (in steps of 2) until 80. 
> 80-76 don't shrink.
>  >
>  > 75 - shrinks until 64. And so on.
>
> Does shrinking the height with the mouse work as expected?  I'm quite
> confident that neither of these can work reliably - after all, the one
> pixel lost during rounding will continue to affect the intuitive
> behavior.  I'd say that it's already a success when attempting to shrink
> the frame with the mouse does not increase it initially.

Resizing with the mouse works without any apparent glitches. The corner 
of the frame follows the mouse almost exactly, within the margin of a 
char's height/width (when resizing is not pixelwise).

> Our handling of size hints is antediluvian.  In particular when
> 'frame-resize-pixelwise' is nil and on the other end a presumably
> Teutonic WM designer interprets size hints literally.  I can try to come
> up with a patch for these but don't expect too much.

Thanks.