After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 657047 - System configuration's subpixel rendering is used for rendering text
System configuration's subpixel rendering is used for rendering text
Product: GIMP
Classification: Other
Component: Tools
git master
Other Linux
: Normal minor
: ---
Assigned To: GIMP Bugs
: 647313 676312 678746 683330 731944 739860 746791 781474 (view as bug list)
Depends on:
Reported: 2011-08-21 22:28 UTC by Einar Lielmanis
Modified: 2018-01-20 20:42 UTC
See Also:
GNOME target: ---
GNOME version: ---

GIMP screenshot (236.86 KB, image/png)
2011-09-03 00:16 UTC, The Man
Proposed patch (946 bytes, patch)
2011-09-06 12:15 UTC, Massimo
none Details | Review
Comparison (32.03 KB, image/png)
2015-04-02 16:57 UTC, TesX
GPaint is not affected (6.46 KB, image/png)
2015-04-03 08:55 UTC, TesX

Description Einar Lielmanis 2011-08-21 22:28:29 UTC
If the subpixel rendering is enabled on system — e.g in ~/.fonts.conf with <edit mode="assign" name="rgba"><const>rgb</const></edit> — then attempts to write some text, e.g. in orange color — will leave visible colored subpixel rendering artifacts on the sides of the letters, which can look weird, especially when zoomed in.

While it may be successfully argued that gimp is just obeying system preferences for the selected font, this also means that the same file with unrasterized text with same settings in xcf, with the same font, with same almost everything — may still look vastly different on other system, which I'd argue is a bad thing.

I'd suggest not using subpixel rendering for text output at all — it and its settings are absolutely dependant on the exact monitor the text is viewed on — or to move it to an option like "antialias" already is (but I can't imagine a good use case where this would be helpful).
Comment 1 Michael Schumacher 2011-08-25 20:37:48 UTC
Is this the same as bug #647313?
Comment 2 Einar Lielmanis 2011-08-25 23:00:16 UTC
Yes, it is indeed.
Comment 3 Michael Schumacher 2011-08-26 09:42:23 UTC
*** Bug 647313 has been marked as a duplicate of this bug. ***
Comment 4 Martin Nordholts 2011-08-27 14:27:34 UTC

*** This bug has been marked as a duplicate of bug 647313 ***
Comment 5 Martin Nordholts 2011-08-27 15:17:48 UTC
*** Bug 647313 has been marked as a duplicate of this bug. ***
Comment 6 The Man 2011-09-03 00:16:37 UTC
Created attachment 195548 [details]
GIMP screenshot

I can confirm this bug, screenshot attached. And I would not call it a «minor» bug…
GIMP version 2.7.3
Comment 7 Massimo 2011-09-06 12:15:21 UTC
Created attachment 195777 [details] [review]
Proposed patch

Could anybody that is experiencing the problem, please,
test the attached patch and report whether it fixes the
Comment 8 Einar Lielmanis 2011-09-07 09:00:35 UTC
It doesn't help. By the quick glance over some bug reports, it looks like a conceptual design choice of cairo: users' font settings have an explicit priority over the settings requested by the application:
Comment 9 Massimo 2011-09-07 11:15:00 UTC
If that's the case it is wrong because the output
of cairo is not going directly to the screen, but 
it is a layer in a stack of layers that are combined
together according to different rules, none of which
take in consideration subpixel rendering. 

Neither does a GIMP's filter applied to it.

When different results on different platforms will 
be observed it will be GIMP's fault.
Comment 10 rat.o.drat 2012-05-06 19:43:37 UTC
I can confirm this bug with GIMP 2.8. Here's a screenshot: Also Massimo's patch doesn't fix this. Please tell me if I should add any additional details.
Comment 11 Michael Schumacher 2012-05-06 20:45:43 UTC
From #cairo on freenode:

22:39 < schumaml> hi, is there a way to prevent subpixel rendering when adding
                  text to an image in gimp - see 
         for details 
                  about how cairo is invovled
22:43 < ickle> cairo_set_antialias(GRAY), cairo_font_options_set_antialias(GRAY)
Comment 12 Michael Schumacher 2012-05-06 20:48:53 UTC
at least one of those has been tried unsuccessfully
Comment 13 Michael Schumacher 2012-05-18 13:16:59 UTC
*** Bug 676312 has been marked as a duplicate of this bug. ***
Comment 14 Michael Schumacher 2012-06-25 04:57:21 UTC
*** Bug 678746 has been marked as a duplicate of this bug. ***
Comment 15 Michael Natterer 2012-09-04 20:05:20 UTC
*** Bug 683330 has been marked as a duplicate of this bug. ***
Comment 16 James Le Cuirot 2012-12-29 21:45:14 UTC
Is there any update here? I saw Michael Natterer state in bug #683330 that it's a system misconfiguration. If that's the case then this should be closed but I'd also like some more details. Where in the configuration would the problem lie? I've looked through /etc/fonts and I can't see anything relevant. I am running Gentoo and I believe I am using the default font configuration so does that mean it is a Gentoo bug?
Comment 17 Michael Natterer 2012-12-30 20:14:32 UTC
We don't know. We asked the fontconfig people and were told it's a system
config problem. It has never happened on my machine (debian unstable), and
not for many others either. Please ask fontconfig.

Finally closing as NOTGNOME because we can't do anything about it.
Comment 18 Michael Natterer 2014-06-30 14:41:34 UTC
*** Bug 731944 has been marked as a duplicate of this bug. ***
Comment 19 Michael Schumacher 2014-11-10 11:40:47 UTC
*** Bug 739860 has been marked as a duplicate of this bug. ***
Comment 20 TesX 2015-04-02 16:56:36 UTC
I think that this bug should be reopened because I think it definitely is a problem with GIMP, since I tried typing a white text on white background with Krita and there it works...

So, I suppose, this means that it's not a problem of fontconfig...

I will attach a screenshot of the text with GIMP and Krita.
(Please, see BUG 746791)
Comment 21 TesX 2015-04-02 16:57:26 UTC
Created attachment 300848 [details]

My Comparison on the same system between Krita and GIMP
Comment 22 Michael Schumacher 2015-04-02 17:54:43 UTC
Does Krita use fontconfig?
Comment 23 Michael Natterer 2015-04-02 22:16:32 UTC
*** Bug 746791 has been marked as a duplicate of this bug. ***
Comment 24 TesX 2015-04-03 08:55:44 UTC
Created attachment 300871 [details]
GPaint is not affected

I don't know about Krita (since it is a Qt/KDE app), but GPaint which uses GTK and pango seems to be not affected by this bug... (and I presume that it uses fontconfig)
Comment 25 Michael Natterer 2015-04-03 10:55:49 UTC
Do Krita and GPaint also use pango-cairo? Because that's what's affected by
the problem.
Comment 26 TesX 2015-04-03 11:30:40 UTC
I don't know how to check this precisely, I tried with ldd:

ldd `which gpaint` | grep 'pango\|cairo' => /usr/lib/ (0x00007fa37f210000) => /usr/lib/ (0x00007fa37ed9e000) => /usr/lib/ (0x00007fa37df2a000) => /usr/lib/ (0x00007fa37d99e000)

ldd `which krita` | grep 'pango\|cairo'

Here is the complete ldd:


ldd `which gpaint` (0x00007ffeb21f7000) => /usr/lib/ (0x00007f4483554000) => /usr/lib/ (0x00007f4483339000) => /usr/lib/ (0x00007f4482cf7000) => /usr/lib/ (0x00007f4482a41000) => /usr/lib/ (0x00007f448281b000) => /usr/lib/ (0x00007f44824eb000) => /usr/lib/ (0x00007f44822c5000) => /usr/lib/ (0x00007f4482079000) => /usr/lib/ (0x00007f4481e28000) => /usr/lib/ (0x00007f4481b1a000) => /usr/lib/ (0x00007f4481777000) => /usr/lib/ (0x00007f4481412000) => /usr/lib/ (0x00007f4481205000) => /usr/lib/ (0x00007f4480e8f000) => /usr/lib/ (0x00007f4480c79000) => /usr/lib/ (0x00007f4480a36000) => /usr/lib/ (0x00007f4480770000) => /usr/lib/ (0x00007f448056c000) => /usr/lib/ (0x00007f448022a000) => /usr/lib/ (0x00007f4480024000) => /usr/lib/ (0x00007f447fe07000) => /usr/lib/ (0x00007f447fbfd000) => /usr/lib/ (0x00007f447f9fa000) => /usr/lib/ (0x00007f447f7e9000) => /usr/lib/ (0x00007f447f5df000) => /usr/lib/ (0x00007f447f3d4000) => /usr/lib/ (0x00007f447f1d1000) => /usr/lib/ (0x00007f447efce000) => /usr/lib/ (0x00007f447edbc000) => /usr/lib/ (0x00007f447eb0f000) => /usr/lib/ (0x00007f447e80e000) => /usr/lib/ (0x00007f447e60a000) => /usr/lib/ (0x00007f447e3d4000) => /usr/lib/ (0x00007f447e1d0000) => /usr/lib/ (0x00007f447dfc6000) => /usr/lib/ (0x00007f447dda4000) => /usr/lib/ (0x00007f447db8e000) => /usr/lib/ (0x00007f447d836000) => /usr/lib/ (0x00007f447d62e000) => /usr/lib/ (0x00007f447d42c000) => /usr/lib/ (0x00007f447d1bd000) => /usr/lib/ (0x00007f447cfb4000)
        /lib64/ (0x00007f4483859000) => /usr/lib/ (0x00007f447cd8e000) => /usr/lib/ (0x00007f447cb31000) => /usr/lib/ (0x00007f447c91a000) => /usr/lib/ (0x00007f447c6f0000) => /usr/lib/ (0x00007f447c4e0000) => /usr/lib/ (0x00007f447c256000) => /usr/lib/ (0x00007f447c052000) => /usr/lib/ (0x00007f447be4c000) => /usr/lib/ (0x00007f447bc49000) => /usr/lib/ (0x00007f4478f70000) => /usr/lib/ (0x00007f4478d52000)



ldd `which krita` (0x00007ffe5d19b000) => /usr/lib/ (0x00007fa0af536000) => /usr/lib/ (0x00007fa0ae847000) => /usr/lib/ (0x00007fa0ae35d000) => /usr/lib/ (0x00007fa0ade6e000) => /usr/lib/ (0x00007fa0adb5f000) => /usr/lib/ (0x00007fa0ad949000) => /usr/lib/ (0x00007fa0ad5a6000) => /usr/lib/ (0x00007fa0ad264000) => /usr/lib/ (0x00007fa0ad053000) => /usr/lib/ (0x00007fa0acda4000) => /usr/lib/ (0x00007fa0acba0000) => /usr/lib/ (0x00007fa0ac94e000) => /usr/lib/ (0x00007fa0ac64d000) => /usr/lib/ (0x00007fa0ac417000) => /usr/lib/ (0x00007fa0abef1000) => /usr/lib/ (0x00007fa0abc70000) => /usr/lib/ (0x00007fa0ab918000) => /usr/lib/ (0x00007fa0ab617000) => /usr/lib/ (0x00007fa0ab413000) => /usr/lib/ (0x00007fa0ab17f000) => /usr/lib/ (0x00007fa0aac9c000) => /usr/lib/ (0x00007fa0aa8ff000) => /usr/lib/ (0x00007fa0aa6e9000) => /usr/lib/ (0x00007fa0aa431000) => /usr/lib/ (0x00007fa0a9f5f000) => /usr/lib/ (0x00007fa0a9c15000) => /usr/lib/ (0x00007fa0a98b2000) => /usr/lib/ (0x00007fa0a966c000) => /usr/lib/ (0x00007fa0a9460000) => /usr/lib/ (0x00007fa0a924c000) => /usr/lib/ (0x00007fa0a8bb5000) => /usr/lib/ (0x00007fa0a8998000) => /usr/lib/ (0x00007fa0a871b000) => /usr/lib/ (0x00007fa0a8416000) => /usr/lib/ (0x00007fa0a8108000) => /usr/lib/ (0x00007fa0a7ef2000) => /usr/lib/ (0x00007fa0a7c2c000) => /usr/lib/ (0x00007fa0a79db000) => /usr/lib/ (0x00007fa0a77d3000) => /usr/lib/ (0x00007fa0a75b6000) => /usr/lib/ (0x00007fa0a73ac000) => /usr/lib/ (0x00007fa0a7169000) => /usr/lib/ (0x00007fa0a6f57000) => /usr/lib/ (0x00007fa0a6d47000) => /usr/lib/ (0x00007fa0a6b21000) => /usr/lib/ (0x00007fa0a6919000)
        /lib64/ (0x00007fa0aff50000) => /usr/lib/ (0x00007fa0a66f7000) => /usr/lib/ (0x00007fa0a63ef000) => /usr/lib/ (0x00007fa0a61d5000) => /usr/lib/ (0x00007fa0a5f7d000) => /usr/lib/ (0x00007fa0a5c0b000) => /usr/lib/ (0x00007fa0a59e1000) => /usr/lib/ (0x00007fa0a57de000) => /usr/lib/ (0x00007fa0a2b05000) => /usr/lib/ (0x00007fa0a2901000) => /usr/lib/ (0x00007fa0a26be000) => /usr/lib/ (0x00007fa0a22bd000) => /usr/lib/ (0x00007fa0a1e93000) => /usr/lib/ (0x00007fa0a1c57000) => /usr/lib/ (0x00007fa0a1944000) => /usr/lib/ (0x00007fa0a16b6000) => /usr/lib/ (0x00007fa0a14ad000) => /usr/lib/ (0x00007fa0a12a8000) => /usr/lib/ (0x00007fa0a102d000) => /usr/lib/ (0x00007fa0a0bb1000) => /usr/lib/ (0x00007fa0a08bb000) => /usr/lib/ (0x00007fa0a0683000) => /usr/lib/ (0x00007fa0a047d000) => /usr/lib/ (0x00007fa0a0272000) => /usr/lib/ (0x00007fa0a006c000) => /usr/lib/ (0x00007fa09fe23000) => /usr/lib/ (0x00007fa09fbb4000) => /usr/lib/ (0x00007fa09f957000) => /usr/lib/ (0x00007fa09f74e000) => /usr/lib/ (0x00007fa09f549000) => /usr/lib/ (0x00007fa09f345000) => /usr/lib/ (0x00007fa09f13f000) => /usr/lib/ (0x00007fa0b0142000) => /usr/lib/ (0x00007fa09eefe000) => /usr/lib/ (0x00007fa09eb99000) => /usr/lib/ (0x00007fa09e97b000) => /usr/lib/ (0x00007fa09e777000)
Comment 27 Michael Natterer 2015-04-03 15:19:43 UTC
Have you asked the fontconfig people about the configuration issue?

I (and many others) use subpixel AA for screen rendering, and still GIMP's
font rendering is OK. So I tend to trust the fontconfig guys' statement
that this problem is related to a broken fonconfig setup. The problem
also went away for some people when upgrading their system.

How Krita or GPaint render their fonts is probably different and
not relevant here.
Comment 28 Colin Griffith 2015-05-15 23:51:41 UTC
It seems that this issue stems from when a desktop environment uses (or writes to) the global '~/.config/fontconfig/fonts.conf' (I think it used to be '~/.fonts.conf') file for antialiasing configuration. I know that at least KDE uses this to override global configuration files (which would be in '/etc/fonts/conf.d', I believe), and I believe there are other desktop environments that do as well - perhaps Xfce, though I don't know for sure.

Deleting the local config file inside of .config fixes this bug, though probably would NOT be a valid solution for people who want to override their distribution's default options. However, it also seems that deleting just the relevant part of the config file works too; removing these lines works for me:

 <match target="font">
  <edit mode="assign" name="rgba">

It's interesting to note that '/etc/fonts/conf.d' does not contain a file that specifies this anywhere, which I find weird. So, if anyone has an odd computer setup where fontconfig can't detect that they have an LCD monitor, they might not be able to ever get this bug in Gimp fixed without also removing all subpixel rendering from the rest of their applications.

And of course, every time anyone edits KDE's font rendering settings, or potentially the font settings for other desktop environments besides Gnome, they'll have to go in and delete that part of the configuration file after doing so.

I don't know if you guys will still consider this to not be a Gimp/Gnome bug, but it doesn't seem likely that it'll ever be resolved through any other route. People who have hardware that FontConfig won't detect as an LCD display will also be permanently out of luck, so it probably isn't a good idea to ask KDE to simply not add that part of the config file.
Comment 29 Thomas Manni 2017-04-20 16:33:01 UTC
*** Bug 781474 has been marked as a duplicate of this bug. ***
Comment 30 Jehan 2018-01-19 14:37:18 UTC
Hey all!

We have a bunch of people reporting similar issues and it comes from them having installed a package called "fontconfig-infinality". Simply uninstalling this package fixes the problem.
I am unsure so I hesitate to just mark them as duplicates, but it looks like quite a similar problem. If anyone still reading here still has this problem, please check if you have installed such "infinality" package, get rid of it and try again.

If it also fixes your problem, could you please report here as well to confirm?

See bug 708052.
Comment 31 rat.o.drat 2018-01-20 20:42:02 UTC
Jehan: Infinality is a patchset mainly for freetype, typically used together with some fontconfig configurations. It could be that with the patch and/or some fontconfig setting, sub-pixel is force enabled. But in that case, the user should address the force-enable (probably can be fixed by fixing fontconfig settings and/or env variables for gimp). Or maybe it's not force-enabled and it's GIMP's fault again, but currently GIMP (version 2.8.22) seems to render properly without sub-pixel although I have it enabled, so it's probably not GIMP. In either case, it's not as easy to uninstall this package for most people, as it's most likely deliberately installed to achieve certain  font rendering features, and uninstalling this package will lead to making fonts look worse for said user.