GNU bug report logs - #73730
31.0.50; Support for color fonts on MS-Windows

Previous Next

Package: emacs;

Reported by: Cecilio Pardo <cpardo <at> imayhem.com>

Date: Thu, 10 Oct 2024 11:17:01 UTC

Severity: wishlist

Found in version 31.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Cecilio Pardo <cpardo <at> imayhem.com>
Cc: 73730 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: Re: bug#73730: 31.0.50; Support for color fonts on MS-Windows
Date: Sun, 20 Oct 2024 19:17:10 +0300
> Date: Sun, 20 Oct 2024 15:35:10 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> Cc: 73730 <at> debbugs.gnu.org, kbrown <at> cornell.edu
> 
> The error is caused indeed by fonts with size == 0.
> 
>   - w32-find-non-USB-fonts calls open-font with size == nil.
>   - open-font gets the size from font-entity, that is also empty.
>   - It ends up calling CreateFontIndirect with a LOGFONT
>     with lfHeight == 0
>   - Then, w32-find-non-USB-fonts calls font-get-glyphs, which call
>     text_extents.
>   - text_extents on DirectWrite fails with a font of size 0, but
>     w32font_text_extents does return values that are not 0.
> 
> If the case of size <= 0, we are now falling back to
> w32font_text_extents.

Maybe it's better to use some default size in text_extents instead?
The pixel size of the default font is known (see FRAME_LINE_HEIGHT),
so maybe just use it if you get a font of size zero?  That could be a
more future-proof fix, since we could get such fonts in other
situations as well.

Regardless, we should keep the strategy of falling back to the old
code if DirectWrite fails.

Thanks.




This bug report was last modified 197 days ago.

Previous Next


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