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

Previous Next

Full log

Message #11 received at 73730 <at> debbugs.gnu.org (full text, mbox):

From: Cecilio Pardo <cpardo <at> imayhem.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73730 <at> debbugs.gnu.org
Subject: Re: bug#73730: 31.0.50; Support for color fonts on MS-Windows
Date: Thu, 10 Oct 2024 17:14:34 +0200

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.

Previous Next

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