> Well, given the fact that Freetype already has filters (LCD filters)
> in it, it made sense to me to allow other arbitrary filters too.
OK.
> Perhaps Freetype isn't the right spot for it, but I don't know where
> else it makes sense to put this at the moment. I think there needs
> to be some sort of intermediate layer, that is controllable by the
> end-user, that all toolkits respect, and whose filters they use,
> instead of implementing their own on top of it. Knowing that's
> unlikely to happen is why I've resorted to putting all this stuff
> into Freetype with my patches. That way I (the end user) can make
> it do what I want!
If you volunteer to handle this, I could imagine the following route:
1. Move the existing filter stuff into a separate module.
2. Move the existing rendering modes into a separate module.
3. Add an API for 1. and 2.
4. Add new filters and rendering modes.
What do you think?
Werner
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
