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.