some ~/.fonts.conf settings do no override desktop-wide gnome settings (hinting style)

Bug #161058 reported by puntium on 2007-11-08
56
This bug affects 5 people
Affects Status Importance Assigned to Milestone
cairo
Confirmed
Low
cairo (Ubuntu)
Undecided
Unassigned

Bug Description

I didn't fill out the package field, since this seems to be an interaction between multiple packages (gnome-setting-daemon, libgtk, libcairo, pango/cairo).

In the 'Appearance' control app, under the font settings, I like to use 'Subpixel' and 'Full' hinting by default, since this looks good for most bundled fonts.

However, there is occasionally a font (especially in the msttcorefonts package) that doesn't look good with these settings. So I want to override their rendering settings using .fonts.conf. My main tactic is to usually turn on the autohinter in 'hintslight' mode for certain fonts. Lets take Times new Roman as an example.. the .fonts.conf incantation to do this would be:

 <match target="font">
         <test name="family" qual="any">
                 <string>Times New Roman</string>
         </test>
    <edit name="autohint"> <bool>true</bool></edit>
    <edit name="hinting"> <bool>true</bool></edit>
    <edit name="hintstyle" > <const>hintslight</const> </edit>
 </match>

The odd thing about this is that the 'autohint' and 'hinting' edits seem to work, but the 'hintstyle' edit is always overridden by the control applet's settings. I can verify this by launching gedit each time after tweaking these settings.

"fc-match -v 'Times New Roman'" does return the right settings, so its something in the chain of gtk libraries that is messing it up.

Interstingly, it's not all possible edit settings that are ignored. It seems to only be hintstyle. For example if I were to say:

 <match target="font">
         <test name="family" qual="any">
                 <string>Times New Roman</string>
         </test>
    <edit name="antialias"> <bool> false </bool> </edit>
 </match>

Then this works correctly. Only Times New Roman will be non-antialiased even in gedit. Even setting "hinting" to "false" works.. its only the hintstyle setting that doesn't work.
[lspci]
00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge [8086:7190] (rev 01)
     Subsystem: VMware Inc Device [15ad:1976]
00:0f.0 VGA compatible controller [0300]: VMware Inc Abstract SVGA II Adapter [15ad:0405]
     Subsystem: VMware Inc Abstract SVGA II Adapter [15ad:0405]

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?

Tobias Wolf (towolf) wrote :

How about cross-checking with KDE or something similar?

Mingming Ren (portis25) wrote :

I have reported a same bug in libcairo Bug #209256, but no response.

I'd like to render my fonts in different hintstyles.

To be precise, I have chinese font and western language fonts. For the chinese font, I'd like it to be rendered in hintfull, but for other fonts, I'd prefer hintslight.

Ok, I configured in the fontconfig file, but it didn't make any change. All the fonts are in the same hintstyle, depending on the configuration in gnome-appearance-properties.

I googled for quite a long time and finally I got one solution.

In the file cairo-ft-font.c, in function _cairo_ft_options_merge, just comment the following line:

// if (options->base.hint_style == CAIRO_HINT_STYLE_DEFAULT)

and recompile, now everything works fine. The fonts are rendered according to the hintstyles configured in fontconfig.

I don't know if this is really a bug of libcairo. If I'm wrong, please accept my apology.

puntium (puntium) wrote :

Tobias, what do you mean by cross checking with KDE? Qt's interaction with fontconfig and freetype is entirely different, and I don't really really think relevant to this discussion. I don't use KDE.

Mingming, thanks for the interesting comment. If you apply this change, and you _don't_ specify a setting for a font in .fonts.conf, then does it get the setting in gnome-appearance-properties?

The behaviour should be that gnome-appearance-properties specifies the default, and then users can use .fonts.conf to override this setting for particular fonts.

Mingming Ren (portis25) wrote :

puntium,

I remove .fonts.conf, and it gets the setting in gnome-appearance-properties.

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.

Ian Weisser (ian-weisser) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

puntium (puntium) wrote :

Yes it's still there in 8.04.

*** Bug 13335 has been marked as a duplicate of this bug. ***

*** Bug 4792 has been marked as a duplicate of this bug. ***

Bryce Harrington (bryce) wrote :

Hi puntium,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

Changed in xorg:
status: New → Incomplete
Bryce Harrington (bryce) wrote :

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

Changed in xorg:
status: Incomplete → Invalid
puntium (puntium) wrote :

I'm running in a vm, so I doubt you'll see anything interesting.

puntium (puntium) wrote :
puntium (puntium) wrote :

reopening with requested output

Changed in xorg:
status: Invalid → New
puntium (puntium) wrote :

Just confirmed on 8.10 as well. It seems things have gotten slightly better.

I wrote a simple ~/.fonts.conf:

<fontconfig>
   <match target="font">
      <test name="family"><string>DejaVu Sans Mono</string></test>
      <edit name="hintstyle"><const>hintfull</const></edit>
   </match>
</fontconfig>

fc-match -v "DejaVu Sans Mono" will always return me a result that is consistent with my fonts.conf.

In Intrepid, the above setting *seems* to work as long as you never actually run the gnome appearance panel and manually change the hint settings. Once you do that, then all the settings get overridden again (even if I restart apps [i've been testing with gedit])

Bryce Harrington (bryce) wrote :

Thanks puntium.

Changed in xorg:
importance: Undecided → Medium
status: New → Confirmed
mbana (m.bana) wrote :

I can also confirm this. The following snippet doesn't set the hinting to hintslight

    <match target="font">
        <test compare="eq" name="family">
            <string>Consolas</string>
        </test>
        <edit name="rgba" mode="assign"><const>rgb</const></edit>
        <edit name="autohint" mode="assign"><bool>false</bool></edit>
        <edit name="antialias" mode="assign"><bool>true</bool></edit>
        <edit name="hinting" mode="assign"><bool>true</bool></edit>
        <edit name="hintstyle" mode="assign"><const>hintslight</const></edit>
    </match>

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.

Bryce Harrington (bryce) on 2009-01-17
description: updated

Created attachment 23125
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.

Carsten Gräser (graeser) wrote :

I observe the same problem im 9.04. I mainly use kde which respects the per font setting of hintstyle in .fonts.conf . However any gnome app (e.g. gvim, gnome-terminal) ignores it.

Carsten Gräser (graeser) wrote :

Same problem in 9.10. Will this ever be fixed?

Created attachment 34511
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.

Igor (i-gocalinski) wrote :

This is not a problem of FontConfig. Cairo (still in 10.04) just decides to ignore the hintstyle returned by FontConfig if desktop provides any other value. Rebuild of Cairo solves this problem.

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
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
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
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.

Download full text (5.0 KiB)

Comment on attachment 42713
Revised version of respect-fontconfig patch against 1.10.2 version.

Review of attachment 42713:
-----------------------------------------------------------------

(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 w...

Read more...

Thomas Hotz (thotz) wrote :

So should we close the fontconfig task? Please tell us! Thank you!

Changed in libcairo (Ubuntu):
status: New → Confirmed
Changed in fontconfig (Ubuntu):
status: Confirmed → Incomplete
Thomas Hotz (thotz) on 2013-05-02
Changed in fontconfig (Ubuntu):
status: Incomplete → Invalid

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
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".

affects: fontconfig (Ubuntu) → cairo
Changed in cairo:
status: Invalid → New
affects: libcairo (Ubuntu) → cairo (Ubuntu)
Changed in cairo:
importance: Medium → Unknown
status: New → Unknown
Changed in cairo:
importance: Unknown → Low
status: Unknown → Confirmed

Created attachment 111193
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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.