Re: [ft-devel] [RFC] FT_LCD_FILTER_HEAVY

[Eric Rannaud]

On Mon, Nov 21, 2011 at 4:36 PM, Infinality <address@hidden> wrote:
> 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'll ask the fontconfig ML what they think of this, and if they OK it,
I'll send you the fontconfig patch as I work on it.

The question here is how to pass an arbitrary set of parameters to
freetype from fontconfig. I'm not sure what will be the most natural
on the fontconfig side (they already support a number of "complex"
configuration value types, such as a 2x2 matrix). I'm thinking that
for simplicity we may want to restrict "module" configuration to
polymorphic lists, not trees. Anyway, I'll ask the fontconfig people
for advice.


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

I'm certainly no expert in that area, but I know of users of freetype
(think small embedded) that would likely not want to have a new
library dependency to get AA rendering. However, it certainly makes
sense to modularize this part of freetype, but maybe it should still
belong to freetype (the project), even if it designed in modules that
can be loaded/unloaded at runtime (for instance).