bug#73730: 31.0.50; Support for color fonts on MS-Windows

[Cecilio Pardo <cpardo@imayhem.com>]

On 17/10/2024 8:21, Eli Zaretskii 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.

>> BTW, why does that variable show as undocumented with
>> describe-variables? What am I doing wrong?
> 
> You used DEFVAR_BOOL inside a function.  It should be on the top level
> (look at other places where we define such variables), then
> make-docfile will collect its definition and it will be written to
> etc/DOC.

Thanks.

>> - Instead of aborting on failure, just disable DirectWrite and let emacs
>> continue. This will take some work.
> 
> Instead of disabling DirectWrite, it might be better to fall back on
> previous code -- that way, the glyphs will be shown, but without
> colors.  The trick is to detect this early enough, because some fonts
> AFAIR cannot be displayed using non-dwrite code.

Ok.

>>>> +void *w32_font_get_dwrite_cache (struct font *font, float *font_size);
>>>> +void w32_font_set_dwrite_cache (struct font *font, void *cache, float font_size);
>>>
>>> Why aren't these functions defined in w32dwrite.c?
>>
>> They need to know about the uniscribe_font struct, which is defined there.
> 
> If that's the only reason, we could perhaps move the definition of
> uniscribe_font struct to w32font.h.

Will do that.