GNU bug report logs -
#77171
31.0.50; Some lines in etc/HELLO display with large height on MS-Windows
Previous Next
Reported by: Eli Zaretskii <eliz <at> gnu.org>
Date: Sat, 22 Mar 2025 10:37:01 UTC
Severity: normal
Tags: patch
Found in version 31.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 23 Apr 2025 17:25:19 +0300
with message-id <86r01jymy8.fsf <at> gnu.org>
and subject line Re: bug#77171: 31.0.50; Some lines in etc/HELLO display with large height on MS-Windows
has caused the debbugs.gnu.org bug report #77171,
regarding 31.0.50; Some lines in etc/HELLO display with large height on MS-Windows
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
77171: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77171
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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 part 3 (message/rfc822, inline)]
> 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.
This bug report was last modified 83 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.