GNU bug report logs -
#73730
31.0.50; Support for color fonts on MS-Windows
Previous Next
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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73730 in the body.
You can then email your comments to 73730 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Thu, 10 Oct 2024 11:17:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Cecilio Pardo <cpardo <at> imayhem.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 10 Oct 2024 11:17:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The attached patch is a preliminar implementation of a DirectWrite font
driver that allows for color fonts, tested only on Windows 11.
There is much to be refined about quality, performance (caching), OS
version conditionals, etc.
Before doing all that, I need to know that this is the right (or at
least good enough) way to do it.
The DirectWrite font driver mounts on top of a copy of the harfbuzz one,
and then replaces some of the functions, but some of the hb functions
include eassert to check that the driver for a font is harfbuzz. I don't
know how to deal with that.
I suppose that if we skip harfbuzz completely, then we would have to
reimplement a lot of stuff with DirectWrite?
Also uniscribe_open has been modified to change the driver assigned to
the font unconditionally to dwrite.
--
Cecilio Pardo
[0001-Font-driver-for-DirectWrite-MS-Windows-supporting-co.patch (text/plain, attachment)]
[emacs_3xjaQ7etE9.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Thu, 10 Oct 2024 13:10:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 10 Oct 2024 13:16:23 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> The attached patch is a preliminar implementation of a DirectWrite font
> driver that allows for color fonts, tested only on Windows 11.
Thanks!
> There is much to be refined about quality, performance (caching), OS
> version conditionals, etc.
>
> Before doing all that, I need to know that this is the right (or at
> least good enough) way to do it.
>
> The DirectWrite font driver mounts on top of a copy of the harfbuzz one,
> and then replaces some of the functions, but some of the hb functions
> include eassert to check that the driver for a font is harfbuzz. I don't
> know how to deal with that.
If we use a (slightly modified) HarfBuzz font driver (see below), this
won't be a problem, right?
> I suppose that if we skip harfbuzz completely, then we would have to
> reimplement a lot of stuff with DirectWrite?
Yes, I don't want to skip HarfBuzz, since we want HarfBuzz to be our
primary text-shaping engine. We don't want to rely on
Windows-specific shapers because MS has a habit of deprecating them at
will (which happened with Uniscribe). The experts on text shaping are
hard to get on board, so we don't want to have to rewrite our display
routines when MS decide to come up with a shining new shaper.
> Also uniscribe_open has been modified to change the driver assigned to
> the font unconditionally to dwrite.
That's temporary, I presume?
Some comments about significant issues below.
> @@ -3202,7 +3202,7 @@ AC_DEFUN
> W32_OBJ="$W32_OBJ w32image.o"
> fi
> W32_LIBS="$W32_LIBS -lwinmm -lgdi32 -lcomdlg32"
> - W32_LIBS="$W32_LIBS -lmpr -lwinspool -lole32 -lcomctl32"
> + W32_LIBS="$W32_LIBS -lmpr -lwinspool -lole32 -lcomctl32 -ldwrite"
This we cannot do, for two reasons: (1) mingw.org's MinGW doesn't have
the libdwrite.dll.a import library, and (2) linking against -ldwrite
will make Emacs refuse to start on systems without DWrite.dll.
Instead, we need to use LoadLibrary at startup time to load the DLL,
like we do with HarfBuzz, and if the load succeeds, use get_proc_addr
to assign the addresses of APIs we need to use to function pointers;
then we call the functions through those pointers. See w32image.c for
how we do that with GdiPlus.dll and w32uniscribe.c for how we do that
with libharfbuzz-0.dll.
> --- a/src/font.h
> +++ b/src/font.h
> @@ -978,6 +978,7 @@ valid_font_driver (struct font_driver const *d)
> extern struct font_driver uniscribe_font_driver;
> #ifdef HAVE_HARFBUZZ
> extern struct font_driver harfbuzz_font_driver;
> +extern struct font_driver dwrite_font_driver;
Do we really need a whole new font driver? I hoped that we'd only
need to replace the functions we call to actually draw the font glyphs
in w32font_draw (ExtTextOutW etc.) with the appropriate replacements
from Direct2D. You see, HarfBuzz already does the job of finding the
appropriate font glyphs when we need some non-trivial font processing
(like character compositions), so I thought all we needed was to be
able to actually draw the font glyphs of color fonts.
IOW, how about just modifying the few methods of the HarfBuzz font
driver when DirectWrite is available, and otherwise leaving the
HarfBuzz font driver be the one which supports this? With Uniscribe
we had legacy support issues (Windows 9X etc.), but there's no such
problem with HarfBuzz vs DirectWrite, so adding yet another font
driver which needs to coexist with the others is a complexity I'd like
to avoid. In my mental model, we just use DirectWrite for low-level
drawing of font glyphs, and otherwise we still keep the HarfBuzz font
driver. Does that make sense?
> +/* Initialized on syms_of_w32dwrite_for_pdumper */
> +IDWriteFactory *dwrite_factory = NULL;
> +IDWriteFactory2 *dwrite_factory2 = NULL;
> +IDWriteGdiInterop *gdi_interop = NULL;
> +IDWriteRenderingParams *rendering_params = NULL;
These should probably be static, if they are only used in this one
file.
> +static void
> +verify_hr (HRESULT hr, const char *msg)
> +{
> + if (FAILED (hr))
> + {
> + printf ("Error: %s\n", msg);
> + abort ();
> + }
> +}
This will need to be replaced with something more suitable.
> +static Lisp_Object
> +dwrite_list (struct frame *f, Lisp_Object font_spec)
> +{
> + Lisp_Object fonts = w32font_list_internal (f, font_spec, true);
> + for (Lisp_Object tail = fonts; CONSP (tail); tail = XCDR (tail))
> + ASET (XCAR (tail), FONT_TYPE_INDEX, Qdwrite);
> +
> + FONT_ADD_LOG ("dwrite-list", font_spec, fonts);
> + return fonts;
> +}
> +
> +static Lisp_Object
> +dwrite_match (struct frame *f, Lisp_Object font_spec)
> +{
> + Lisp_Object entity = w32font_match_internal (f, font_spec, true);
> + FONT_ADD_LOG ("dwrite-match", font_spec, entity);
> +
> + if (! NILP (entity))
> + ASET (entity, FONT_TYPE_INDEX, Qdwrite);
> + return entity;
> +}
If we avoid defining a new font driver, the above two methods are not
needed, as they do the same as the HarfBuzz driver does.
> +static int
> +dwrite_draw (struct glyph_string *s, int from, int to,
> + int x, int y, bool with_background)
> +{
> + HRGN orig_clip = NULL;
> + int len = to - from;
> +
> + if (s->num_clips > 0)
> + {
> + HRGN new_clip = CreateRectRgnIndirect (s->clip);
> +
> + /* Save clip region for later restoration. */
> + orig_clip = CreateRectRgn (0, 0, 0, 0);
> + if (!GetClipRgn (s->hdc, orig_clip))
> + {
> + DeleteObject (orig_clip);
> + orig_clip = NULL;
> + }
> +
> + if (s->num_clips > 1)
> + {
> + HRGN clip2 = CreateRectRgnIndirect (s->clip + 1);
> +
> + CombineRgn (new_clip, new_clip, clip2, RGN_OR);
> + DeleteObject (clip2);
> + }
> +
> + SelectClipRgn (s->hdc, new_clip);
> + DeleteObject (new_clip);
> + }
> +
> + /* Using OPAQUE background mode can clear more background than expected
> + when Cleartype is used. Draw the background manually to avoid this. */
> + SetBkMode (s->hdc, TRANSPARENT);
> + if (with_background)
> + {
> + HBRUSH brush;
> + RECT rect;
> + struct font *font = s->font;
> + int ascent = font->ascent, descent = font->descent;
> +
> + /* Font's global ascent and descent values might be
> + preposterously large for some fonts. We fix here the case
> + when those fonts are used for display of glyphless
> + characters, because drawing background with font dimensions
> + in those cases makes the display illegible. There's only one
> + more call to the draw method with with_background set to
> + true, and that's in w32_draw_glyph_string_foreground, when
> + drawing the cursor, where we have no such heuristics
> + available. FIXME. */
> + if (s->first_glyph->type == GLYPHLESS_GLYPH
> + && (s->first_glyph->u.glyphless.method == GLYPHLESS_DISPLAY_HEX_CODE
> + || s->first_glyph->u.glyphless.method == GLYPHLESS_DISPLAY_ACRONYM))
> + {
> + ascent =
> + s->first_glyph->slice.glyphless.lower_yoff
> + - s->first_glyph->slice.glyphless.upper_yoff;
> + descent = 0;
> + }
> + brush = CreateSolidBrush (s->gc->background);
> + rect.left = x;
> + rect.top = y - ascent;
> + rect.right = x + s->width;
> + rect.bottom = y + descent;
> + FillRect (s->hdc, &rect, brush);
> + DeleteObject (brush);
> + }
> +
> + if (s->padding_p)
> + {
> + int i;
> + for (i = 0; i < len; i++)
> + dwrite_draw_internal (s->hdc, x, y - s->font->ascent,
> + s->char2b + from, 1, s->font->ascent,
> + GetTextColor(s->hdc), s->font);
> + }
> + else
> + {
> + dwrite_draw_internal( s->hdc, x, y - s->font->ascent,
> + s->char2b + from, len, s->font->ascent,
> + GetTextColor(s->hdc), s->font );
> +
> + }
> +
> + /* Restore clip region. */
> + if (s->num_clips > 0)
> + SelectClipRgn (s->hdc, orig_clip);
> +
> + if (orig_clip)
> + DeleteObject (orig_clip);
> +
> + return len;
> +}
This method looks almost identical to w32font_draw, except that it
calls DirectWrite specific functions instead of ExtTextOutW. It would
be better to reuse the code in w32font.c instead of copying it; a
single test for DirectWrite's availability should not be an issue, I
think (if you are worried about performance).
> + hr = dwrite_factory->lpVtbl->
> + CreateCustomRenderingParams (dwrite_factory,
> + def->lpVtbl->GetGamma(def),
> + def->lpVtbl->GetEnhancedContrast(def),
> + def->lpVtbl->GetClearTypeLevel(def),
> + def->lpVtbl->GetPixelGeometry(def),
> + DWRITE_RENDERING_MODE_GDI_CLASSIC,
> + &rendering_params);
Are there some options for the rendering here that we perhaps need to
discuss? E.g., is DWRITE_RENDERING_MODE_GDI_CLASSIC the only
reasonable choice?
Thanks again for working on this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Thu, 10 Oct 2024 15:15:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 73730 <at> debbugs.gnu.org (full text, mbox):
On 10/10/2024 15:08, Eli Zaretskii wrote:
> IOW, how about just modifying the few methods of the HarfBuzz font
> driver when DirectWrite is available, and otherwise leaving the
> HarfBuzz font driver be the one which supports this? With Uniscribe
> we had legacy support issues (Windows 9X etc.), but there's no such
> problem with HarfBuzz vs DirectWrite, so adding yet another font
> driver which needs to coexist with the others is a complexity I'd like
> to avoid. In my mental model, we just use DirectWrite for low-level
> drawing of font glyphs, and otherwise we still keep the HarfBuzz font
> driver. Does that make sense?
Yes. I'll rewrite it like that.
>> + hr = dwrite_factory->lpVtbl->
>> + CreateCustomRenderingParams (dwrite_factory,
>> + def->lpVtbl->GetGamma(def),
>> + def->lpVtbl->GetEnhancedContrast(def),
>> + def->lpVtbl->GetClearTypeLevel(def),
>> + def->lpVtbl->GetPixelGeometry(def),
>> + DWRITE_RENDERING_MODE_GDI_CLASSIC,
>> + &rendering_params);
>
> Are there some options for the rendering here that we perhaps need to
> discuss? E.g., is DWRITE_RENDERING_MODE_GDI_CLASSIC the only
> reasonable choice?
This gives poor quality, we will definitely use something else. But in
my tests other methods gave fractional widths for glyphs, so I took this
one for the first version.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Thu, 10 Oct 2024 16:35:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 10 Oct 2024 17:14:34 +0200
> Cc: 73730 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> On 10/10/2024 15:08, Eli Zaretskii wrote:
>
> > IOW, how about just modifying the few methods of the HarfBuzz font
> > driver when DirectWrite is available, and otherwise leaving the
> > HarfBuzz font driver be the one which supports this? With Uniscribe
> > we had legacy support issues (Windows 9X etc.), but there's no such
> > problem with HarfBuzz vs DirectWrite, so adding yet another font
> > driver which needs to coexist with the others is a complexity I'd like
> > to avoid. In my mental model, we just use DirectWrite for low-level
> > drawing of font glyphs, and otherwise we still keep the HarfBuzz font
> > driver. Does that make sense?
>
> Yes. I'll rewrite it like that.
Thanks, SGTM.
> >> + hr = dwrite_factory->lpVtbl->
> >> + CreateCustomRenderingParams (dwrite_factory,
> >> + def->lpVtbl->GetGamma(def),
> >> + def->lpVtbl->GetEnhancedContrast(def),
> >> + def->lpVtbl->GetClearTypeLevel(def),
> >> + def->lpVtbl->GetPixelGeometry(def),
> >> + DWRITE_RENDERING_MODE_GDI_CLASSIC,
> >> + &rendering_params);
> >
> > Are there some options for the rendering here that we perhaps need to
> > discuss? E.g., is DWRITE_RENDERING_MODE_GDI_CLASSIC the only
> > reasonable choice?
>
> This gives poor quality, we will definitely use something else. But in
> my tests other methods gave fractional widths for glyphs, so I took this
> one for the first version.
I'd guess DWRITE_RENDERING_MODE_DEFAULT should be the first choice?
And if it gets you corrupted glyphs on display, this is something that
needs debugging, I think. Maybe the code which processes the glyphs,
which you basically copied from w32font.c, needs some adjustment for
DirectWrite or something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Thu, 10 Oct 2024 16:47:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> I'd guess DWRITE_RENDERING_MODE_DEFAULT should be the first choice?
> And if it gets you corrupted glyphs on display, this is something that
> needs debugging, I think. Maybe the code which processes the glyphs,
> which you basically copied from w32font.c, needs some adjustment for
> DirectWrite or something?
It draws well, but when measuring character sizes it gives fractional
values, not integers. Anyway, I will investigate it throroughly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Thu, 10 Oct 2024 21:51:02 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
It looks like DirectWrite can't handle .FON files. When I build emacs,
the fixed-pitch face, which uses the Monospace family, gets the
"Courier" font which we can't use.
I'd say that this wasn't failing before today's windows update, but who
knows...
Any pointers?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Fri, 11 Oct 2024 03:40:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 10 Oct 2024 23:50:00 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> It looks like DirectWrite can't handle .FON files. When I build emacs,
> the fixed-pitch face, which uses the Monospace family, gets the
> "Courier" font which we can't use.
>
> I'd say that this wasn't failing before today's windows update, but who
> knows...
>
> Any pointers?
What happens if you revert commit 7eba90c12227 ?
If this fixes the problem, please look at the rationale described in
the commit log message and see if you get back the problem described
there, and in particular what happens with the faces requested by
info.el. It is possible that the problem described there only happens
on XP, where there's no DirectWrite, in which case we could condition
Qascii_0 so that it doesn't get in the way.
But it is somewhat bothersome that .fon fonts are not supported. Are
you sure this is true? What does Internet search bring? There are
example programs on MSDN which use DirectWrite, can you try them with
Courier and see if they also fail?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Fri, 11 Oct 2024 06:29:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Cc: 73730 <at> debbugs.gnu.org
> Date: Fri, 11 Oct 2024 06:36:55 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Date: Thu, 10 Oct 2024 23:50:00 +0200
> > From: Cecilio Pardo <cpardo <at> imayhem.com>
> >
> > It looks like DirectWrite can't handle .FON files. When I build emacs,
> > the fixed-pitch face, which uses the Monospace family, gets the
> > "Courier" font which we can't use.
> >
> > I'd say that this wasn't failing before today's windows update, but who
> > knows...
> >
> > Any pointers?
>
> What happens if you revert commit 7eba90c12227 ?
>
> If this fixes the problem, please look at the rationale described in
> the commit log message and see if you get back the problem described
> there, and in particular what happens with the faces requested by
> info.el. It is possible that the problem described there only happens
> on XP, where there's no DirectWrite, in which case we could condition
> Qascii_0 so that it doesn't get in the way.
>
> But it is somewhat bothersome that .fon fonts are not supported. Are
> you sure this is true? What does Internet search bring? There are
> example programs on MSDN which use DirectWrite, can you try them with
> Courier and see if they also fail?
After some more thinking: I think something is amiss in your code,
because AFAICT the existing code draws .fon fonts using the 'gdi' font
driver. Here's how to see that:
emacs -Q
M-x font-lock-mode
M-x load-library RET facemenu RET
Now mark some text in *scratch* and type:
M-x facemenu-set-face RET fixed-pitch RET
Then go to some character displayed with fixed-pitch face and type
"C-u C-x =". When I do that in the current Emacs, I see:
position: 78 of 147 (52%), column: 6
character: c (displayed as c) (codepoint 99, #o143, #x63)
charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x63
script: latin
syntax: w which means: word
category: .:Base, L:Strong L2R, a:ASCII, l:Latin, r:Roman
to input: type "C-x 8 RET 63" or "C-x 8 RET LATIN SMALL LETTER C"
buffer code: #x63
file code: #x63 (encoded by coding system iso-latin-1-dos)
display: by this font (glyph code):
gdi:-raster-Courier-regular-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x63)
Note the last line: we already detect that this font should use the
'gdi' font backend. So either your new code somehow bypassed this
detection, or the fallback on old glyph-drawing APIs which are used on
the current master branch by the 'gdi' font driver is missing
something. AFAIR (and my memory is not reliable in this matter, so
please check with the code), we decide that this font needs to be
drawn by the 'gdi' font driver when we look for fonts for the
"Monospace" family: I think the 'harfbuzz' font backend rejects it for
some reason (I don't remember which), whereas 'gdi' accepts it.
Bottom line: we should use the 'gdi' font backend for these fonts,
like we do with the current code. The 'harfbuzz' font driver, with or
without the new DirectWrite methods, should not be used for them,
presumably for reasons similar to those which determined how the
current code works.
If the above doesn't help, please tell more details about how
DirectWrite "cannot handle .FON fonts", and let's take it from there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Fri, 11 Oct 2024 07:21:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 73730 <at> debbugs.gnu.org (full text, mbox):
On 11/10/2024 8:28, Eli Zaretskii wrote:
> Bottom line: we should use the 'gdi' font backend for these fonts,
> like we do with the current code. The 'harfbuzz' font driver, with or
> without the new DirectWrite methods, should not be used for them,
> presumably for reasons similar to those which determined how the
> current code works.
Ok. Thanks a lot.
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sat, 12 Oct 2024 13:35:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Tue, 15 Oct 2024 22:19:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 73730 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The attached patch works without a new font driver.
This requires the harfbuzz font backend to be available.
It works by modifying the harfbuzz backend to use DirectWrite at
some points, if it is available:
- When encoding characters: w32hb_encode_char
- When measuring text: w32font_text_extents
- When drawing text: w32font_draw
DirectWrite is setup by calling w32_initialize_direct_write. From
that point, the function w32_use_direct_write will return true if
DirectWrite is to be used.
The lisp variable w32-inhibit-direct-write can switches it on and off.
It builds with Mingw64 and Mingw. As mingw doesn't have the DirectWrite
includes, I had to declare a lot of things at the start of the file.
This line marks the end of that:
/* End of dwrite_3.h definitions. */
I have tested this only on Windows 11.
[0001-Implement-drawing-text-with-DirectWrite-on-MS-Window.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Wed, 16 Oct 2024 11:03:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 16 Oct 2024 00:18:20 +0200
> Cc: 73730 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> The attached patch works without a new font driver.
Thanks a lot for working on this!
I'n CC'ing Ken, who maintains the Cygwin ports of Emacs, because I
think the cygw32 build would like to use this feature as well. Ken,
could you please give the patch some testing and report any problems?
> This requires the harfbuzz font backend to be available.
>
> It works by modifying the harfbuzz backend to use DirectWrite at
> some points, if it is available:
>
> - When encoding characters: w32hb_encode_char
> - When measuring text: w32font_text_extents
> - When drawing text: w32font_draw
>
> DirectWrite is setup by calling w32_initialize_direct_write. From
> that point, the function w32_use_direct_write will return true if
> DirectWrite is to be used.
>
> The lisp variable w32-inhibit-direct-write can switches it on and off.
This design SGTM, thanks. Eventually, we will need a NEWS entry for
this change, and w32-inhibit-direct-write (which I'd rename to
w32-inhibit-dwrite for better mnemonic value) should be mentioned
there.
> It builds with Mingw64 and Mingw. As mingw doesn't have the DirectWrite
> includes, I had to declare a lot of things at the start of the file.
> This line marks the end of that:
>
> /* End of dwrite_3.h definitions. */
I wonder if this is sufficiently future-proof. AFAIU, dwrite_3.h is a
generated file, so it could change in the future. So maybe we should
only define these on our own for mingw.org, and in MinGW64 builds use
the header file they provide? Maybe even on a separate header file?
This way, at least most of the users will be immune to future changes
in the header file. WDYT?
> * configure.ac: Add src/w32drite to W32_OBJ
^
Period missing there.
> * src/w32dwrite.c: This is a new file.
> (w32-initialize-direct-write): Initializes the DirectWrite library if
^^^^^^^^^^^
A nit: our style is to say "Initialize".
> (w32_use_direct_write): Allows to check if DirectWrite is available
^^^^^^^^^^^^^^^
And here, just "Check" will do.
> (w32_dwrite_encode_char): Replacement for harfbuzz's encode_char.
> (w32_dwrite_text_extents): Replacement for w32font text_extents.
> (w32_dwrite_draw): Replacement for w32font draw.
> (w32_dwrite_free_cached_face): Used on the font deletion process to
> also delete DirectWrite data.
> (verify_hr): Verify COM method results.
These are new functions, so please say so. Like this:
(w32_dwrite_encode_char): New function, implements encode_char for
DirectWrite.
> * src/w32font.c:
> (w32font_text_extents): If DirectWrite is enabled, call
This and similar entries should be formatted like so:
* src/w32font.c (w32font_text_extents): If DirectWrite is enabled, ...
We only break the line between the file name and the function name if
the latter is too long to be placed on the same line.
> * src/w32uniscribe.c:
> (w32hb_encode_char): If DirectWrite is enabled, call
> w32_dwrite_encode_char.
Same here.
> --- /dev/null
> +++ b/src/w32dwrite.c
> @@ -0,0 +1,930 @@
> +/* Support for using DirectWrite on MS-Windows to draw text. This allows
> + for color fonts. ^^
Two spaces between sentences, per our conventions.
> +/*
> + This requires the harfbuzz font backend to be available.
^^^^^^^^
HarfBuzz, here and elsewhere (except in code).
> +#include <config.h>
> +#include <math.h>
> +#include <windows.h>
> +
> +#include "frame.h"
> +#include "w32font.h"
> +#include "w32common.h"
> +#include "w32term.h"
> +
> +#include "initguid.h"
> +#include <ole2.h>
> +#include <unknwn.h>
That should be <initguid.h>. And I think the last 3 includes should
be before our Emacs-specific header files.
> +/* The following definitions would be included from dwrite_3.h, but it
> + is not available when building with MinGW. Methods that we don't use
^^^^^
Please say "mingw.org's MinGW", to make this more clear.
> + are declared with the UNUSED macro, to avoid bringing in more types
> + that would need to be declared.
> +*/
> +
> +#define UNUSED(name) void (STDMETHODCALLTYPE *name)(void)
Can we use something more specific than UNUSED here? Like W32_UNUSED
or maybe EMACS_DWRITE_UNUSED?
> +/* Function prototypes. */
> +void w32_initialize_direct_write (void);
> +bool w32_use_direct_write (struct w32font_info *w32font);
> +void w32_dwrite_draw (HDC hdc, int x, int y, unsigned *glyphs, int len,
> + COLORREF color, struct font *font );
> +void w32_dwrite_text_extents (struct font *font, const unsigned *code,
> + int nglyphs, struct font_metrics *metrics);
> +unsigned w32_dwrite_encode_char (struct font *font, int c);
> +void w32_dwrite_free_cached_face(void *cache);
> +
> +/* This two functions are on w32uninscribe.c */
> +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);
These prototypes should go to w32font.h. Then you won't need to
repeat them in other source files.
> +static void
> +verify_hr (HRESULT hr, const char *msg)
> +{
> + if (FAILED (hr))
> + emacs_abort ();
> +}
I think aborting is too harsh here. We could use eassert instead (in
which case it will abort, but only in a build with --enable-checking).
We could also augment that with DebPrint in important places, which
will show a message when a production build of Emacs is run under a
debugger. In a production build (i.e., when eassert compiles to
nothing), it is better to disable the use of DirectWrite when one of
these problems happen, if you detect that early enough, and fall back
to HarfBuzz instead. Is that reasonable here?
> + return abs(logfont.lfHeight);
^
SPC missing there.
> +void
> +w32_dwrite_free_cached_face(void *cache)
^
And here (and in a few places elsewhere in the patch).
> +static float
> +convert_metrics_sz( int sz, float font_size, int units_per_em )
> +{
> + return (float)sz * font_size / units_per_em;
^^
Here also.
> + dwrite_font_face->lpVtbl->
> + GetMetrics (dwrite_font_face, &dwrite_font_metrics);
It is better not to break at the dereference operator:
dwrite_font_face->lpVtbl->GetMetrics (dwrite_font_face,
&dwrite_font_metrics);
Same in other places in the patch.
> + CreateFactory create_factory
> + = (CreateFactory) get_proc_addr (direct_write, "DWriteCreateFactory");
It is better to call the procedure pointers by names that are closer
to their names in the library. In this case, I'd use
dw_create_factory instead of a more general create_factory.
> + /* We never Release this, get_bitmap_render_target reuses it. */
^^^^^^^
"release", in lower case.
> + DWRITE_GLYPH_RUN glyph_run;
> + glyph_run.fontFace = dwrite_font_face;
> + glyph_run.fontEmSize = font_size;
> + glyph_run.glyphIndices = indices;
> + glyph_run.glyphCount = len;
> + glyph_run.isSideways = false;
> + 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?
> + /* No color. Just draw the GlyphRun. */
^^
Two spaces.
> + /* If there were color glyphs, layers contains a containts a list
^^^^^^^^^^ ^^^^^^^^^^^
One of these is redundant.
> --- a/src/w32font.c
> +++ b/src/w32font.c
> @@ -55,6 +55,13 @@ #define VIETNAMESE_CHARSET 163
> #define JOHAB_CHARSET 130
> #endif
>
> +/* Function prototypes from w32write.c */
^^^^^^^^^^
w32dwrite.c
> +bool w32_use_direct_write (struct w32font_info *w32font);
> +void w32_dwrite_draw (HDC hdc, int x, int y, unsigned *glyphs, int len,
> + COLORREF color, struct font *font );
> +void w32_dwrite_text_extents (struct font *font, const unsigned *code,
> + int nglyphs, struct font_metrics *metrics);
> +
If you put them on w32font.h, this won't be needed.
> --- a/src/w32uniscribe.c
> +++ b/src/w32uniscribe.c
> @@ -44,6 +44,15 @@ #define _WIN32_WINNT 0x0600
> #include "pdumper.h"
> #include "w32common.h"
>
> +/* Function prototypes from w32dwrite.c */
> +bool w32_use_direct_write (struct w32font_info *w32font);
> +unsigned w32_dwrite_encode_char (struct font *font, int c);
> +void w32_dwrite_free_cached_face (void *cache);
Likewise: if these are in w32font.h, you won't need this.
> +/* Function prototypes from this file */
> +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?
> +void *w32_font_get_dwrite_cache (struct font *font, float *font_size)
We break the line between the return type and the function name:
void *
w32_font_get_dwrite_cache (struct font *font, float *font_size)
> + if (w32_use_direct_write(&uniscribe_font->w32_font))
> + {
> + return w32_dwrite_encode_char(font, c);
> + }
No need for braces if you have just one statement.
Compiling this with mingw.org's MinGW GCC 9.2.0, I get the following
warnings:
In file included from w32dwrite.c:44:
w32dwrite.c:123:13: warning: 'IID_IDWriteBitmapRenderTarget1' initialized and declared 'extern'
123 | DEFINE_GUID( CC w32inevt.oIID_IDWriteBitmapRenderTarget1
, 0x791e8298, 0x3ef3, 0x4230, 0x98,0x80, 0xc9,0xbd,0xec,0xc4,0x20,0x64);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
w32dwrite.c:124:13: warning: 'IID_IDWriteFactory2' initialized and declared 'extern'
124 | DEFINE_GUID(IID_IDWriteFactory2, 0x0439fc60, 0xca44, 0x4994, 0x8d,0xee, 0x3a,0x9a,0xf7,0xb7,0x32,0xec);
| ^~~~~~~~~~~~~~~~~~~
w32dwrite.c:125:13: warning: 'IID_IDWriteFactory' initialized and declared 'extern'
125 | DEFINE_GUID(IID_IDWriteFactory, 0xb859ee5a, 0xd838, 0x4b5b, 0xa2,0xe8, 0x1a,0xdc,0x7d,0x93,0xdb,0x48);
| ^~~~~~~~~~~~~~~~~~
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Wed, 16 Oct 2024 11:34:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Cc: 73730 <at> debbugs.gnu.org
> Date: Wed, 16 Oct 2024 14:01:36 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Date: Wed, 16 Oct 2024 00:18:20 +0200
> > Cc: 73730 <at> debbugs.gnu.org
> > From: Cecilio Pardo <cpardo <at> imayhem.com>
> >
> > The attached patch works without a new font driver.
>
> Thanks a lot for working on this!
And here's the first bug report after applying this patch:
emacs -Q
M-: (w32-find-non-USB-fonts) RET
This pops up the Emacs Abort dialog. The backtrace and some
additional information are below. The error from
GetGdiCompatibleGlyphMetrics (0x80070057) seems to be E_INVALIDARG.
Perhaps if w32_dwrite_text_extents fails, it should not abort, but
instead fall back on the old code?
If you cannot reproduce this (maybe it depends on what fonts are
installed), feel free to ask me to provide more information or try
some solutions. In case it matters, this is a 32-bit build configured
as --with-wide-int --without-native-compilation.
Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x76611813 in KERNELBASE!DebugBreak () from C:\WINDOWS\SysWOW64\KernelBase.dll
(gdb) bt
#0 0x76611813 in KERNELBASE!DebugBreak ()
from C:\WINDOWS\SysWOW64\KernelBase.dll
#1 0x012f47e1 in emacs_abort () at w32fns.c:11570
#2 0x013221ba in verify_hr (hr=-2147024809,
msg=0x18cbe58 <IID_IDWriteFactory+48> "Failed to GetGdiCompatibleGlyphMetrics") at w32dwrite.c:504
#3 0x01322430 in text_extents_internal (dwrite_font_face=0x9600720,
font_size=0, code=0xbfc6c0, nglyphs=1, metrics=0xbfc6b6) at w32dwrite.c:588
#4 0x013226d4 in w32_dwrite_text_extents (font=0xbf3e9f0, code=0xbfc6c0,
nglyphs=1, metrics=0xbfc6b6) at w32dwrite.c:654
#5 0x012fb29a in w32font_text_extents (font=0xbf3e9f0, code=0xbfc6c0,
nglyphs=1, metrics=0xbfc6b6) at w32font.c:464
#6 0x01229249 in Ffont_get_glyphs (font_object=XIL(0xa00000000bf3e9f0),
from=make_fixnum(0), to=make_fixnum(3), object=XIL(0xa00000000bc5cd60))
at font.c:5454
#7 0x011f1176 in funcall_subr (subr=0x187cb40 <Sfont_get_glyphs>, numargs=4,
args=0xa2eb2a0) at eval.c:3144
#8 0x0125eeb2 in exec_byte_code (fun=XIL(0xa00000000bd9e450),
args_template=257, nargs=1, args=0xbfcf70) at bytecode.c:813
#9 0x011f198b in funcall_lambda (fun=XIL(0xa00000000bd9e450), nargs=1,
arg_vector=0xbfcf68) at eval.c:3229
#10 0x011f0a51 in funcall_general (fun=XIL(0xa00000000bd9e450), numargs=1,
args=0xbfcf68) at eval.c:3021
#11 0x011f0d7a in Ffuncall (nargs=2, args=0xbfcf60) at eval.c:3070
#12 0x01206ebc in mapcar1 (leni=76, vals=0x0, fn=XIL(0xa00000000bd9e450),
seq=XIL(0xc000000000f3ec30)) at fns.c:3370
#13 0x01207af8 in Fmapc (function=XIL(0xa00000000bd9e450),
sequence=XIL(0xc000000000f3ec30)) at fns.c:3507
#14 0x011f10c7 in funcall_subr (subr=0x187bb40 <Smapc>, numargs=2,
args=0xa2eb1f0) at eval.c:3140
#15 0x0125eeb2 in exec_byte_code (fun=XIL(0xa000000009d8ab78),
args_template=0, nargs=0, args=0xa2eb200) at bytecode.c:813
#16 0x011f198b in funcall_lambda (fun=XIL(0xa000000009d8aa58), nargs=0,
arg_vector=0xbfd6d0) at eval.c:3229
#17 0x011f17a6 in apply_lambda (fun=XIL(0xa000000009d8aa58), args=XIL(0),
count=480) at eval.c:3192
#18 0x011ef553 in eval_sub (form=XIL(0xc000000000efa680)) at eval.c:2622
#19 0x011ee62c in Feval (form=XIL(0xc000000000efa680), lexical=XIL(0x30))
at eval.c:2439
#20 0x011f10c7 in funcall_subr (subr=0x187a1c0 <Seval>, numargs=2,
args=0xa2eb1a0) at eval.c:3140
#21 0x0125eeb2 in exec_byte_code (fun=XIL(0xa0000000098cdce8),
args_template=513, nargs=2, args=0xa2eb2f8) at bytecode.c:813
#22 0x011f198b in funcall_lambda (fun=XIL(0xa00000000bd346a0), nargs=0,
arg_vector=0xbfe040) at eval.c:3229
#23 0x011f0a51 in funcall_general (fun=XIL(0xa00000000bd346a0), numargs=0,
args=0xbfe040) at eval.c:3021
#24 0x011f0d7a in Ffuncall (nargs=1, args=0xbfe038) at eval.c:3070
#25 0x011e67ba in call0 (fn=XIL(0xa00000000bd346a0)) at lisp.h:3528
#26 0x011eb1e1 in Fhandler_bind_1 (nargs=3, args=0xa2eb128) at eval.c:1463
#27 0x011f1523 in funcall_subr (subr=0x187a080 <Shandler_bind_1>, numargs=3,
args=0xa2eb128) at eval.c:3161
#28 0x0125eeb2 in exec_byte_code (fun=XIL(0xa00000000997d720),
args_template=1025, nargs=4, args=0xbfe9e0) at bytecode.c:813
#29 0x011f198b in funcall_lambda (fun=XIL(0xa00000000997d720), nargs=4,
arg_vector=0xbfe9c0) at eval.c:3229
#30 0x011f0a51 in funcall_general (fun=XIL(0xa00000000997d720), numargs=4,
args=0xbfe9c0) at eval.c:3021
#31 0x011f0d7a in Ffuncall (nargs=5, args=0xbfe9b8) at eval.c:3070
#32 0x011e1c1a in Ffuncall_interactively (nargs=5, args=0xbfe9b8)
at callint.c:250
#33 0x011f1523 in funcall_subr (subr=0x18798c0 <Sfuncall_interactively>,
numargs=5, args=0xbfe9b8) at eval.c:3161
#34 0x011f09ea in funcall_general (fun=XIL(0xa0000000018798c0), numargs=5,
args=0xbfe9b8) at eval.c:3017
#35 0x011f0d7a in Ffuncall (nargs=6, args=0xbfe9b0) at eval.c:3070
#36 0x011efedd in Fapply (nargs=3, args=0xbfebd8) at eval.c:2742
#37 0x011e226a in Fcall_interactively (function=XIL(0x7fcb530),
record_flag=XIL(0), keys=XIL(0xa000000009ef2300)) at callint.c:342
#38 0x011f110f in funcall_subr (subr=0x1879900 <Scall_interactively>,
numargs=3, args=0xa2eb078) at eval.c:3142
#39 0x0125eeb2 in exec_byte_code (fun=XIL(0xa000000009f0ad40),
args_template=1025, nargs=1, args=0xbff7a0) at bytecode.c:813
#40 0x011f198b in funcall_lambda (fun=XIL(0xa000000009f0ad40), nargs=1,
arg_vector=0xbff798) at eval.c:3229
#41 0x011f0a51 in funcall_general (fun=XIL(0xa000000009f0ad40), numargs=1,
args=0xbff798) at eval.c:3021
#42 0x011f0d7a in Ffuncall (nargs=2, args=0xbff790) at eval.c:3070
#43 0x010f681d in command_loop_1 () at keyboard.c:1545
#44 0x011eba71 in internal_condition_case (bfun=0x10f5c2d <command_loop_1>,
handlers=XIL(0x90), hfun=0x10f4c86 <cmd_error>) at eval.c:1598
#45 0x010f5692 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1163
#46 0x011eabee in internal_catch (tag=XIL(0x12750),
func=0x10f565b <command_loop_2>, arg=XIL(0x90)) at eval.c:1277
#47 0x010f55fd in command_loop () at keyboard.c:1141
#48 0x010f46e6 in recursive_edit_1 () at keyboard.c:749
#49 0x010f4984 in Frecursive_edit () at keyboard.c:832
#50 0x010efaa5 in main (argc=2, argv=0x7c72570) at emacs.c:2624
Lisp Backtrace:
"font-get-glyphs" (0xa2eb2a0)
0xbd9e450 PVEC_CLOSURE
"mapc" (0xa2eb1f0)
"w32-find-non-USB-fonts" (0xbfd6d0)
"eval" (0xa2eb1a0)
0xbd34678 PVEC_CLOSURE
0xbd346a0 PVEC_CLOSURE
"handler-bind-1" (0xa2eb128)
"eval-expression" (0xbfe9c0)
"funcall-interactively" (0xbfe9b8)
"call-interactively" (0xa2eb078)
"command-execute" (0xbff798)
(gdb) fr 6
#6 0x01229249 in Ffont_get_glyphs (font_object=XIL(0xa00000000bf3e9f0),
from=make_fixnum(0), to=make_fixnum(3), object=XIL(0xa00000000bc5cd60))
at font.c:5454
5454 font->driver->text_extents (font, &code, 1, &metrics);
(gdb) pp font_object
#<font-object "-outline-Sans Serif Collection-regular-normal-normal-sans-*-*-*-*-p-*-iso10646-1">
(gdb) fr 3
#3 0x01322430 in text_extents_internal (dwrite_font_face=0x9600720,
font_size=0, code=0xbfc6c0, nglyphs=1, metrics=0xbfc6b6) at w32dwrite.c:588
588 verify_hr (hr, "Failed to GetGdiCompatibleGlyphMetrics");
(gdb) p/x hr
$1 = 0x80070057
(gdb) fr 5
#5 0x012fb29a in w32font_text_extents (font=0xbf3e9f0, code=0xbfc6c0,
nglyphs=1, metrics=0xbfc6b6) at w32font.c:464
464 w32_dwrite_text_extents (font, code, nglyphs, metrics);
(gdb) p *w32_font
$2 = {
font = {
header = {
size = 1661034513
},
props = {XIL(0x9b40), XIL(0xe910), XIL(0xa5622a0), XIL(0x103b0),
XIL(0xb010), make_fixnum(20544), make_fixnum(25632), make_fixnum(25664),
make_fixnum(0), XIL(0), make_fixnum(0), XIL(0), XIL(0xc00000000be75600),
XIL(0), XIL(0x800000000bce6cf0), XIL(0x800000000bce6ce0), XIL(0)},
min_width = 11,
max_width = 76,
pixel_size = 0,
height = 39,
space_width = 11,
average_width = 11,
ascent = 26,
descent = 13,
underline_thickness = 1,
underline_position = 2,
vertical_centering = false,
baseline_offset = 0,
relative_compose = 0,
default_ascent = 26,
encoding_charset = -1,
repertory_charset = -1,
driver = 0x19c78a0 <harfbuzz_font_driver>
},
metrics = {
tmHeight = 39,
tmAscent = 26,
tmDescent = 13,
tmInternalLeading = 23,
tmExternalLeading = 0,
tmAveCharWidth = 11,
tmMaxCharWidth = 76,
tmWeight = 400,
tmOverhang = 0,
tmDigitizedAspectX = 96,
tmDigitizedAspectY = 96,
tmFirstChar = 0 L'\000',
tmLastChar = 65071 L'\xfe2f',
tmDefaultChar = 1 L'\001',
tmBreakChar = 2 L'\002',
tmItalic = 0 '\000',
tmUnderlined = 0 '\000',
tmStruckOut = 0 '\000',
tmPitchAndFamily = 39 '\'',
tmCharSet = 0 '\000'
},
glyph_idx = 16,
cached_metrics = 0x0,
n_cache_blocks = 0,
hfont = 0x2d0a1e66
}
(gdb)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Wed, 16 Oct 2024 21:37:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 73730 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
Also, most of the style changes are done.
- With MingGW64, use dwrite_3.h normally.
- renamed w32-inhibit-direct-write to w32-inhibit-dwrite, and some other
things.
BTW, why does that variable show as undocumented with
describe-variables? What am I doing wrong?
Pending:
- NEWS entry.
- Instead of aborting on failure, just disable DirectWrite and let emacs
continue. This will take some work.
- mingw warnings.
>
>> + 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.
I think the only color font that Windows has is the emoji one. I'll try
to find some other to test this.
>> +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.
[0001-Implement-drawing-text-with-DirectWrite-on-MS-Window.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Thu, 17 Oct 2024 06:22:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Thu, 17 Oct 2024 10:40:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 73730 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 20 Oct 2024 13:36:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 73730 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 20 Oct 2024 13:57:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 20 Oct 2024 15:35:10 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> Cc: 73730 <at> debbugs.gnu.org, kbrown <at> cornell.edu
>
>
> 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.
Great, thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 20 Oct 2024 16:18:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 20 Oct 2024 15:35:10 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> Cc: 73730 <at> debbugs.gnu.org, kbrown <at> cornell.edu
>
> 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.
Maybe it's better to use some default size in text_extents instead?
The pixel size of the default font is known (see FRAME_LINE_HEIGHT),
so maybe just use it if you get a font of size zero? That could be a
more future-proof fix, since we could get such fonts in other
situations as well.
Regardless, we should keep the strategy of falling back to the old
code if DirectWrite fails.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 20 Oct 2024 18:22:02 GMT)
Full text and
rfc822 format available.
Message #61 received at submit <at> debbugs.gnu.org (full text, mbox):
On 20/10/2024 18:17, Eli Zaretskii wrote:
>> If the case of size <= 0, we are now falling back to
>> w32font_text_extents.
>
> Maybe it's better to use some default size in text_extents instead?
> The pixel size of the default font is known (see FRAME_LINE_HEIGHT),
> so maybe just use it if you get a font of size zero? That could be a
> more future-proof fix, since we could get such fonts in other
> situations as well.
The reason w32fint_text_extents has a value to return is because when
the specified font size is 0:
"The font mapper uses a default height value when it searches for a match."
So it gives a font with a size that we cannot know, because when we ask
it says it is 0.
So we may return our own default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 20 Oct 2024 18:34:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 20 Oct 2024 20:20:29 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> On 20/10/2024 18:17, Eli Zaretskii wrote:
>
> >> If the case of size <= 0, we are now falling back to
> >> w32font_text_extents.
> >
> > Maybe it's better to use some default size in text_extents instead?
> > The pixel size of the default font is known (see FRAME_LINE_HEIGHT),
> > so maybe just use it if you get a font of size zero? That could be a
> > more future-proof fix, since we could get such fonts in other
> > situations as well.
>
> The reason w32fint_text_extents has a value to return is because when
> the specified font size is 0:
>
> "The font mapper uses a default height value when it searches for a match."
>
> So it gives a font with a size that we cannot know, because when we ask
> it says it is 0.
>
> So we may return our own default.
I'm not sure I understand the last sentence above.
It should be easy to modify w32-find-non-USB-fonts to specify a
default value for SIZE if the caller didn't provide it. I just
thought that other callers could do something similar, and therefore
it would be better to use FRAME_LINE_HEIGHT of the selected frame as
the size internally in text_extents if the caller specified zero. If
what you say above disagrees with that, please elaborate why you
disagree.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 20 Oct 2024 18:39:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 73730 <at> debbugs.gnu.org (full text, mbox):
On 20/10/2024 20:33, Eli Zaretskii wrote:
>> Date: Sun, 20 Oct 2024 20:20:29 +0200
>> From: Cecilio Pardo <cpardo <at> imayhem.com>
>>
>> On 20/10/2024 18:17, Eli Zaretskii wrote:
>>
>>>> If the case of size <= 0, we are now falling back to
>>>> w32font_text_extents.
>>>
>>> Maybe it's better to use some default size in text_extents instead?
>>> The pixel size of the default font is known (see FRAME_LINE_HEIGHT),
>>> so maybe just use it if you get a font of size zero? That could be a
>>> more future-proof fix, since we could get such fonts in other
>>> situations as well.
>>
>> The reason w32fint_text_extents has a value to return is because when
>> the specified font size is 0:
>>
>> "The font mapper uses a default height value when it searches for a match."
>>
>> So it gives a font with a size that we cannot know, because when we ask
>> it says it is 0.
>>
>> So we may return our own default.
>
> I'm not sure I understand the last sentence above.
>
> It should be easy to modify w32-find-non-USB-fonts to specify a
> default value for SIZE if the caller didn't provide it. I just
> thought that other callers could do something similar, and therefore
> it would be better to use FRAME_LINE_HEIGHT of the selected frame as
> the size internally in text_extents if the caller specified zero. If
> what you say above disagrees with that, please elaborate why you
> disagree.
No, I meant to agree. Sorry I wasn't clear.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Tue, 22 Oct 2024 22:15:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 73730 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here is a new version with pending issues addressed.
- No abort any more. Now, any failure marks the font as not usable,
falling back to previous driver. If the error is general, then all
of DirectWrite is disabled. eassert and DebPrint are called in these
cases.
- Added a NEWS entry.
- The struct uniscribe_font_info is now in w32font.h
- Build without warnings in both versions on MinGW.
Some things I think we didn't discuss before:
- DirectWrite is available since Windows 7, but color glyphs are
available only since Windows 8.1. We only enable DirectWrite since
Windows 8.1. This is stated on the NEWS entry.
- The default value for the Gamma render parameter in DirectWrite
gives very 'light' characters. I changed it to 1.4, which matches
GDI and looks better. But that's just my opinion.
I couldn't find any hebrew font with color glyphs to test RTL
display. I found a latin+arabic one, Cairo Play:
https://github.com/Gue3bara/Cairo
https://fonts.google.com/specimen/Cairo+Play
It displays diacritics in different colors on both scripts.
It seems to work fine in emacs. I attach captures with and without
DirectWrite, and compared to Courier New.
[emacs_KbWp4eBFOp.png (image/png, attachment)]
[emacs_SiXOdpA67i.png (image/png, attachment)]
[0001-Implement-drawing-text-with-DirectWrite-on-MS-Window.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Wed, 23 Oct 2024 10:04:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Oct 2024 00:14:12 +0200
> Cc: 73730 <at> debbugs.gnu.org, kbrown <at> cornell.edu
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> Here is a new version with pending issues addressed.
Thanks.
> - DirectWrite is available since Windows 7, but color glyphs are
> available only since Windows 8.1. We only enable DirectWrite since
> Windows 8.1. This is stated on the NEWS entry.
Sounds okay, but I don't see the Windows version tested anywhere in
the code which initializes DWrite. What did I miss?
> - The default value for the Gamma render parameter in DirectWrite
> gives very 'light' characters. I changed it to 1.4, which matches
> GDI and looks better. But that's just my opinion.
Does the best value depend on whether the theme is light or dark? In
any case, this sounds like a good candidate for a variable that people
could modify if they want. Maybe we should also expose to Lisp the
values of enhanced contrast and clear-type level? Assuming that
setting these from .emacs (or maybe in early-init?) at all could take
effect, that is.
> I couldn't find any hebrew font with color glyphs to test RTL
> display. I found a latin+arabic one, Cairo Play:
>
> https://github.com/Gue3bara/Cairo
> https://fonts.google.com/specimen/Cairo+Play
>
> It displays diacritics in different colors on both scripts.
>
> It seems to work fine in emacs. I attach captures with and without
> DirectWrite, and compared to Courier New.
Looks okay to me, thanks.
> +** Emacs on MS-Windows now supports color fonts.
> +On Windows 8.1 and later versions Emacs now uses DirectWrite to draw
> +text, which supports color fonts. This can be disabled by setting the
> +variable w32-inhibit-dwrite to t.
Names of variables and functions in NEWS should be quoted 'like this'.
> + /* We can get fonts with a size of 0. GDI handles this by using a default
> + size. We do the same. */
> + if (font_size <= 0.0f)
> + font_size = FRAME_LINE_HEIGHT (XFRAME (selected_frame));
^^^^^^^^^^^^^^
Maybe use SLECTED_FRAME() here.
> + if (!verify_hr (hr, "Failed to CreateBitmapRenderTarget"))
> + return NULL;
^^^^^^^^^^^^^^^
The indentation here is incorrect: should be 2 columns, not 4.
> + direct_write_available = true;
> +
> + w32_inhibit_dwrite = false;
Does it work to set w32-inhibit-dwrite in the .emacs init file?
> + UINT16 *indices = alloca (len * sizeof (UINT16));
> +
> + for (int i = 0; i < len; i++)
> + indices[i] = glyphs[i];
> +
> + FLOAT *advances = alloca (len * sizeof (FLOAT));
How large can 'len' be? Maybe we should use USE_SAFE_ALLOCA and
friends here, to avoid the possibility of overflowing the C stack if
alloca is called with a too-large argument?
> + for (;;) {
That's not how we format for-loops: the brace should be on the next
line.
Thanks again for working on this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Wed, 23 Oct 2024 14:18:02 GMT)
Full text and
rfc822 format available.
Message #76 received at submit <at> debbugs.gnu.org (full text, mbox):
On 23/10/2024 12:03, Eli Zaretskii wrote:
>> - DirectWrite is available since Windows 7, but color glyphs are
>> available only since Windows 8.1. We only enable DirectWrite since
>> Windows 8.1. This is stated on the NEWS entry.
>
> Sounds okay, but I don't see the Windows version tested anywhere in
> the code which initializes DWrite. What did I miss?
The IDWriteFactory2 interface is only available from 8.1, so it will
fail on previous versions when we request it in
w32_initialize_direct_write.
>> - The default value for the Gamma render parameter in DirectWrite
>> gives very 'light' characters. I changed it to 1.4, which matches
>> GDI and looks better. But that's just my opinion.
>
> Does the best value depend on whether the theme is light or dark?
No, it looks too dim for me on both.
> In any case, this sounds like a good candidate for a variable that people
> could modify if they want. Maybe we should also expose to Lisp the
> values of enhanced contrast and clear-type level? Assuming that
> setting these from .emacs (or maybe in early-init?) at all could take
> effect, that is.
[...]
> Does it work to set w32-inhibit-dwrite in the .emacs init file?
If you change it in .emacs or early-int it will work, but will not
prevent dwrite initialization and some text output. I am
initializing on syms_of_w32uniscribe_for_pdumper. Could I initialize
on some other place, so that the user can skip dwrite completely?
Also, it will allow to add configuracion variables for Gamma, etc,
without having to reinit if the user sets them.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Wed, 23 Oct 2024 17:54:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Oct 2024 16:17:03 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
>
> On 23/10/2024 12:03, Eli Zaretskii wrote:
>
> >> - DirectWrite is available since Windows 7, but color glyphs are
> >> available only since Windows 8.1. We only enable DirectWrite since
> >> Windows 8.1. This is stated on the NEWS entry.
> >
> > Sounds okay, but I don't see the Windows version tested anywhere in
> > the code which initializes DWrite. What did I miss?
>
> The IDWriteFactory2 interface is only available from 8.1, so it will
> fail on previous versions when we request it in
> w32_initialize_direct_write.
OK, so please add a comment there to this effect.
> >> - The default value for the Gamma render parameter in DirectWrite
> >> gives very 'light' characters. I changed it to 1.4, which matches
> >> GDI and looks better. But that's just my opinion.
> >
> > Does the best value depend on whether the theme is light or dark?
>
> No, it looks too dim for me on both.
>
> > In any case, this sounds like a good candidate for a variable that people
> > could modify if they want. Maybe we should also expose to Lisp the
> > values of enhanced contrast and clear-type level? Assuming that
> > setting these from .emacs (or maybe in early-init?) at all could take
> > effect, that is.
>
> [...]
>
> > Does it work to set w32-inhibit-dwrite in the .emacs init file?
>
> If you change it in .emacs or early-int it will work, but will not
> prevent dwrite initialization and some text output. I am
> initializing on syms_of_w32uniscribe_for_pdumper. Could I initialize
> on some other place, so that the user can skip dwrite completely?
> Also, it will allow to add configuracion variables for Gamma, etc,
> without having to reinit if the user sets them.
Initializing dwrite even though the user said we shouldn't use it
doesn't sound too bad to me. We could provide a function to
reinitialize (if it's needed) and document that it should be called if
the user wants to disable dwrite in the init file. I wouldn't go
farther than this unless we get complaints and discover that
initializing dwrite could cause trouble in some configurations.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Thu, 24 Oct 2024 20:20:02 GMT)
Full text and
rfc822 format available.
Message #82 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
New version attached.
- Added comments
- Use SAFE_ALLOCA instead of alloca.
- Added two lisp functions:
w32-dwrite-available to find out is dwrite is working
w32-dwrite-reinit to reinitialize dwrite, optionally
changing render parameters (gamma, cleartype level, contrast).
Can go back to defaults passing nil.
- Updated NEWS and changelog.
[0001-Implement-drawing-text-with-DirectWrite-on-MS-Window.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Fri, 25 Oct 2024 07:27:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Oct 2024 22:19:06 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> New version attached.
>
> - Added comments
> - Use SAFE_ALLOCA instead of alloca.
> - Added two lisp functions:
> w32-dwrite-available to find out is dwrite is working
> w32-dwrite-reinit to reinitialize dwrite, optionally
> changing render parameters (gamma, cleartype level, contrast).
> Can go back to defaults passing nil.
> - Updated NEWS and changelog.
Thanks, I will review this shortly. Meanwhile, could you please look
at how Emacs with this patch displays some complex Emoji sequences?
Some of them look incorrect to me. For example, this sequence from
admin/unidata/emoji-zwj-sequences.txt:
1F469 200D 1F469 200D 1F467 200D 1F466 ; RGI_Emoji_ZWJ_Sequence ; family: woman, woman, girl, boy # E2.0 [1] (👩👩👧👦)
when displayed using Segoe UI Emoji, is shown with the "boy" part
overlapping the closing parenthesis, which looks incorrect to me.
"C-u C-x =" claims all of the codepoints of the sequence were composed
into a single grapheme cluster, but it doesn't look like that on
display, and the cursor doesn't include the "boy" part.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Fri, 25 Oct 2024 10:19:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 73730 <at> debbugs.gnu.org (full text, mbox):
On 25/10/2024 9:26, Eli Zaretskii wrote:
> Thanks, I will review this shortly. Meanwhile, could you please look
> at how Emacs with this patch displays some complex Emoji sequences?
> Some of them look incorrect to me. For example, this sequence from
> admin/unidata/emoji-zwj-sequences.txt:
>
> 1F469 200D 1F469 200D 1F467 200D 1F466 ; RGI_Emoji_ZWJ_Sequence ; family: woman, woman, girl, boy # E2.0 [1] (👩👩👧👦)
>
> when displayed using Segoe UI Emoji, is shown with the "boy" part
> overlapping the closing parenthesis, which looks incorrect to me.
> "C-u C-x =" claims all of the codepoints of the sequence were composed
> into a single grapheme cluster, but it doesn't look like that on
> display, and the cursor doesn't include the "boy" part.
I dont's see that, but I do see that the individual glyphs are truncated
on the left side, even when removing color rendering. Do you see it? I
will investigate this first, in case the defects are related.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Fri, 25 Oct 2024 11:53:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Cecilio Pardo <cpardo <at> imayhem.com>:
bug acknowledged by developer.
(Fri, 25 Oct 2024 11:53:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 73730-done <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Oct 2024 22:19:06 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> New version attached.
>
> - Added comments
> - Use SAFE_ALLOCA instead of alloca.
> - Added two lisp functions:
> w32-dwrite-available to find out is dwrite is working
> w32-dwrite-reinit to reinitialize dwrite, optionally
> changing render parameters (gamma, cleartype level, contrast).
> Can go back to defaults passing nil.
> - Updated NEWS and changelog.
Thanks, installed on the master branch, and closing the bug.
I also installed minor followup changes:
I removed the eassert from this fragment:
/* IDWriteFactory2 is only available on Windows 8.1 and later.
Without this, we can't use color fonts. So we disable DirectWrite
if it is not available. */
hr = dwrite_factory->lpVtbl->QueryInterface (dwrite_factory,
&IID_IDWriteFactory2,
(void **) &dwrite_factory2);
if (FAILED (hr))
{
DebPrint (("DirectWrite HRESULT failed: (%d) QueryInterface IDWriteFactory2\n", hr));
RELEASE_COM (dwrite_factory);
FreeLibrary (direct_write);
return;
}
That's because otherwise the debug build of Emacs will abort on
Windows 7 and 8.0, which is not what we want.
Also, I've added some information about the default values of the
parameters to the doc string of w32-dwrite-reinit; please see if I
made some mistakes there, as the default values don't seem to be
documented anywhere I could see.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Fri, 25 Oct 2024 12:02:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 25 Oct 2024 12:17:37 +0200
> Cc: 73730 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> On 25/10/2024 9:26, Eli Zaretskii wrote:
>
> > Thanks, I will review this shortly. Meanwhile, could you please look
> > at how Emacs with this patch displays some complex Emoji sequences?
> > Some of them look incorrect to me. For example, this sequence from
> > admin/unidata/emoji-zwj-sequences.txt:
> >
> > 1F469 200D 1F469 200D 1F467 200D 1F466 ; RGI_Emoji_ZWJ_Sequence ; family: woman, woman, girl, boy # E2.0 [1] (👩👩👧👦)
> >
> > when displayed using Segoe UI Emoji, is shown with the "boy" part
> > overlapping the closing parenthesis, which looks incorrect to me.
> > "C-u C-x =" claims all of the codepoints of the sequence were composed
> > into a single grapheme cluster, but it doesn't look like that on
> > display, and the cursor doesn't include the "boy" part.
>
> I dont's see that, but I do see that the individual glyphs are truncated
> on the left side, even when removing color rendering. Do you see
> it?
Yes.
> I will investigate this first, in case the defects are related.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Fri, 25 Oct 2024 13:45:01 GMT)
Full text and
rfc822 format available.
Message #99 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Also, I've added some information about the default values of the
> parameters to the doc string of w32-dwrite-reinit; please see if I
> made some mistakes there, as the default values don't seem to be
> documented anywhere I could see.
LGTM.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sat, 26 Oct 2024 20:15:01 GMT)
Full text and
rfc822 format available.
Message #102 received at 73730 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> Thanks, I will review this shortly. Meanwhile, could you please look
>>> at how Emacs with this patch displays some complex Emoji sequences?
>>> Some of them look incorrect to me. For example, this sequence from
>>> admin/unidata/emoji-zwj-sequences.txt:
>>>
>>> 1F469 200D 1F469 200D 1F467 200D 1F466 ; RGI_Emoji_ZWJ_Sequence ; family: woman, woman, girl, boy # E2.0 [1] (👩👩👧👦)
>>>
>>> when displayed using Segoe UI Emoji, is shown with the "boy" part
>>> overlapping the closing parenthesis, which looks incorrect to me.
>>> "C-u C-x =" claims all of the codepoints of the sequence were composed
>>> into a single grapheme cluster, but it doesn't look like that on
>>> display, and the cursor doesn't include the "boy" part.
>>
>> I dont's see that, but I do see that the individual glyphs are truncated
>> on the left side, even when removing color rendering. Do you see
>> it?
>
> Yes.
>
>> I will investigate this first, in case the defects are related.
This patch fixes the left side glyph truncation, which happens when
glyphs have negative left bearing.
About the problem you reported, I can't reproduce when building for
64bit. It does show when building with mingw32 for 32bit. It also shows
when building version 30.0.92. Maybe is the Harfbuzz version? I have
2.4.0 for this build.
[0001-Fix-problem-with-DirectWrite-MS-Windows.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 27 Oct 2024 06:38:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Oct 2024 22:13:57 +0200
> From: Cecilio Pardo <cpardo <at> imayhem.com>
> Cc: 73730 <at> debbugs.gnu.org
>
> This patch fixes the left side glyph truncation, which happens when
> glyphs have negative left bearing.
Thanks, installed.
> About the problem you reported, I can't reproduce when building for
> 64bit. It does show when building with mingw32 for 32bit. It also shows
> when building version 30.0.92. Maybe is the Harfbuzz version? I have
> 2.4.0 for this build.
Quite possible. I guess I'll have to build a newer HarfBuzz some day
soon (which I tried to avoid, since they dropped support for
Autoconf in favor of fancier build tools).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 27 Oct 2024 13:34:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Cc: 73730 <at> debbugs.gnu.org
> Date: Sun, 27 Oct 2024 08:36:44 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > About the problem you reported, I can't reproduce when building for
> > 64bit. It does show when building with mingw32 for 32bit. It also shows
> > when building version 30.0.92. Maybe is the Harfbuzz version? I have
> > 2.4.0 for this build.
>
> Quite possible. I guess I'll have to build a newer HarfBuzz some day
> soon (which I tried to avoid, since they dropped support for
> Autoconf in favor of fancier build tools).
Could you perhaps try the 32-bit build with the latest win32 binaries
that the HarfBuzz project itself provides from their Releases page?
https://github.com/harfbuzz/harfbuzz/releases
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 27 Oct 2024 13:43:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Could you perhaps try the 32-bit build with the latest win32 binaries
> that the HarfBuzz project itself provides from their Releases page?
>
> https://github.com/harfbuzz/harfbuzz/releases
Ok.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 27 Oct 2024 15:45:02 GMT)
Full text and
rfc822 format available.
Message #114 received at submit <at> debbugs.gnu.org (full text, mbox):
> Could you perhaps try the 32-bit build with the latest win32 binaries
> that the HarfBuzz project itself provides from their Releases page?
>
> https://github.com/harfbuzz/harfbuzz/releases
I replaced libharfbuzz-0.dll with the one from version 10.0.1 (the
latest one) and it just works, with and without DirectWrite, without
rebulding Emacs with the new headers.
Besides the normal build with meson/cmake, I've seen this:
There is also amalgamated source provided with HarfBuzz which reduces
whole process of building HarfBuzz to g++ src/harfbuzz.cc
-fno-exceptions but there is no guarantee provided with buildability
and reliability of features you get.
I will take a look at that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 27 Oct 2024 16:56:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 27 Oct 2024 16:44:13 +0100
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> > Could you perhaps try the 32-bit build with the latest win32 binaries
> > that the HarfBuzz project itself provides from their Releases page?
> >
> > https://github.com/harfbuzz/harfbuzz/releases
>
> I replaced libharfbuzz-0.dll with the one from version 10.0.1 (the
> latest one) and it just works, with and without DirectWrite, without
> rebulding Emacs with the new headers.
And the problems with displaying emoji-zwj-sequences are gone?
It doesn't surprise me that no rebuilding is needed, because the
latest HarfBuzz is still ABI-compatible with the old ones (which is
why the name is still "-0.dll", not a larger number).
> Besides the normal build with meson/cmake, I've seen this:
>
> There is also amalgamated source provided with HarfBuzz which reduces
> whole process of building HarfBuzz to g++ src/harfbuzz.cc
> -fno-exceptions but there is no guarantee provided with buildability
> and reliability of features you get.
Yes, I know, I've seen the suggestion to TeX Live folks to use that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 27 Oct 2024 17:52:01 GMT)
Full text and
rfc822 format available.
Message #120 received at 73730 <at> debbugs.gnu.org (full text, mbox):
On 27/10/2024 17:54, Eli Zaretskii wrote:
>> I replaced libharfbuzz-0.dll with the one from version 10.0.1 (the
>> latest one) and it just works, with and without DirectWrite, without
>> rebulding Emacs with the new headers.
>
> And the problems with displaying emoji-zwj-sequences are gone?
Yes, they show correctly.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 27 Oct 2024 19:19:02 GMT)
Full text and
rfc822 format available.
Message #123 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 27 Oct 2024 18:50:50 +0100
> Cc: 73730 <at> debbugs.gnu.org
> From: Cecilio Pardo <cpardo <at> imayhem.com>
>
> On 27/10/2024 17:54, Eli Zaretskii wrote:
>
> >> I replaced libharfbuzz-0.dll with the one from version 10.0.1 (the
> >> latest one) and it just works, with and without DirectWrite, without
> >> rebulding Emacs with the new headers.
> >
> > And the problems with displaying emoji-zwj-sequences are gone?
>
> Yes, they show correctly.
OK, good to know. Then this mystery can be put to rest.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Tue, 29 Oct 2024 08:58:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 73730 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I've built HarfBuzz with the attached patch with mingw, using
g++ src/harfbuzz.cc --shared -o libharfbuzz-0.dll --no-exceptions
and it seems to work fine.
[0001-harbuzz-mingw.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#73730; Package
emacs.
(Sun, 03 Nov 2024 13:04:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 73730 <at> debbugs.gnu.org (full text, mbox):
> Cc: 73730 <at> debbugs.gnu.org
> Date: Sun, 27 Oct 2024 08:36:44 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > About the problem you reported, I can't reproduce when building for
> > 64bit. It does show when building with mingw32 for 32bit. It also shows
> > when building version 30.0.92. Maybe is the Harfbuzz version? I have
> > 2.4.0 for this build.
>
> Quite possible. I guess I'll have to build a newer HarfBuzz some day
> soon (which I tried to avoid, since they dropped support for
> Autoconf in favor of fancier build tools).
FTR: I built HarfBuzz 8.5.0 (the last release which supports
Autoconf), and the problems with emoji-zwj-sequences.txt are gone with
that version.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 02 Dec 2024 12:24:06 GMT)
Full text and
rfc822 format available.
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.