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.
Created attachment 1631088 [details] ~/.config/fontconfig/fonts.conf
Created attachment 1631089 [details] Font itself
My DE is XFCE. screen #0: dimensions: 1920x1080 pixels (508x286 millimeters) resolution: 96x96 dots per inch
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
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.
Created attachment 1639217 [details] Tahoma
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.
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
Created attachment 1639251 [details] Tahoma from Windows 10 with pango 1.44.7
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.
(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.
Created attachment 1639435 [details] WMT with the official update 1.44.7
Created attachment 1639436 [details] WMT with the test update 1.44.7
Yes the PNG files turned out to be slightly different which means there's a difference in output.
Created attachment 1639437 [details] The difference between the official update and the test version
Please provide the screenshot of the expected result.
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.
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.
Could you provide the result screenshot with your patch?
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.
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.
Upstream URL: https://github.com/harfbuzz/harfbuzz/issues/2268
(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.
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
From pango 1.43 to 1.44, pango switched to use harfbuzz instead of freetype.
(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.
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!