Attached patch is from openSUSE Build. Author: Mike Fabian This patch makes the rendering settings from gnome-font-properties work. For example in case of the antialias option: Without the patch, cairo will add the antialias option to the fontconfig pattern only if it is not already there. But the option might already be in the pattern because a fontconfig setup file in /etc/fonts or ~/.fonts.conf adds it ot the pattern. With the patch, cairo first deletes the antialias option from the pattern unconditionally, then adds its own value of this option. Same for the other options like rgba, hinting, and hintstyle. When doing it like this, the settings in gnome-font-properties are preferred over any rules like <match target="pattern"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="hintstyle"> <const>hintfull</const> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> in a fontconfig setup file. I.e. such rules will then only set a default if nothing is set in gnome-font-properties or if a desktop different from gnome is used. If there are rules like <match target="font"> <edit name="autohint"> <bool>true</bool> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> in a fontconfig setup file which match on "font" instead of "pattern", these rules will stil win over the settings in gnome-font-properties. Therefore, the default systemwide fontconfig setup in /etc/fonts should avoid using rules matching on "font" for setting options which can also be changed in gnome-font-properties. Reference: https://bugzilla.novell.com/show_bug.cgi?id=104365
*** Bug 10414 has been marked as a duplicate of this bug. ***
*** Bug 10415 has been marked as a duplicate of this bug. ***
Created attachment 9305 [details] [review] cairo-freetype.patch
My quick response here is that this patch seems wrong to me. It makes it impossible to configure font-specific options in via fonts.conf, which some people seem to want to be able to do. Configuration of system-wide defaults can be done via X resources - the approach we took for Red Hat Linux and Fedora. (cairo still reads the Xft.* X resources)
Owen Taylor> It makes it impossible to configure font-specific Owen Taylor> options in via fonts.conf, which some people seem Owen Taylor> to want to be able to do. No, font-specific options match on font not on pattern and therefore they are not affected at all by this patch. I.e. something like <match target="font"> <test name="family"> <string>Arial</string> </test> <edit name="antialias"> <bool>false</bool> </edit> </match> still works with this patch.
I defer to others on decisions like this, but long ago I did raise the issue (on the cairo mailing list) of which settings get the priority when various things come into play, (cairo_set_font_options vs. things in configuration files, etc.). The consensus that came from that discussion, (and put forth by Keith Packard), is a policy that the user should be allowed to override anything that a program does. And the suggested mechanism for implementing that policy is that settings in the configuration file should take precedence over other settings within the application. Again, I'm not an expert in any of this, but the patch appears to be violating that mechanism, (providing functionality to override the configuration file), but as a means to meet the same policy, (allowing user-specified settings in the preference dialog to be forced over anything else). So perhaps there's an alternate way to achieve what you want. I'd still love to see someone document a prioritized list of the various places that fonts settings can come from. Otherwise, I fear we're in danger of implementing oscillating behaviors here. -Carl
I tend to agree with the functional goal of this patch, but the patch itself is definitely wrong, as it changes the documented semantics of a public function. So it's a no no for now. I'll defer more discussion to when David's cairo-ft rewrite thread.
I'm probably just missing something, but I don't see why that patch would differently affect type="font" or type="pattern" ... FcFontRenderPrepare is called on the pattern before the pattern is ever passed to cairo.
(In reply to comment #8) > I'm probably just missing something, but I don't see why that patch would > differently affect type="font" or type="pattern" ... FcFontRenderPrepare > is called on the pattern before the pattern is ever passed to cairo. The patch affects cairo_ft_font_options_substitute(), which is called after FcConfigSubstitute() but before FcDefaultSubstitute() and FcFontRenderPrepare().
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.