GNU bug report logs - #78621
Pixelwise display specified spaces less precise than min-width

Previous Next

Full log

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

From: Ship Mints <shipmints <at> gmail.com>
Cc: 78621 <at> debbugs.gnu.org
Subject: Re: bug#78621: Pixelwise display specified spaces less precise than
 min-width
Date: Thu, 29 May 2025 13:23:04 -0400

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

tags 78621 notabug
close 78621

On Thu, May 29, 2025 at 12:50 PM Ship Mints <shipmints <at> gmail.com> wrote:

> tags 78621 notabug
> close 78621
>
> On Thu, May 29, 2025 at 12:41 PM Ship Mints <shipmints <at> gmail.com> wrote:
>
>> On Thu, May 29, 2025 at 12:38 PM Jim Porter <jporterbugs <at> gmail.com>
>> wrote:
>>
>>> On 5/28/2025 11:18 PM, Eli Zaretskii wrote:
>>> > I don't follow this argument.  string-pixel-width uses the display
>>> > code, so it should return the exact same value in pixels as what the
>>> > actual display produces when the same characters are shown on the
>>> > screen.  So whatever rounding happens (which I don't think it does,
>>> > since font glyphs have integer advance width), it happens the same in
>>> > both cases and should yield the same values.  Or what am I missing?
>>>
>>> The short version is that we should pass the current buffer to
>>> 'string-pixel-width' so that we can just use the display code to compute
>>> the string's width with all the remappings applied, rather than having
>>> the display code compute it without remappings and then trying to guess
>>> what the remapping would do to the width.
>>>
>>> Here's a longer version if it helps:
>>>
>>> The problem is that 'text-scale-increase' modifies the text size by a
>>> particular ratio; when zooming out by one step, that defaults to 1 /
>>> text-scale-mode-step, or 5/6.
>>>
>>> My fixed-pitch font is 8 pixels wide at the default size, so zooming out
>>> one step means the pixel width per char is 8 * 5/6 = 6.666. Since the
>>> advance width is an integer, we round up to 7 pixels. The original code
>>> works for fixed-pitch fonts since '(default-font-width)' returns 7 in
>>> this case, so the original expression:
>>>
>>>    (ceiling (* (string-pixel-width str)
>>>                (/ (float (default-font-width)) (frame-char-width))))
>>>
>>> is equivalent (only in this simple case) to:
>>>
>>>    (* (string-width str) (default-font-width))
>>>
>>> Hopefully that all makes sense.
>>>
>>> For variable-pitch fonts, this is more complex. Our zoom ratio is still
>>> 5/6, but we apply that ratio per-character, rounding each time. For the
>>> string "hi there", the pixel widths of each character are:
>>>
>>>    Scale   h  i  _  t  h  e  r  e   Total
>>>        0   8  4  4  5  8  8  5  8      50
>>>       -1   7  3  4  4  7  7  5  7      44
>>>
>>> Since the error introduced by rounding each character is a bit
>>> different, we get a different result between the width from the display
>>> engine compared to the approximation in the first expression above where
>>> we round only once at the very end.
>>>
>>
>> Yes, indeed.  No more estimation.  Just use the display engine directly.
>>
>

[Message part 2 (text/html, inline)]

Previous Next

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