freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Something in 2.6.4 broke my windows


From: Behdad Esfahbod
Subject: Re: [ft-devel] Something in 2.6.4 broke my windows
Date: Fri, 8 Jul 2016 00:49:17 -0700

On Thu, Jul 7, 2016 at 9:46 PM, Werner LEMBERG <address@hidden> wrote:
>
>>> If I may chime in: fontconfig does indeed specify rendering
>>> options.  Werner is right that fontconfig itself does not prepare
>>> the FT_Face or rendering, and that is a problem, because our means
>>> adding any new config options to fontconfig requires updating all
>>> clients.  But fundamentally I think it makes sense adding
>>> "ft-parameters" to fontconfig, the same way that lcd filter is set
>>> for example.
>
> Yes, probably.  An advantage of using `FREETYPE_PROPERTIES', however,
> is that *all* calls to `FT_Open_Face' on the OS are affected – even
> the most simple programs that don't know what fontconfig actually is.
>
>> I'm not sure if it is/was a good way to have, because it sometimes
>> confuses it could applies per fonts/FT_Face, despite it is applicable
>> per FT_Library. maybe fontconfig should improve something to have a
>> global parameter rather than providing them as in FcPattern.
>
> Here Behdad's and my view differs, I guess: He would argue that
> everything should be handled per face (implying changes in FreeType to
> make that happen), while I have the same point of view as you have,
> namely separating global (FT_Library) and local (FT_Face) options.

I don't have any stake in this personally.  I use whatever config my
desktop comes with.  But hyper-customizers exist, and exist loudly,
and for any freetype parameter I've heard of, I can imagine someone
wanting to tweak it on a per-face basis.

My personal interest in this comes more from a library design point of
view.  For a library, it's not desirable to have global or
per-big-library-object settings.  It is more desirable that each
operation can set it's own preferences.  When threadsafety is not an
issue, the whole point is moot since clients can set all properties
every time they need to use the library, but in general, the less
state the "global" library object holds, the easier it is to use the
library.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]