Bug 1767499 - Very bad kerning for Tahoma after update from Pango 1.43 to 1.44.x
Summary: Very bad kerning for Tahoma after update from Pango 1.43 to 1.44.x
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: pango
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peng Wu
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-10-31 15:16 UTC by Artem S. Tashkinov
Modified: 2020-11-30 01:51 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-09 19:16:41 UTC
Type: Bug


Attachments (Terms of Use)
Tahoma as rendered by Pango 1.44 in Fedora 31 (27.86 KB, image/png)
2019-10-31 15:16 UTC, Artem S. Tashkinov
no flags Details
~/.config/fontconfig/fonts.conf (612 bytes, application/xml)
2019-10-31 15:16 UTC, Artem S. Tashkinov
no flags Details
Font itself (126.62 KB, application/x-xz)
2019-10-31 15:17 UTC, Artem S. Tashkinov
no flags Details
Tahoma (251.60 KB, application/x-font-ttf)
2019-11-24 13:46 UTC, Artem S. Tashkinov
no flags Details
Tahoma from Windows 10 with pango 1.44.7 (19.06 KB, image/png)
2019-11-24 17:16 UTC, Artem S. Tashkinov
no flags Details
WMT with the official update 1.44.7 (36.58 KB, image/png)
2019-11-25 10:34 UTC, Artem S. Tashkinov
no flags Details
WMT with the test update 1.44.7 (36.31 KB, image/png)
2019-11-25 10:35 UTC, Artem S. Tashkinov
no flags Details
The difference between the official update and the test version (2.08 KB, image/png)
2019-11-25 10:41 UTC, Artem S. Tashkinov
no flags Details
WMT with pango 1.43 (30.41 KB, image/png)
2019-11-26 11:47 UTC, Artem S. Tashkinov
no flags Details
Microsoft core fonts broken kerning with Pango 1.44/patched freetype2 (43.58 KB, image/png)
2020-03-05 10:05 UTC, Artem S. Tashkinov
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME pango issues 463 0 None None None 2020-03-10 15:19:51 UTC
Github harfbuzz harfbuzz issues 1892 0 None closed rounding differences between harfbuzz and cairo 2021-01-14 06:16:52 UTC
Github harfbuzz harfbuzz issues 2394 0 None closed No/broken kerning for a large number of fonts 2021-01-14 06:17:31 UTC

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!


Note You need to log in before you can comment on or make changes to this bug.