GNU bug report logs - #77171
31.0.50; Some lines in etc/HELLO display with large height on MS-Windows

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77171 in the body.
You can then email your comments to 77171 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50;
 Some lines in etc/HELLO display with large height on MS-Windows
Date: Sat, 22 Mar 2025 12:36:45 +0200

To reproduce:

  emacs -Q
  M-: (w32-find-non-USB-fonts) RET
  C-h h

and observe how some lines are displayed with large whitespace above
and/or below them.  For example, the lines of the following scripts:

  Batak
  Cham
  Coptic
  Hanifi Rohingya
  Hanunoo
  Makasar

Bisection shows that this started when DirectWrite text drawing was
added to Emacs in commit edf37e811caf back in Oct 2024.

Cecilio, could you please look into this?  I'm guessing that the code
we now use to return the metrics of character glyphs somehow returns
different results from what was used before, in this particular
aspect.


In GNU Emacs 31.0.50 (build 782, i686-pc-mingw32) of 2025-03-22 built on
 ELIZ-PC
Repository revision: cf7fdd374ac96ddd53a026bda2aa2b7211e5ee70
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 10.0.26100
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.26100.3476)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int
 --without-native-compilation --enable-checking=yes,glyphs 'CFLAGS=-O0
 -gdwarf-4 -g3''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY
PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  enriched-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  use-hard-newlines: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  view-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug lisp-mnt message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils thai-util thai-word mule-util lao-util vc-git diff-mode
track-changes easy-mmode files-x vc-dispatcher cl-loaddefs cl-lib
enriched facemenu view rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
touch-screen dos-w32 ls-lisp term/w32-nt disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process
tty-child-frames emacs)

Memory information:
((conses 16 199535 13089) (symbols 48 7733 0) (strings 16 21122 3511)
 (string-bytes 1 478810) (vectors 16 19762)
 (vector-slots 8 348637 11993) (floats 8 32 65) (intervals 40 389 136)
 (buffers 896 12))

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

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 77171 <at> debbugs.gnu.org
Subject: Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large
 height on MS-Windows
Date: Sat, 22 Mar 2025 15:12:39 +0100

On 22/03/2025 11:36, Eli Zaretskii wrote:
> Cecilio, could you please look into this?  I'm guessing that the code
> we now use to return the metrics of character glyphs somehow returns
> different results from what was used before, in this particular
> aspect.

Yes, I'm on it.

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

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 77171 <at> debbugs.gnu.org
Subject: Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large
 height on MS-Windows
Date: Thu, 27 Mar 2025 22:30:48 +0100

On 22/03/2025 15:12, Cecilio Pardo wrote:
> On 22/03/2025 11:36, Eli Zaretskii wrote:
>> Cecilio, could you please look into this?  I'm guessing that the code
>> we now use to return the metrics of character glyphs somehow returns
>> different results from what was used before, in this particular
>> aspect.

Just reporting status.

The problematic font here is "Sans serif collection", which gives very 
big ascent and descent values for glyphs. Not even Windows own tools, 
such as charmap or the font selection dialog, render this font correctly.

Emacs' code without directwrite directly inspects the glyph outlines to 
get metrics. I'm looking for a way to do the same with directwrite, or 
find another solution.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 77171 <at> debbugs.gnu.org
Subject: Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large
 height on MS-Windows
Date: Fri, 28 Mar 2025 10:21:24 +0300

> Date: Thu, 27 Mar 2025 22:30:48 +0100
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 22/03/2025 15:12, Cecilio Pardo wrote:
> > On 22/03/2025 11:36, Eli Zaretskii wrote:
> >> Cecilio, could you please look into this?  I'm guessing that the code
> >> we now use to return the metrics of character glyphs somehow returns
> >> different results from what was used before, in this particular
> >> aspect.
> 
> Just reporting status.
> 
> The problematic font here is "Sans serif collection", which gives very 
> big ascent and descent values for glyphs. Not even Windows own tools, 
> such as charmap or the font selection dialog, render this font correctly.
> 
> Emacs' code without directwrite directly inspects the glyph outlines to 
> get metrics. I'm looking for a way to do the same with directwrite, or 
> find another solution.

Thanks for working on this.  Sans serif collection is an important
font collection on Windows, since it supports a lot of scripts.  So it
would be good for Emacs to support it in a reasonably good fashion.

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

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 77171 <at> debbugs.gnu.org
Subject: Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large
 height on MS-Windows
Date: Tue, 1 Apr 2025 10:47:11 +0200

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

On 22/03/2025 11:36, Eli Zaretskii wrote:

> Cecilio, could you please look into this?  I'm guessing that the code
> we now use to return the metrics of character glyphs somehow returns
> different results from what was used before, in this particular
> aspect. 

The attached patch fixes this by using the GDI measurement for the 
vertical size of text.

Doing the same with DirectWrite would be too expensive, and would imply 
using the "layout" parts of DirectWrite, to get the same results most of 
the time.

Horizontal extents is different, we need to keep using DirectWrite for that.

[0001-w32-fix-problem-with-font-vertical-measurement-for-d.patch (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 77171 <at> debbugs.gnu.org
Subject: Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large
 height on MS-Windows
Date: Thu, 03 Apr 2025 08:32:43 +0300

> Date: Tue, 1 Apr 2025 10:47:11 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> On 22/03/2025 11:36, Eli Zaretskii wrote:
> 
> > Cecilio, could you please look into this?  I'm guessing that the code
> > we now use to return the metrics of character glyphs somehow returns
> > different results from what was used before, in this particular
> > aspect. 
> 
> The attached patch fixes this by using the GDI measurement for the 
> vertical size of text.
> 
> Doing the same with DirectWrite would be too expensive, and would imply 
> using the "layout" parts of DirectWrite, to get the same results most of 
> the time.

Hmm... are we sure the GDI measurement will work always for the fonts
for which we must use DirectWrite?  For example, the color fonts?

If GDI might fail for some fonts, perhaps leaving the metrics code in
w32_dwrite_text_extents, and then _overriding_ that by GDI values if
available, would be safer?

Thanks.

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

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77171 <at> debbugs.gnu.org
Subject: Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large
 height on MS-Windows
Date: Thu, 3 Apr 2025 11:12:51 +0200

On 03/04/2025 7:32, Eli Zaretskii wrote:

>> The attached patch fixes this by using the GDI measurement for the
>> vertical size of text.
>>
>> Doing the same with DirectWrite would be too expensive, and would imply
>> using the "layout" parts of DirectWrite, to get the same results most of
>> the time.
> 
> Hmm... are we sure the GDI measurement will work always for the fonts
> for which we must use DirectWrite?  For example, the color fonts?
> 
> If GDI might fail for some fonts, perhaps leaving the metrics code in
> w32_dwrite_text_extents, and then _overriding_ that by GDI values if
> available, would be safer?

We get the DirectWrite font from the underlying GDI font, so GDI will 
not fail, but it will indeed give incorrect metrics from color fonts, so 
this will need some more work.

Thanks.

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

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 77171 <at> debbugs.gnu.org
Subject: Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large
 height on MS-Windows
Date: Mon, 21 Apr 2025 20:53:35 +0200

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

Hello,

The attached patch examines the actual glyph's outline with DirectWrite 
to compute exact values for ascent and descent and should solve the 
problem for any font. Specifically, Sans Serif Collection works well 
now, and everything on HELLO.txt looks good on my system.

This adds some overhead, but I didn't find it noticeable.  In case 
someone does, we could cache measurements as the GDI backend does.

When computing the bounding box for bezier curves, I just used minmax 
values for start/end and control points, instead of actually evaluating 
the curve.  This reduces the overhead and loses some precision, but I 
didn't see any real difference.

[0001-w32-change-the-way-text-is-measured-when-using-Direc.patch (text/plain, attachment)]

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

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>, 77171 <at> debbugs.gnu.org
Subject: Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large
 height on MS-Windows
Date: Mon, 21 Apr 2025 20:57:57 +0200

On 21/04/2025 20:53, Cecilio Pardo wrote:
> Hello,
> 
> The attached patch examines the actual glyph's outline with DirectWrite 
> to compute exact values for ascent and descent and should solve the 
> problem for any font. Specifically, Sans Serif Collection works well 
> now, and everything on HELLO.txt looks good on my system.

Forgot to say that I tested this in 64 and 32bit build. Had to add some 
stuff from header files to work with the 32bit compiler.

Message #36 received at 77171-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 77171-done <at> debbugs.gnu.org
Subject: Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large
 height on MS-Windows
Date: Wed, 23 Apr 2025 17:25:19 +0300

> Date: Mon, 21 Apr 2025 20:53:35 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> The attached patch examines the actual glyph's outline with DirectWrite 
> to compute exact values for ascent and descent and should solve the 
> problem for any font. Specifically, Sans Serif Collection works well 
> now, and everything on HELLO.txt looks good on my system.
> 
> This adds some overhead, but I didn't find it noticeable.  In case 
> someone does, we could cache measurements as the GDI backend does.
> 
> When computing the bounding box for bezier curves, I just used minmax 
> values for start/end and control points, instead of actually evaluating 
> the curve.  This reduces the overhead and loses some precision, but I 
> didn't see any real difference.

Thanks, this solves the problems, so I've now installed this on
master, and I'm therefore closing the bug.

Previous Next

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