FS#64451 - [cairo] Incorrect rendering of fonts

Attached to Project: Arch Linux
Opened by Fedor Dostoyevskiy (bachtiar) - Monday, 11 November 2019, 03:12 GMT
Last edited by freswa (frederik) - Sunday, 13 September 2020, 16:01 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Andreas Radke (AndyRTR)
Jan Alexander Steffens (heftig)
Laurent Carlier (lordheavy)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Since cairo-1.17.2+17+g52a7c79fd-1, font rendering is broken and results in disfigured text.

See attached image for example.

This was tested in xfce with following:
Font: Tahoma TrueType font from Windows ttf-fonts, size 8
Enable anti-aliasing: off
Hinting: Full
Sub-pixel order: None

There were no other changes to the system except cairo version.
Reverting to cairo-1.16.0-2 solves the problem (this was the last working version released in Arch).
This task depends upon

Closed by  freswa (frederik)
Sunday, 13 September 2020, 16:01 GMT
Reason for closing:  Upstream
Additional comments about closing:  This is not a packaging issue. Please report this upstream. Thank you
Comment by Andreas Radke (AndyRTR) - Wednesday, 11 December 2019, 12:06 GMT
Is this still an issue with 1.17.2+17+g52a7c79fd-2 (see also  FS#63856 ) ?
Comment by Fedor Dostoyevskiy (bachtiar) - Saturday, 18 January 2020, 20:56 GMT
Yes, it is still an issue with 1.17.2+17+g52a7c79fd-2.
Comment by mattia (nTia89) - Sunday, 12 April 2020, 15:53 GMT
I cannot reproduce the issue.
Is it still valid for you?
Comment by Fedor Dostoyevskiy (bachtiar) - Sunday, 12 April 2020, 21:00 GMT
Yes, as of 2020-04-12 current cairo version is still 1.17.2+17+g52a7c79fd-2 and is still the same issue as before. I verified with a fresh Arch install from scratch.

Did you try with the exact settings above (specifically antialias off etc.)?

I've done some more research and it seems that font rendering is very sensitive to display DPI setting. For reference, all my tests are at 96dpi (default). My impression is that there is some floating point rounding error - like certain values are being rounded in the wrong direction in the new version. The problem is emphasized when antialiasing is off, because it becomes obvious if it's not pixel-exact. The old version was pixel-exact at 96dpi. With the new version, if you change the DPI to 94 or 98, some of the artifacts disappear, but new ones start appearing. It's impossible to get it right. It also seems as if cairo and pango issues are somehow related.

If I can be of any more help, please let me know how. If you want, I can also send you the ttf-windows package to save you time.
Comment by mattia (nTia89) - Sunday, 12 April 2020, 21:29 GMT
I use GNOME, with tahoma font from WINE (aur package) and tweaks app for settings
and I cannot reproduce the issue.
Comment by Fedor Dostoyevskiy (bachtiar) - Monday, 13 April 2020, 04:19 GMT
That's a totally different scenario, I wouldn't say it counts as "can not reproduce".

I only noticed this issue in XFCE on text for desktop icons. It might be related to the fact that XFCE tries to drop a shadow on text for desktop icons. With antialiasing off, the text looks absolutely terrible and is almost unreadable (see attached image). With antialiasing on, the text looks "almost OK" - this makes me think that many people simply didn't notice it, even though you can still see that the quality of rendering is lower than what it was before if you compare it side-by-side.

This issue is definitely separate from https://bugs.archlinux.org/task/64450 (pango), because it is independent - i.e. this issue persists even when you resolve #64450 by reverting pango to an old working version.

Except for XFCE4 desktop icons, I am not sure what would be a minimal example, but GNOME + WINE is definitely not. From my observation, one could also infer that it a XFCE issue. To narrow down the problem, it would probably make sense to start with #64450.

My fonts:
$ fc-list Tahoma
/usr/share/fonts/TTF/tahoma.ttf: Tahoma:style=Regular,Normal,obyčejné,Standard,Κανονικά,Normaali,Normál,Normale,Standaard,Normalny,Обычный,Normálne,Navadno,thường,Arrunta
/usr/share/fonts/TTF/tahomabd.ttf: Tahoma:style=Bold,Negreta,tučné,fed,Fett,Έντονα,Negrita,Lihavoitu,Gras,Félkövér,Grassetto,Vet,Halvfet,Pogrubiony,Negrito,Полужирный,Fet,Kalın,Krepko,đậm,Lodia

$ sha1sum /usr/share/fonts/TTF/tahoma*.ttf
bc34f23d506dc2886878d1af5bfd2f0ddcf2726a /usr/share/fonts/TTF/tahomabd.ttf
f43d7bf79be8b787d53f7b06a2d5136865aff169 /usr/share/fonts/TTF/tahoma.ttf
Comment by mattia (nTia89) - Monday, 13 April 2020, 07:59 GMT
Ok, let's do this in an orderly fashion:
1- I do not use GNOME + WINE; I use GNOME and the Tahoma font FROM the WINE package [https://aur.archlinux.org/packages/ttf-tahoma/]. Let we know if this issue happens also with this font, that's different from the original Windows/Microsoft one (yes, I checked `fc-list Tahoma` and `sha1sum` and output differ!).
2- It's important to easily REPRODUCE the issue by giving us concise instructions; this will let know A) confirm it is a "world" issue, since only you apparently have reported it B) where is (which package or combination) the issue: maybe it is only related to XFCE, maybe not, ...
Comment by Fedor Dostoyevskiy (bachtiar) - Monday, 13 April 2020, 18:37 GMT
If I use Tahoma TTF font from WINE, the appearance of text for desktop icons in XFCE is different, but still not OK.
(Note that my version of Tahoma TTF was copied directly from Windows 7 and is almost 3 times as big as Tahoma TTF from WINE. It would be interesting to know how they are different as this might provide some clues.)
This issue seems to be specific to XFCE4 desktop icons when used with latest Cairo version. (Perhaps it is also somewhere else, but I'm not aware of it at the moment).
To reproduce it, you need to actually use XFCE and not GNOME.
Comment by Fedor Dostoyevskiy (bachtiar) - Monday, 13 April 2020, 19:04 GMT
I noticed few more weird things. For example, there is an icon called "File System" which is a XFCE-specific system icon. If I create a folder with the exact same name "File System", the text on my icon looks significantly different. If I add a dot, such as in "File System.", the text again looks different. Bad in all cases, but different. Parts of the glyphs are simply "rounded" into the wrong pixels.

And one more thing. If I switch antialiasing on, the rendering of the text for same icon actually looks different if the icon is positioned on the top or on the bottom of the screen.
Comment by mattia (nTia89) - Monday, 13 April 2020, 19:26 GMT
which locale are you using?
Comment by Fedor Dostoyevskiy (bachtiar) - Monday, 13 April 2020, 20:10 GMT
$ echo $LANG
en_US.UTF-8
Comment by Fedor Dostoyevskiy (bachtiar) - Tuesday, 14 April 2020, 08:19 GMT
Currently known facts:
- the bug seems to be related to XFCE4 desktop icons, namely "Home" and "File System"
- the text for those two icons seems to use different rendering than text for other icons (e.g. user-made shortcut with exactly the same text)
- there are different versions of tahoma.ttf font and they produce different results
- tahoma.ttf which I used is from official Windows 10 ISO downloaded from Microsoft (AUR: win10-ttf)
- there were no problems up to cairo-1.16.0-2, since cairo-1.17.2+17+g52a7c79fd-1 it produces artifacts as shown on the attached PNG
- the problem is reproducible on a clean system installed from scratch with out-of-the-box xorg and xfce4 and nothing else
Comment by stargazer (bernie) - Saturday, 18 April 2020, 18:16 GMT
I see the same rendering issues on fonts when using e.g. keepassx (which uses mono) . version cairo-1.16.0 is fine.
Comment by mattia (nTia89) - Saturday, 18 April 2020, 18:18 GMT
@bernie please share a screenshot
Comment by stargazer (bernie) - Saturday, 18 April 2020, 20:12 GMT
e.g. keepassx , good font rendering with cairo version 1.16.x

Loading...