[Top][All Lists]

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

Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY

From: Infinality
Subject: Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY
Date: Mon, 21 Nov 2011 18:36:22 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

Yes, I think that alternative is totally acceptable (and better, even), and the fontconfig syntax makes a lot more sense than the example I gave.

I'd certainly be willing to figure out the changes needed to make Freetype accommodate this, however this is a new area for me. Based on the link that Werner sent today to quanta's post, it might make sense to ultimately rip out the rendering / rasterizing part of Freetype into its own library. That seems like a larger project though. Making these modifications to Freetype should be (relatively) easy, compared to creating a different library. They could be moved to such a library if/when it gets created.

It seems like Werner is now OK with adding this to Freetype, so I can start proceeding down the path of figuring out how to implement this.


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">

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

(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

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.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

Does that make sense?


reply via email to

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