cairo behaves inconsistently on hintstyle and rgba settings. If specified in fonts.conf something like this: <edit name="rgba" mode="assign" ><const>rgb</const><edit> <edit name="hintstyle" mode="assign" ><const>hintfull</const></edit> cairo would respond to rgba but not to hintstyle; hintstyle can only be set via gtk( through gnome-settings-daemon). Although i don't know how to code, but after looking at the code (several times), i commented this out in cairo-ft-font.c (in function _cairo_ft_options_merge): if (options->base.hint_style == CAIRO_HINT_STYLE_DEFAULT) and everything goes fine. Is this the right solution?
Recently I've found a better fix. Set default hintstyle to "CAIRO_HINT_STYLE_DEFAULT"(which is new), and in the function _cairo_ft_options_merge, change if (options->base.hint_style == CAIRO_HINT_STYLE_DEFAULT) options->base.hint_style = other->base.hint_style; to if (other->base.hint_style != CAIRO_HINT_STYLE_DEFAULT) options->base.hint_style = other->base.hint_style; This should give fair result, i.e., only if hintstyle is specified with fontconfig would the value configured with gnome-settings-daemon be overriden.
The rgba behavior is actually more complicated: With "echo Xft.rgba: rgb | xrdb -merge" and <edit name="rgba" mode="assign" ><const>none</const></edit>, "pango-view -t 'fcgray antialias' --backend=cairo" renders with rgb subpixel antialiasing. "--backend=ft2" and "--backend=xft" render with gray antialiasing as expected. _cairo_ft_options_merge has some complex logic to decide which options on the scaled_font or on the cairo_ft_font_face (from the FcPattern) take priority in the way the font behaves. Assuming that surface options have already been set on the FcPattern with cairo_ft_font_options_substitute, it is not clear to me why options on the scaled_font should ever take priority over those from the pattern. If fontconfig has changed any options on the pattern then that is what the user (or distribution) wants. Is the logic in _cairo_ft_options_merge meant to protect against broken fontconfig settings? Some surfaces may be pretty keen to have CAIRO_HINT_STYLE_NONE. Also, maybe surfaces with depth 1 would like CAIRO_ANTIALIAS_NONE and gray surfaces don't need rgba antialiasing, but maybe changing the load flags based on the color support of the surface would produce some surprises with glyph outline changes. I wouldn't really see a problem with fontconfig settings always having the last say (bug 4792 comment 5). fontconfig settings should be able to achieve their goals without unconditionally setting hinting to true (as true is the default). Even if there are some special cases where surface options should take priority, I can't think why the surface should care what hintstyle is used once hinting is on. Similarly, I can't think why a color surface should care if the user asks for gray antialiasing on a font that doesn't hint well to reduce color fringing. I wonder whether a cairo_ft_scaled_font_create_for_pattern or cairo_font_options_merge_from_pattern API might be good so that the scaled_font can be created with the font_options that will be used, which would be useful in _cairo_scaled_font_keys_equal. But merely modifying _cairo_ft_options_merge could enable fontconfig settings even with the existing API.
I know I've been surprised by the logic in _cairo_ft_options_merge() before, but decided not to change it without fully understanding it. I'll look into this after 1.8. Feel free to ping.
*** Bug 13335 has been marked as a duplicate of this bug. ***
*** Bug 4792 has been marked as a duplicate of this bug. ***
I don't understand why this bug exists such a long time - it's obvious and important. You can't specify different hintstyles for individual fonts through fontconfig - gnome-settings-daemon override all your settings and only one hintstyle for all fonts. This is the main reason I choose KDE: libxft doesn't have this bug.
Created attachment 23125 [details] [review] patch for cairo-ft-font.c This bug still exists in Debian sid (libcairo2=1.8.6-2). This simple patch shall fix it, at least it works for me.
Created attachment 34511 [details] [review] cairo-respect-fontconfig.patch (In reply to comment #3) > I'll look into this after 1.8. Feel free to ping. Ping! I've used the enclosed cairo-respect-fontconfig.patch in Gentoo, Fedora, Arch Linux and Lunar Linux. And so have others. It is needed, so as not to partially ignore fontconfig's configuration files. Further info is in this post within Gentoo's huge fonts thread: http://forums.gentoo.org/viewtopic-t-723341-postdays-0-postorder-asc-start-258.html
Hi, this is an annoying bug, any chance for the patch above to be included in cairo? It solves the problem for me.
Bug still there (1.8.10) and cairo-respect-fontconfig.patch still works... Simple fix, waiting far too long to be fixed in codebase. I did some digging and condition (options->base.hint_style == CAIRO_HINT_STYLE_DEFAULT) would be only true if Xft.hintstyle had a unrecognized value, for instance 5. Empty value will falls back to CAIRO_HINT_STYLE_FULL.
Created attachment 37489 [details] [review] The complete patch for respecing Fontconfig in Cairo. Hintstyle / RGBA / LCDFilter are supported now. The routines dealing with data returned by Fontconfig have been rewritten to support all properties. The logic is simple - if anything is returned by Fontconfig, it will be respected. If not, the xrdb/Xft settings are used.
(In reply to comment #11) > Created an attachment (id=37489) [details] > The complete patch for respecing Fontconfig in Cairo. Hintstyle / RGBA / > LCDFilter are supported now. > > The routines dealing with data returned by Fontconfig have been rewritten to > support all properties. The logic is simple - if anything is returned by > Fontconfig, it will be respected. If not, the xrdb/Xft settings are used. Quick comments: 1. No unnecessary whitespace changes please. 2. No C++-style comments please. 3. If you can, break down the patch into bite-size chunks such that I can review the behvaior change instead of blanket-approving it. Thanks
Please excuse me if this is not the best place to bring this topic, but what exactly is the point of supporting all these Xft.<option> xresources? Maybe I'm a bit uniformed but this stuff is broken by design anyway (hence fontconfig). I mean, toolkits and whatnot shouldn't give a f..k about those options because all they should care about is fontconfig. Setting some Xft.<foo> is global (is terms of fonts) and this is what makes it almost totally useless. Everyone who digs fonts knows that you can't get all your fonts right just by setting some global options. Most good quality fonts (mostly from professional font foundries, but not only) require "tweaks" in hintstyle etc. to look good (in other words - they only look good with e.g. hintstyle=hintslight). If you set Xft.hintstyle to hintmedium, you get one group of fonts properly shaped and in the same time some other group of fonts to look suboptimal or unacceptable. [This is also a good place to point out that approach taken by tools like gnome-appearance-properties (which tries to screw^Wsave the world by playing with Xft xresources/xsettings via gnome-settings-daemon) is blatantly naive, except if you're blind or just used to bad looking screen fonts.] "But these are just Xft defaults and we should obey them" you may say. Yeah, but dealing with those legacy options brings SO MUCH CONFUSION and bizarre bugs I lack words to describe it. Every toolkit/app and their dog tries to do something with them and almost always fails to do it right (perhaps because it's impossible to do so). Let's take emacs for an example. Emacs can use gtk2 and fontconfig, but not cairo. It pretty much succeeds but what's striking is that it basically fucks up FcPatterns by modifying them with stuff from Xft xresources. After getting them from fontconfig, so any carefully crafted (font/pattern-specific or not) fontconfig configuration gets ignored. It'll screw it even if Xft.<foo> stuff isn't set. It's a disaster. Qt, OpenOffice, Java runtime... ugh. *Even cairo can't get its shit together.* The bottom line is: why not use fontconfig for everything, so app/toolkit developers won't do stupid things like the mentioned above? Freetype is pretty capable of providing good results, but bugs like this simply prevent demanding users from making use of it. Also, If you don't believe this stuff, just google around, see how users are struggling in confusion. Sorry for the style of this comment. I couldn't help myself. My English is so poor I can only rant ;)
(In reply to comment #13) > The bottom line is: why not use fontconfig for everything, Fontconfig doesn't know whether the text is being rendered to an LCD screen or a printer, so fontconfig needs to be told subpixel order and whether hinting is appropriate. Problems happen when fontconfig rules blindly override such information (bug 17722, https://bugs.kde.org/show_bug.cgi?id=105797), as well as when apps/toolkits blindly override fontconfig patterns (this bug).
(In reply to comment #14) > Fontconfig doesn't know whether the text is being rendered to an LCD screen or > a printer, so fontconfig needs to be told subpixel order and whether hinting is > appropriate. I admit I don't know how printing specific rendering is being done. Is it that antialiasing and hinting are turned off because printer resolution is much higher than screen and it wouldn't make sense to leave them on? (no visible effect?) > Problems happen when fontconfig rules blindly override such information (bug > 17722 Sorry for discussing bug 17722 here, but how come that rules in 10-sub-pixel-*.conf can override anything? Isn't it how defaults supposed to be set, giving that "50-user.conf" can override it later and any "low-level" fontconfig user can do the same if needed? (and virtually all Xft.rgba touching stuff does it anyway? Or doesn't? Or is xrm/fc priority issue? See? This should be nuked.)
Created attachment 42713 [details] [review] Revised version of respect-fontconfig patch against 1.10.2 version. I am sending the updated patch, with comments from Behdad Esfahbod incorporated. There are two routines modified with this patch: * _cairo_ft_options_merge - changes here are small and focus on having the same algorithm for all font properties: if other structure define a property (it does not equal CAIRO_*_DEFAULT), this value will be used. Sometimes there is some additional processing for antialiasing required - in case the subpixel antialiasing is forced on, but physical screen structure is unknown, the type of antialiasing (Subpixel/Gray) has to be calculated based on values in options structure. * _get_pattern_ft_options - this routine loads FontConfig information into cairo_ft_options_t structure. ** The most significant change here covers the fact, that hinting information wasn't processed if antialiasing was switched off. ** Another change in behavior applies to antialiasing information - basically there are 7 different combination of FontConfig properties ('antialias' and 'rgba') values that define different behavior, but they cannot be naturally represented in cairo_ft_options_t structure (in theory it could be done, but with extremely nasty approach). As changing the contract and defining additional value for _cairo_subpixel_order type would be rather wrong idea, the routine will assume user wanted to switch on antialiasing when the 'rgba' property is defined.
Created attachment 42714 [details] Revised version of respect-fontconfig patch against 1.10.2 version - for easy reading Just modified methods - for easy reading...
One year passes. Is there anything stopping this patch merged to the main line?
Karl, do you think you would have the time to review the patch?
(In reply to comment #15) > (In reply to comment #14) > > Fontconfig doesn't know whether the text is being rendered to an LCD screen or > > a printer, so fontconfig needs to be told subpixel order and whether hinting is > > appropriate. > > I admit I don't know how printing specific rendering is being done. Is it that > antialiasing and hinting are turned off because printer resolution is much > higher than screen and it wouldn't make sense to leave them on? (no visible > effect?) Not just that the printer resolution is higher, but the resolution may not even be known at the time of generating the PDF or PS output.
Comment on attachment 42713 [details] [review] Revised version of respect-fontconfig patch against 1.10.2 version. Review of attachment 42713 [details] [review]: ----------------------------------------------------------------- (In reply to comment #16) Thanks for the helpful overview of the changes. > * _cairo_ft_options_merge - changes here are small and focus on having the same > algorithm for all font properties: if other structure define a property (it > does not equal CAIRO_*_DEFAULT), this value will be used. I'd like to agree in principle, but we need at least one exception to this rule. If FT_LOAD_NO_HINTING is not set, but hint_metrics is CAIRO_HINT_METRICS_OFF, x_advance/y_advance metrics will not be hinted, but x/y_bearing/width/height metrics and outlines will still be hinted. https://bugzilla.mozilla.org/show_bug.cgi?id=490475#c5 says "cairo PDF/PS always embeds (and subsets) the fonts used. If subsetting fails it will fallback to embedding a font generated from the unhinted outlines of the glyphs." And https://bugzilla.mozilla.org/show_bug.cgi?id=490475#c19 says "Hintstyle should also be set to none for printing although this only affects the use of fallback fonts where cairo embeds a font created from the glyph outlines." That means that a HINT_STYLE_NONE on the surface will need to override fontconfig. I guess we could argue that users shouldn't have fontconfig settings that turn on hinting if it has been turned off, but history has shown that people will use fontconfig to turn on hinting, overriding an explicitly set value in the pattern. There are also times when the font_options should be able to override the cairo antialias option from fontconfig. This would be beneficial if the destination surface is monochrome or grayscale and so doesn't support the same antialiasing options, or if the destination is a translucent part of a CONTENT_COLOR_ALPHA surface and so component-alpha will be lost before the glyphs are composited onto an opaque background (leading to excessive color fringing). I think what we want for cairo antialias is not a priority of fontconfig over other interests, but the greatest common method among those supported and desired. The current code doesn't provide this exception, however. > * _get_pattern_ft_options - this routine loads FontConfig information into > cairo_ft_options_t structure. > > ** The most significant change here covers the fact, that hinting information > wasn't processed if antialiasing was switched off. Yes, processing hinting and hintstyle to determine whether to hint seems the right thing to do (even if I don't know of a good reason, apart from testing perhaps, why anyone would want to turn off hinting through fontconfig if antialias has been set to false). > ** Another change in behavior applies to antialiasing information - basically > there are 7 different combination of FontConfig properties ('antialias' and > 'rgba') values that define different behavior, but they cannot be naturally > represented in cairo_ft_options_t structure (in theory it could be done, but > with extremely nasty approach). As changing the contract and defining > additional value for _cairo_subpixel_order type would be rather wrong idea, the > routine will assume user wanted to switch on antialiasing when the 'rgba' > property is defined. There is an awkwardness in the mapping from fontconfig's rgba to cairo's subpixel_order and antialias. It looks like the current _get_pattern_ft_options code is not achieving the desired result here because there is no SUBPIXEL_ORDER_NONE and it doesn't change antialias from DEFAULT to GRAY for FC_RGBA_NONE, and so it won't override a surface default ANTIALIAS_SUBPIXEL. A SUBPIXEL_ORDER_NONE would be worth considering as there are device surfaces that are not linear arrays of RGB colors. The patch also sets ANTIALIAS_SUBPIXEL if the pattern has antialias == true but FC_RGBA_UNKNOWN or missing. I'm cautious about the benefit of this change as antialiasing would be the default in _cairo_ft_options_merge anyway. I guess this is so that someone can have antialias turned off on the screen settings but enable it through fontconfig only for certain fonts. However, this would turn on grayscale aa for surfaces with ANTIALIAS_NONE, and perhaps even subpixel aa for surfaces with antialias GRAY or NONE, if the subpixel_order has not been cleared out. Those could both be less than ideal. Clients would not expect to have to clear out the subpixel order because the documentation says subpixel order is only used "when rendering with an antialiasing mode of CAIRO_ANTIALIAS_SUBPIXEL." These issues already can happen when fontconfig has rgba set, but I fear this part of the patch would not move things in the right direction. The Fc prefix indicates a fontconfig symbol but FcUndefined is not a fontconfig symbol. Perhaps it would be better/clearer to just use -1, though assigning a non-true/false value to FcBool doesn't feel quite right, even if it really is just an int. It looks like we may not need a special value at all if the antialias=true/rgba=unknown case is removed.
This bug is still present. Any hope to see it fixed someday? I suppose that using Wayland this bug should vanish. Am I right?
Created attachment 109191 [details] GIMP font rendering https://bugzilla.gnome.org/show_bug.cgi?id=657047 refers to this bug. The referring bug is about black border around text rendered with Cairo with non-black color, antialiasing turned on and hinting set to "medium".
Created attachment 111193 [details] [review] Respect fontconfig's hintstyle I am currently using the attached minimal patch to make cairo respect fontconfig's hintstyle; it will probably need to be adapted for the other parameters.
Karl, would you have time to finish the patch for this? That would be really appreciated. Thanks.
Any news on this?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/23.
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.