bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: 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@debbugs.gnu.org
> From: Cecilio Pardo <cpardo@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]