Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY

[Eric Rannaud]

My apologies, this part of the thread didn't make it to the list.
Appending Werner's reply and my reply to him.

----
On the fontconfig ML, they suggest passing filter parameters in this way:

 <match target="font">
  <edit mode="assign" name="lcdfilter">
    <const>lcdcustom</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="lcdfiltercustom">
    <double>.0625</double>
    <double>.25</double>
    <double>.4375</double>
    <double>.25</double>
    <double>.0625</double>
  </edit>
 </match>

On Mon, Nov 21, 2011 at 12:03 PM, Werner LEMBERG <address@hidden> wrote:
>> I'm not sure how the details would work (or IF it would work), but I
>> think the best thing would be to add an arbitrary "filter" option
>> where a string name and a signed int (or float?) value can be passed
>> to fontconfig, and it will make a call to freetype using those.
>
> Sounds sensible, but...
>
>> That way, new filters and features (like brightness, contrast,
>> gamma, sharpening, etc.) could be added to Freetype without
>> requiring a change to fontconfig code (just fontconfig configuration
>> files).
>
> ... how much of these features must reside within FreeType?  I really
> would like to *not* have that stuff at all!
>
> Cf. this thread:
>
>  http://lists.gnu.org/archive/html/freetype/2011-09/msg00018.html
>
> Ideally, the ideas laid out in this message should be handled
> similarly, this, using hooks and/or separate modules, probably even in
> a separate library.

We could have fontconfig options that would be specified for
individual freetype modules. Something like:

<match target="font">
 <edit mode="append" name="renderer">
   <option name="lcdfilter">
     <double>0.125</double>
     <double>0.125</double>
     <double>0.125</double>
     <double>0.125</double>
     <double>0.125</double>
   </option>
 </edit>
</match>

<match target="font">
 <edit mode="append" name="renderer">
   <option name="gamma">
     <double>1.4</double>
   </option>
 </edit>
</match>

(From freetype's point of view, "lcdfilter", "gamma" could be
registered internally as some sort of module with configuration
callbacks accepting the options specified above.)

Then fontconfig users (e.g. Cairo) would retrieve a data structure
encoding the module name and options, and pass it directly to
freetype.

The problem, however, is that fontconfig is supposed to validate that
options are well-formed. Right now they use a DTD. While it is
possible to write a DTD that would accept arbitrary XML fragments as
module option values, the end user could still specify an invalid set
of parameters, and freetype would have to reject it. This raises
issues of error reporting, and recovery.

So, while the goal of having fontconfig accept arbitrary options and
have them passed to freetype directly is laudable, because new options
could be added without changing either fontconfig or Cairo/Xft/Qt, I'm
not sure it's in the spirit of what fontconfig is trying to achieve.

However, there is an alternative that gets you most of the way there.
Make fontconfig aware of each new module option, so that fontconfig
can validate it (at least basic things like data type and number of
parameters), but users of fontconfig would still pass the
configuration directly to freetype without interpretation.

Cairo/Xft would do something like:

   for option in FC_renderer_options:
       FT_set_module_config(option.name, option.value)

In other words, when a gamma option is added to freetype, the
fontconfig DTD would be updated but the fontconfig library would not
need to be recompiled, while Cairo/Xft would not need any change at
all.

Does that make sense?

Eric.


----
Date: Tue, 22 Nov 2011 00:01:54 +0100 (CET)
Message-Id: <address@hidden>
To: address@hidden
Subject: Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY
From: Werner LEMBERG <address@hidden>

> However, there is an alternative that gets you most of the way
> there.  Make fontconfig aware of each new module option, so that
> fontconfig can validate it (at least basic things like data type and
> number of parameters), but users of fontconfig would still pass the
> configuration directly to freetype without interpretation.
>
> Cairo/Xft would do something like:
>
>     for option in FC_renderer_options:
>         FT_set_module_config(option.name, option.value)
>
> In other words, when a gamma option is added to freetype, the
> fontconfig DTD would be updated but the fontconfig library would not
> need to be recompiled, while Cairo/Xft would not need any change at
> all.

It should be straightforward to add an API to FreeType which returns
information about a module's available options.  I don't dare to
suggest something here because my knowledge is too limited.


    Werner


----
Date: Mon, 21 Nov 2011 16:01:21 -0800
Message-ID: <address@hidden>
Subject: Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY
From: Eric Rannaud <address@hidden>
To: Werner LEMBERG <address@hidden>

On Mon, Nov 21, 2011 at 3:01 PM, Werner LEMBERG <address@hidden> wrote:
>> In other words, when a gamma option is added to freetype, the
>> fontconfig DTD would be updated but the fontconfig library would not
>> need to be recompiled, while Cairo/Xft would not need any change at
>> all.
>
> It should be straightforward to add an API to FreeType which returns
> information about a module's available options. =A0I don't dare to
> suggest something here because my knowledge is too limited.

If I understand correctly, fontconfig doesn't really assume anything
about the renderer the options will ultimately be passed to, right?
That is, when fontconfig parses its configuration, it doesn't know to
query freetype yet, as the fontconfig-using application could
potentially rely on something other than freetype. I may be
exaggerating the extent to which fontconfig intends to be
renderer-agnostic though.

So fontconfig users such as Cairo and Xft would have to query freetype
and validate the options returned by fontconfig, in a codepath that is
not generally expected to fail, which could force them to rework their
code quite a bit.

Eric