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


View this message in rfc822 format

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73730 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: bug#73730: 31.0.50; Support for color fonts on MS-Windows
Date: Sun, 20 Oct 2024 15:35:10 +0200
On 17/10/2024 12:38, Cecilio Pardo wrote:

>>> Still not done with this, but I am sending a new patch to fix the bug
>>> with w32-find-non-USB-fonts.  It calls text_extents with a font of size
>>> 0. Checking for that seems to solve the problem.
>>
>> Is that really TRT?  What does it mean font_size = 0 in this case?
> 
> No, I was wrong, sorry. DirectDwrite is failing to create a font from 
> certain GDI fonts. I need to then fall back to w32font. I'm on it.
> 

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.

Also, in the case of failures to get text size, draw, or encode char,
now we will disable directwrite for the particular font.

I'll send a patch as soon as I can.





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.