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

[Eli Zaretskii]

> Date: Thu, 10 Oct 2024 17:14:34 +0200
> Cc: 73730@debbugs.gnu.org
> From: Cecilio Pardo <cpardo@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?