[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Turning off stem darkening by default until all drivers s
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] Turning off stem darkening by default until all drivers support it? |
Date: |
Thu, 14 Jan 2016 12:29:53 +0100 (CET) |
>> I would model my stem darkening property after your proposal.
>
> Werner has to make the call.
What about the following model, which tries to harmonize the various
suggestions.
. In `FT_Library', we have default properties, to be set with
functions like `FT_Set_Property' or `FT_Library_SetLcdFilter'.
. `FT_Face' objects inherit the default properties at creation time
from its parent `FT_Library' object. A new set of functions like
`FT_Face_Set_Property' or `FT_Face_SetLcdFilter' override the
properties locally.
After some thinking I still believe that many properties belong to
FT_Library; for example, a web browser doesn't need various LCD
rendering modes in different tabs, say. However, it's not the job of
FreeType to enforce this.
The next step IMHO should be to have stem darkening control within
`FT_Library', for the sake of simplicity and orthogonality. A
separate, later action would be the addition of local properties to
`FT_Face', together with the necessary functions.
> 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.
I don't understand your reasoning. FontConfig, for example, doesn't
provide an `FT_Library' object to a client that queries font
information, AFAIK. An application has to call `FT_Init_FreeType' by
itself, then deriving all `FT_Face' objects from the just created
`FT_Library' object. Ditto for Qt (where a call to `FT_Init_FreeType'
is hidden by an application's Qt initialization). How can this be
thread-unsafe? What am I missing? Please provide a real-world
example that helps me understand your concerns.
Werner