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

Previous Next

Full log

Message #46 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: Thu, 17 Oct 2024 09:21:08 +0300

> Date: Wed, 16 Oct 2024 23:35:34 +0200
> Cc: 73730 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> 
> 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?

> 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.

> - 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.

>  >> +  glyph_run.bidiLevel = 0;
>  >                 ^^^^^^^^^^^^^
>  > Is this because otherwise DirectWrite will possibly reorder the
>  > glyphs or something?  Did you test this with R2L text, e.g. by
>  > displaying TUTORIAL.he?  I did try, and it looks OK, but are there any
>  > color fonts that cover the Hebrew block, so I could be sure everything
>  > works in that case?
>  >
>  > More generally, what color fonts can be used with this build on
>  > Windows for characters other than Emoji, in addition to Segoe UI
>  > Emoji?
> 
> 
> The documentation describes this field as the "implicit resolved level 
> of the glyph run". Odd levels indicate RTL, and the function asks for 
> the right side position as origin, so I think they would be reordered.
> 
> As there is no reference to bidi in w32font.c, I assumed glyphs reach 
> this layer prepared to be rendered ltr.

Yes, that's true.

> I think the only color font that Windows has is the emoji one. I'll try 
> to find some other to test this.

Thanks.

> >> +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.

Previous Next

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