Comment 53 for bug 164640

I discussed this issue with Keith the other day:

17:48 < syp|> keithp: what do you think about https://bugs.freedesktop.org/show_bug.cgi?id=13566 ?
17:49 < keithp> syp|: fontconfig doesn't need these values, but cairo can add them itself if desired
17:50 < keithp> fontconfig allows applications to add their own variables to fontconfig
17:51 < keithp> you can do precisely the same operation from cairo code
17:51 < keithp> just add the values and constants using the existing public fontconfig API
17:51 < keithp> then fontconfig will happily parse those values appropriately
17:52 < syp|> keithp: is this way of doing already used for other configuration options?
17:53 < keithp> syp|: not in cairo, but I think Xft may use this
17:53 < keithp> yeah, FcNameRegisterConstants, FcNameRegisterObjectTypes
17:55 < syp|> ok thanks for the information. so this particular bug should be WONTFIXed?
17:57 < keithp> please see if you can make it work from cairo, then we can close the bug

So I tried to use the FcNameRegisterConstants and FcNameRegisterObjectTypes functions to register the lcdfilter object type and the lcdfilter* constants. However, I could see a time dependency issue when doing this:

FcNameRegisterConstants() has to be called before the fontconfig configuration file is read, otherwise the parser is not aware of the defined constants and do not fill the pattern with them.

This can work when using the toy API and registering the constants from _cairo_ft_scaled_font_create_toy(), because the fontconfig configuration file is parsed later when FcDefaultSubstitute() is called (so it knows about the constants at this time).

But it fails when using Pango, because it deals with FontConfig before calling into the cairo API, so that the fontconfig configuration is already parsed when we are in cairo-ft-font.c