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.
Thanks,
Erik
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.
_______________________________________________
Freetype-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/freetype-devel
