Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

[Behdad Esfahbod]

On 15-12-15 05:08 PM, Werner LEMBERG wrote:
> 
>>> A new function operating on FT_Library, as Jan suggests, is the way
>>> to go, I think, cf. `FT_Library_SetLcdFilter'.
>>
>> I recommend against that, as it makes the FT_Library non-threadsafe.
>> I hvae plans to replace SetLcdFilter with bits in the load_flags to
>> make FT_Library fully threadsafe eventually.
> 
> Hmm.  It's not clear to me what you want.  Where should metadata be
> stored?  With `metadata' I mean stuff that acts globally on many
> faces.

How is that different from, say, other hinting settings?  I don't see any
distinction.  To you and your model of the world, these might "act globally on
many faces".  To a fontconfig-using-, or cairo, or Chrome, or Firefox, or
Skia, or Android, or Qt, or any other large-enough platform, there's no global
setting, there's just per-face configuration that needs to be enabled.  If you
push that to FT_Library, that makes FT_Library thread-unsafe and bound to one
face at a time.


>  Or do you want to get rid of metadata altogether, this is,
> moving the global properties in FT_Library to private data in FT_Face?
> This would be a major change in FreeType

It's not.  To you, there might be a lot of things in FT_Library.  To the user
of FreeType, none of them are relevant.  A user of FreeType only cares about
FT_Face objects.  The only piece of FT_Library, so far, used by major clients,
is the SetLcdFilter API.

All the module, and service, and property API, those are things the user
doesn't care about.  They don't render fonts.  FT_Face does.


>, and I'm not sure that this
> would be a wise decision, since it would make FT_Face larger.  We
> would also need a new API for handling FT_Face properties.

This goes back to the original discussion around whether we need runtime
properties at all :).


> Note that load_flags is the wrong place for setting the LCD filter
> IMHO.

Why?  How is that different from other load flags that control aspects of
rasterization?

>  Additionally, we are slowly running out of available bits in
> load_flags...

Sure, that's a tangible problem we can discuss.

Cheers,
behdad

> 
>     Werner
> 

-- 
behdad
http://behdad.org/