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 <[email protected]> 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: <[email protected]> To: [email protected] Subject: Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY From: Werner LEMBERG <[email protected]> > 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: <CA+zRj8Xu2ukO0gYP49rMmW8X79qZwqTLDmZp4r=tsjj-kjp...@mail.gmail.com> Subject: Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY From: Eric Rannaud <[email protected]> To: Werner LEMBERG <[email protected]> On Mon, Nov 21, 2011 at 3:01 PM, Werner LEMBERG <[email protected]> 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 _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
