different hintstyle issue

Bug #209256 reported by Mingming Ren on 2008-03-30
6
Affects Status Importance Assigned to Milestone
cairo
Confirmed
Low
cairo (Ubuntu)
Wishlist
Unassigned

Bug Description

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.

Mingming Ren (portis25) wrote :

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.

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.

Robin Stocker (nibor) wrote :

Could you submit that bug to the Cairo bug tracker please? (https://bugs.freedesktop.org/enter_bug.cgi?product=cairo)

Changed in libcairo:
importance: Undecided → Wishlist

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.

Changed in libcairo:
status: Unknown → Confirmed

Created an attachment (id=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.

Changed in cairo (Ubuntu):
status: New → Triaged

Created an attachment (id=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 :

In Cairo there is following logic for setting the HintStyle implemented:
  if the system-wide setting (I really don't know if it is XSETTINGS Xft/HintStyle served by gnome-settings-daemon or xrdb xft.hintstyle value) contains any valid value (int = 0-3, which represent HintNone, HintSlight, HintMedium and HintFull ), this value overrides everything and will be always used by Cairo.
  if the system-wide setting doesn't exist, the HintFull is assumed and that value will be used.
  if the system-wide setting exists, but is not valid, the HintStyle returned by FontConfig will be used.

I have modified the code (options represent the system-wide options object, others represents settings returned by FontConfig):
  if (options->base.hint_style == CAIRO_HINT_STYLE_DEFAULT)
    options->base.hint_style = others->base.hint_style
into
  if (others->base.hint_style != CAIRO_HINT_STYLE_DEFAULT)
    options->base.hint_style = others->base.hint_style

This way, if FontConfig has any information about Hinting of the font that was requested, that information will be used. Otherwise Cairo uses the default system-wide setting.

Igor (i-gocalinski) wrote :

Update: it is xrdb xft.hintstyle that is read by Cairo as the "System-wide" setting.

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 an attachment (id=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.

Igor (i-gocalinski) wrote :

It turned out that not only Hintstyle was ignored, but also switching between Subpixel and grayscale AA wasn't supported. Defining LCDFitler wasn't working as well.

I have created a patch comprehensively addressing this issues: http://weirdfellow.wordpress.com/2010/08/01/patching-cairo.
Finally I have fonts I want!

Igor (i-gocalinski) wrote :
tags: added: patch
Changed in libcairo:
importance: Unknown → Low

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

Changed in libcairo:
importance: Low → Unknown

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

Changed in libcairo:
importance: Unknown → Low

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

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: libcairo → cairo
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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