touch-packages team mailing list archive

[Bug Watch Updater <161058@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 24 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=11838.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2007-08-03T17:44:33+00:00 B. Lin wrote:

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?

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/0

------------------------------------------------------------------------
On 2008-07-18T05:45:31+00:00 B. Lin wrote:

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.

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/6

------------------------------------------------------------------------
On 2008-09-07T16:36:49+00:00 Bugs-freedesktop wrote:

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.

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/7

------------------------------------------------------------------------
On 2008-09-15T15:35:19+00:00 Freedesktop wrote:

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.

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/8

------------------------------------------------------------------------
On 2008-10-10T14:55:53+00:00 Chris Wilson wrote:

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

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/11

------------------------------------------------------------------------
On 2008-10-10T15:20:01+00:00 Chris Wilson wrote:

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

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/12

------------------------------------------------------------------------
On 2008-12-26T00:29:19+00:00 Doublebacks wrote:

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.

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/22

------------------------------------------------------------------------
On 2009-02-20T00:54:57+00:00 ZHANG Yi wrote:

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.

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/23

------------------------------------------------------------------------
On 2010-03-27T11:21:37+00:00 Paul Bredbury wrote:

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

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/26

------------------------------------------------------------------------
On 2010-05-09T19:02:53+00:00 Pedro Ribeiro wrote:

Hi, this is an annoying bug, any chance for the patch above to be
included in cairo? It solves the problem for me.

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/27

------------------------------------------------------------------------
On 2010-07-25T16:43:32+00:00 Grogi wrote:

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.

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/29

------------------------------------------------------------------------
On 2010-07-31T17:14:33+00:00 Grogi wrote:

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.

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/30

------------------------------------------------------------------------
On 2010-09-21T10:46:20+00:00 Freedesktop wrote:

(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

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/31

------------------------------------------------------------------------
On 2010-09-25T16:17:20+00:00 Krzysztof Kotlenga wrote:

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 ;)

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/32

------------------------------------------------------------------------
On 2010-09-25T16:43:39+00:00 Bugs-freedesktop wrote:

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

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/33

------------------------------------------------------------------------
On 2010-09-25T18:09:17+00:00 Krzysztof Kotlenga wrote:

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

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/34

------------------------------------------------------------------------
On 2011-01-30T04:13:36+00:00 Grogi wrote:

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.

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/35

------------------------------------------------------------------------
On 2011-01-30T04:16:32+00:00 Grogi wrote:

Created attachment 42714
Revised version of respect-fontconfig patch against 1.10.2 version - for easy reading

Just modified methods - for easy reading...

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/36

------------------------------------------------------------------------
On 2012-04-15T21:45:43+00:00 Zhou Yi Chao wrote:

One year passes. Is there anything stopping this patch merged to the
main line?

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/37

------------------------------------------------------------------------
On 2012-09-04T21:28:31+00:00 Freedesktop wrote:

Karl, do you think you would have the time to review the patch?

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/38

------------------------------------------------------------------------
On 2012-09-07T07:30:09+00:00 Bugs-freedesktop wrote:

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

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/39

------------------------------------------------------------------------
On 2012-09-07T22:16:56+00:00 Bugs-freedesktop wrote:

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

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/40

------------------------------------------------------------------------
On 2014-01-14T14:08:06+00:00 BubuXP wrote:

This bug is still present.
Any hope to see it fixed someday?

I suppose that using Wayland this bug should vanish. Am I right?

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/42

------------------------------------------------------------------------
On 2014-11-10T07:15:58+00:00 Lavir the Whiolet wrote:

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

Reply at: https://bugs.launchpad.net/cairo/+bug/161058/comments/43


** Changed in: cairo
       Status: Unknown => Confirmed

** Changed in: cairo
   Importance: Unknown => Low

** Bug watch added: KDE Bug Tracking System #105797
   https://bugs.kde.org/show_bug.cgi?id=105797

** Bug watch added: Mozilla Bugzilla #490475
   https://bugzilla.mozilla.org/show_bug.cgi?id=490475

** Bug watch added: GNOME Bug Tracker #657047
   https://bugzilla.gnome.org/show_bug.cgi?id=657047

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cairo in Ubuntu.
https://bugs.launchpad.net/bugs/161058

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

Status in Cairo Graphics Library:
  Confirmed
Status in cairo package in Ubuntu:
  Confirmed

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]

To manage notifications about this bug go to:
https://bugs.launchpad.net/cairo/+bug/161058/+subscriptions