Bug 1767499

Summary: Very bad kerning for Tahoma after update from Pango 1.43 to 1.44.x
Product: [Fedora] Fedora Reporter: Artem S. Tashkinov <aros>
Component: pangoAssignee: Peng Wu <pwu>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 32CC: caillon+fedoraproject, constantine.gavrilov, fonts-bugs, gnome-sig, i18n-bugs, john.j5live, maclas, mclasen, nerijus, pwu, rcalmbac, rh, rhughes, rstrode, sandmann, shigorin, tagoh
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-09 19:16:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Tahoma as rendered by Pango 1.44 in Fedora 31
none
~/.config/fontconfig/fonts.conf
none
Font itself
none
Tahoma
none
Tahoma from Windows 10 with pango 1.44.7
none
WMT with the official update 1.44.7
none
WMT with the test update 1.44.7
none
The difference between the official update and the test version
none
WMT with pango 1.43
none
Microsoft core fonts broken kerning with Pango 1.44/patched freetype2 none

Description Artem S. Tashkinov 2019-10-31 15:16:07 UTC
Created attachment 1631087 [details]
Tahoma as rendered by Pango 1.44 in Fedora 31

This is how Tahoma font is rendered in Fedora 31.

After downgrading to pango-1.43.0-4.fc30.x86_64.rpm the issue disappears.

Comment 1 Artem S. Tashkinov 2019-10-31 15:16:48 UTC
Created attachment 1631088 [details]
~/.config/fontconfig/fonts.conf

Comment 2 Artem S. Tashkinov 2019-10-31 15:17:47 UTC
Created attachment 1631089 [details]
Font itself

Comment 3 Artem S. Tashkinov 2019-10-31 15:18:57 UTC
My DE is XFCE.

screen #0:
  dimensions:    1920x1080 pixels (508x286 millimeters)
  resolution:    96x96 dots per inch

Comment 4 Peng Wu 2019-11-22 09:42:22 UTC
Could you try the following patch?

https://gitlab.gnome.org/pwu/pango/commit/3cea6d3e2526f4900a180d75717be30d3646a9ed

The patch is only trying to find the cause of this problem.

Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=39192026

Comment 5 Artem S. Tashkinov 2019-11-24 13:44:49 UTC
Tried the build at https://koji.fedoraproject.org/koji/taskinfo?taskID=39192041 - no changes whatsoever.

You can install Tahoma in any Linux distro. I don't quite understand why I should be debugging this issue on my end: it's reproducible in a few seconds.

Comment 6 Artem S. Tashkinov 2019-11-24 13:46:41 UTC
Created attachment 1639217 [details]
Tahoma

Comment 7 Nicolas Mailhot 2019-11-24 14:09:06 UTC
Tahoma and other parts of Microsoft’s “fonts for the web” are very early display fonts with lots of technical mistakes.

So, they are challenging to display correctly, because they are, basically, incorrect (they were built around the bugs of the Windows text engine, and the screen pixel resolutions, of the time, both of which do not apply on a 2019 Linux system).

The version Microsoft ships in Windows has been fixed a long time ago (or they may special-case it, I don’t remember).

The version people keep installing on Linux is the same 1990’s Microsoft dump. Because they do not have access to the fixed font files for legal reasons.

Comment 8 Artem S. Tashkinov 2019-11-24 17:13:05 UTC
I've just installed the Tahoma font from Windows 10 LTSC - the result is absolutely the same.

You can freely get the font by downloading Windows 10 ISO from Microsoft website, then using 7zip to extract the fonts from install.wim

In case that's two difficult for you I've uploaded the font to my Google Drive:

https://drive.google.com/drive/folders/1d8l1OP08LCSBMrCpKLxniOR9Q_bFuoDV

Comment 9 Artem S. Tashkinov 2019-11-24 17:16:41 UTC
Created attachment 1639251 [details]
Tahoma from Windows 10 with pango 1.44.7

Comment 10 Peng Wu 2019-11-25 07:14:28 UTC
Actually I think the patch will make the text rendering one pixel positioning different.

Please provide whether this test version of pango works as old version or not.

Please try it with re-login or reboot.

Comment 11 Artem S. Tashkinov 2019-11-25 10:27:45 UTC
(In reply to Peng Wu from comment #10)

I did re-login.

The results are already posted.

I don't have a 20/20 vision to see a one pixel difference but overall it looks the same to me. You're free to use GIMP or any other graphics editor to spot the difference.

Comment 12 Artem S. Tashkinov 2019-11-25 10:34:32 UTC
Created attachment 1639435 [details]
WMT with the official update 1.44.7

Comment 13 Artem S. Tashkinov 2019-11-25 10:35:03 UTC
Created attachment 1639436 [details]
WMT with the test update 1.44.7

Comment 14 Artem S. Tashkinov 2019-11-25 10:37:01 UTC
Yes the PNG files turned out to be slightly different which means there's a difference in output.

Comment 15 Artem S. Tashkinov 2019-11-25 10:41:37 UTC
Created attachment 1639437 [details]
The difference between the official update and the test version

Comment 16 Peng Wu 2019-11-26 03:17:38 UTC
Please provide the screenshot of the expected result.

Comment 17 Artem S. Tashkinov 2019-11-26 11:47:20 UTC
Created attachment 1639774 [details]
WMT with pango 1.43

(In reply to Peng Wu from comment #16)
> Please provide the screenshot of the expected result.

Comment 18 Constantine Gavrilov 2020-01-26 18:37:56 UTC
I have finally found what is the reason. For me, the switch from Fedora 29 with freetype-freeworld from RPMFUSION to Fedora-31 with freetype with supposedly included sub-pixel rendering was really painful, especially on 4k screen, and especially when screen scaling was done.
The reason is that the freetype build Fedora 31 enables subpixel rendering, but disables LCD filter. This breaks the rendering. I believe this is an error, since both are covered by the same patent, and both must be enabled for subpixel rendering to work corretcly.

The following simple patch fixes it:

-- src/smooth/ftsmooth.c.orig  2020-01-26 19:29:22.287267057 +0200
+++ src/smooth/ftsmooth.c       2020-01-26 19:35:55.302516806 +0200
@@ -44,7 +44,7 @@
     sub[2].x = 21;
     sub[2].y = 0;
 
-#elif 0   /* or else, once ClearType patents expire */
+#else
 
     FT_Library_SetLcdFilter( render->root.library, FT_LCD_FILTER_DEFAULT );


And the code block in question is:


  /* initialize renderer -- init its raster */
  static FT_Error
  ft_smooth_init( FT_Renderer  render )
  {

#ifndef FT_CONFIG_OPTION_SUBPIXEL_RENDERING

    FT_Vector*  sub = render->root.library->lcd_geometry;


    /* set up default subpixel geometry for striped RGB panels. */
    sub[0].x = -21;
    sub[0].y = 0;
    sub[1].x = 0;
    sub[1].y = 0;
    sub[2].x = 21;
    sub[2].y = 0;
 
#elif 0   /* or else, once ClearType patents expire */ <<< BOOM ISSUE HERE
 
    FT_Library_SetLcdFilter( render->root.library, FT_LCD_FILTER_DEFAULT );
 
#endif

Recompiling the freetype with the fix, brings back very crips fonts, as opposed to stock ugly fat Fedora 31 fonts.

Comment 19 Peng Wu 2020-02-03 11:59:50 UTC
Could you provide the result screenshot with your patch?

Comment 20 Artem S. Tashkinov 2020-03-05 10:05:31 UTC
Created attachment 1667695 [details]
Microsoft core fonts broken kerning with Pango 1.44/patched freetype2

This patch doesn't work for this issue. Microsoft core fonts kerning is still utterly broken with the new Pango.

Comment 21 Peng Wu 2020-03-17 06:26:30 UTC
In pango 1.44, pango switched from freetype to harfbuzz for kerning, etc.

I think freetype kerning supports grid fitting, maybe harfbuzz kerning not support grid fitting, BICBW.

I dunno whether this is the root cause.

Comment 22 Peng Wu 2020-03-23 04:40:40 UTC
Upstream URL: https://github.com/harfbuzz/harfbuzz/issues/2268

Comment 23 Artem S. Tashkinov 2020-03-23 09:03:51 UTC
(In reply to Peng Wu from comment #22)
> Upstream URL: https://github.com/harfbuzz/harfbuzz/issues/2268

Are you sure? It's closed.

It's all kind ugly: Gnome/RH programmers removed bitmap fonts support and broke kerning for lots of fonts almost a year ago now and no one cares.

Comment 24 Peng Wu 2020-03-23 09:51:13 UTC
That is one potential cause for larger kerning value on small DPI,
and this feature exists in pango 1.43.

I can reproduce this issue now with pango-view.
$ pango-view -t "Tahoma 9" --font="Tahoma 9" --hinting=full --hint-metrics=on --dpi=72 --antialias=none --subpixel-order=rgb

Comment 25 Peng Wu 2020-05-07 07:26:11 UTC
From pango 1.43 to 1.44, pango switched to use harfbuzz instead of freetype.

Comment 26 Artem S. Tashkinov 2020-05-07 20:58:44 UTC
(In reply to Peng Wu from comment #25)

Knowing what causes this issue isn't much a consolation unfortunately. I'm now running F32 and I have to use packages from F30 (pango-1.43) and F31 (Thunar) in order to work around this issue.

Matthias Clasen who broke this feature has remained silent so far, two months after I reported the issue in Gnome's bugzilla, and half a year after I reported it here in RH's bugzilla.

He is ostensibly so busy he doesn't even have the time to confirm it.

Comment 27 Artem S. Tashkinov 2020-05-09 19:16:41 UTC
I was basically told to **** off and stop using Open Source. Maybe you're right. It doesn't seem entirely fair given how much I've invested in Open Source over the past 20+ years but it is what it is.

It doesn't seem fair given that Linux is often offered as a better alternative to Windows but it surely looks like some developers don't share this opinion and insist users must buy high DPI displays to keep on using Linux. Maybe Linux has suddenly become a sort of luxury but I surely don't want to participate in this.

I will downgrade from future Fedora releases which will make using Pango 1.43 impossible to CentOS 8 which still uses the same old "bad" "inefficient" "outdated" font stack and then when CentOS 8 become unsuitable for me I will probably give up on Linux altogether. I don't have spare $600 to buy a monitor just to continue to use Linux. I have much better things in life to spend this money on. Spending them on pixels is a vanity fair.

I'm deeply sorry for wasting everyone's time here and spamming this bugzilla with worthless requests. It's the worst interaction I've ever had with Open Source for the past 24 years but maybe I'm just unlucky since my eyes are my most prized asset. I will surely choose my eyes over Linux any time of the day.

Thank you for your attention. Have a nice day!