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

[Cecilio Pardo]

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.