Bug 1336042 - Liberation Fonts not displayed correctly
Summary: Liberation Fonts not displayed correctly
Keywords:
Status: VERIFIED
Alias: None
Product: Fedora
Classification: Fedora
Component: liberation-fonts
Version: 30
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ---
Assignee: vishal vijayraghavan
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-13 21:13 UTC by Viktor Pankraz
Modified: 2019-06-27 21:29 UTC (History)
9 users (show)

Fixed In Version: liberation-fonts-2.00.3-1.fc29
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1626999 (view as bug list)
Environment:
Last Closed:


Attachments (Terms of Use)
Screenshots to show the difference between Fedora 22 and 23/24 (128.41 KB, image/png)
2016-05-13 21:13 UTC, Viktor Pankraz
no flags Details
Comparison: left: COPR, right: fedorahosted (806.88 KB, image/png)
2016-10-18 07:10 UTC, Viktor Pankraz
no flags Details
Diff from LiberationSans-Regular.ttx (made with ttx) from the binary release from https://fedorahosted.org/liberation-fonts/ to the .ttf in liberation-sans-fonts-2.00.1-5.fc25.noarch.rpm from COPR (1.80 KB, text/plain)
2016-11-27 14:48 UTC, Nikolaus Waxweiler
no flags Details
Impallari testpage, left: COPR, right: Fedorahosted (304.79 KB, image/png)
2016-11-27 18:47 UTC, Viktor Pankraz
no flags Details

Description Viktor Pankraz 2016-05-13 21:13:52 UTC
Created attachment 1157360 [details]
Screenshots to show the difference between Fedora 22 and 23/24

Description of problem:
Liberation Fonts are not being diplayed correctly. This is obvious on websites where the text is shifted some pixel up compared to Fedora 22 and other OSes. Fedora 23 has the same issue.

The source files for liberation font is the same in Fedora 22-24 but the output *.ttf files are different. Installing the RPMs from Fedora 22 in Fedora 24 fixes the problem. Maybe the output has changed due to updated build tools?

Version-Release number of selected component (if applicable):
1.07.4

How reproducible:
Open Webpage in Firefox or Google Chrome

Steps to Reproduce:
Open https://github.com/solus-project/budgie-desktop in Firefox

Actual results:
Text is shifted upwards besides the images (see attached screenshot)

Expected results:
Text aligned with images (see attached screenshot)

Additional info:
https://plus.google.com/+ViktorPankraz/posts/L8KVUGEbHxz

Comment 1 Viktor Pankraz 2016-05-13 21:17:42 UTC
Note that I don't have any fonts from Microsoft installed. I doublechecked, Liberation fonts are used on websites on all systems.

Comment 2 Yaroslav 2016-05-14 14:05:58 UTC
Same thing happens after upgrading to F23, but for me it's only in Google Chrome. Fonts in Firefox look ok.

Comment 3 Pravin Satpute 2016-05-16 11:46:42 UTC
Which locale do you use?

Comment 4 Viktor Pankraz 2016-05-16 12:17:07 UTC
It's German. de_DE.

Comment 5 Yaroslav 2016-05-16 12:45:48 UTC
en_US here.

Comment 6 Viktor Pankraz 2016-05-16 14:20:17 UTC
In my attached screenshot the upper half is from Google Chrome and lower half from Firefox (it's from heise.de/open). Bug definitely also appears in Firefox though it looks different. Compare e.g. the distribution dropdown list on distrowatch.com in F22 and F23/24. Every item is shifted some pixels. And in the distribution search field the text isn't displayed correctly.

Comment 7 Pravin Satpute 2016-05-17 14:02:58 UTC
Yes, i can reproduce bug. Its tricky issue, trying to find root cause.

Comment 8 Viktor Pankraz 2016-05-19 06:20:01 UTC
There is one significant version change in build dependencies between F22 and F23/24: ImagaMagick-libs changed from 6.8 to 6.9. Could this be a hint?

Comment 9 Viktor Pankraz 2016-09-13 08:04:57 UTC
(In reply to Pravin Satpute from comment #7)
> Yes, i can reproduce bug. Its tricky issue, trying to find root cause.

Any update on this? I would be happy to help, so if you can tell me how :)

Just for testing purposes I installed version 2.00.1 of liberation-fonts from https://fedorahosted.org/liberation-fonts/. It looks way better. Maybe switching to this version would solve the problems. Version 2 was released on July 18, 2012, so why does Fedora still ship version 1?

Comment 10 Pravin Satpute 2016-09-13 09:22:45 UTC
Unfortunately i did not found time to work on this issue. :(

For Liberation 2.x, We already started discussion #1375061

At least for now, i am creating Copr repo and then based on feedback, we can migrate to Liberation 2.x.

Comment 11 Viktor Pankraz 2016-10-18 07:10:41 UTC
Created attachment 1211620 [details]
Comparison: left: COPR, right: fedorahosted

Comment 12 Viktor Pankraz 2016-10-18 07:24:37 UTC
I installed liberation-fonts from the Copr repo mentioned in Bug 1375061. That should be Liberation Fonts version 2. But it has the same issues as version 1 from the original Fedora repo.

However when I use the ttf-files directly from https://fedorahosted.org/liberation-fonts/ everything looks like expected. See attachment 1211620 [details] for a comparison between the version from your Copr repo (left) and the tarball from fedorahosted (right). Both Version 2 obviously.

Now we have to find out which part of the toolchain changed since Fedora 23 that causes the issues with both versions.

Comment 13 Nikolaus Waxweiler 2016-10-19 18:55:21 UTC
Hm. The metrics in the OS/2 table appear identical in both LiberationSans-Regular.ttf files (from the site and in the archive).

Comment 14 Yaroslav 2016-11-23 14:50:40 UTC
The issue is still there in Fedora 25. Upgrading to Liberation-Fonts v2 from Copr mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1375061 didn't fix the problem.

Comment 15 Nikolaus Waxweiler 2016-11-27 13:59:30 UTC
Does the bug also surface on http://www.impallari.com/testing/? Drag and drop the .ttf on the gray bar at the top. You can switch between ttfs when dropping multiple files on it.

Comment 16 Nikolaus Waxweiler 2016-11-27 14:48:50 UTC
Created attachment 1224851 [details]
Diff from LiberationSans-Regular.ttx (made with ttx) from the binary release from https://fedorahosted.org/liberation-fonts/ to the .ttf in liberation-sans-fonts-2.00.1-5.fc25.noarch.rpm from COPR

The font is switched from OS/2 version 3 to 4, among other minor differences of unknown significance. It looks like the release in the COPR does not match the release on https://fedorahosted.org/liberation-fonts/.

Comment 17 Yaroslav 2016-11-27 16:03:34 UTC
The bug also present on the site you mentioned. It was not obvious at first, but when the text is selected, the selection cuts the top of some of the symbols.

Comment 18 Viktor Pankraz 2016-11-27 18:47:58 UTC
Created attachment 1224968 [details]
Impallari testpage, left: COPR, right: Fedorahosted

Difference between LiberationSans V2 from Pravins COPR (left) and the binary from fedorahosted (right). It's very obvious when text is selected (first line)

Comment 19 Viktor Pankraz 2016-11-27 18:53:12 UTC
Seems like the margin/padding above the glyphs is missing in the COPR Version just like in Liberation V1 from the official Fedora repository.

Comment 20 Yaroslav 2016-11-29 02:52:14 UTC
Is there any way to fix it in Fedora 25?

Thanks.

Comment 21 Nikolaus Waxweiler 2016-11-29 04:13:24 UTC
Yes. Use the files from fedorahosted.

Comment 22 Yaroslav 2016-11-29 04:34:15 UTC
Thanks, I've already used those. What I was looking for is an update to official rpm.

Comment 23 Pravin Satpute 2016-11-29 06:29:47 UTC
(In reply to Nikolaus Waxweiler from comment #21)
> Yes. Use the files from fedorahosted.

Which files are you using from fedorahosted? directly ttf?
Present Copr repo ttf's are build from sources, so may be issue with any recent update. (Need to check)

May be as of now, i should directly package ttf in Copr repo  and with next release (which might happen in next month) try again building from source and see the issue.

Comment 24 Nikolaus Waxweiler 2017-05-07 17:52:03 UTC
https://github.com/fontforge/fontforge/issues/3052

Hm!

Comment 25 Fedora End Of Life 2017-11-16 19:37:38 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 26 Nikolaus Waxweiler 2017-11-28 13:49:55 UTC
As I understand it, this issue can be worked around by building the fonts by a specific version of Fontforge. A better path would probably to port the source to a UFO workflow and go from there, but that would probably require much more effort.

Comment 27 Viktor Pankraz 2017-11-29 09:36:20 UTC
Seems like nobody is interested in fixing it neither in FontForge itself nor in Fedora :(

Comment 28 Nikolaus Waxweiler 2018-02-11 18:34:36 UTC
Would it maybe make more sense to switch to Google's Arimo, Tinos and Couisine? The Liberation package is derived from those anyway...

Comment 29 Pravin Satpute 2018-02-12 09:46:19 UTC
Can we reproduce this issue with Arimo, Tonis and Couisine?

Comment 30 Nikolaus Waxweiler 2018-02-17 17:40:10 UTC
I see no height difference when switching between Arimo and Liberation Sans on a random GitHub page.

Comment 31 Jens Petersen 2018-07-17 08:30:37 UTC
(In reply to Nikolaus Waxweiler from comment #30)
> I see no height difference when switching between Arimo and Liberation Sans
> on a random GitHub page.

Which version of liberation-fonts?

Comment 32 Jens Petersen 2018-07-17 08:36:07 UTC
Do you mean liberation-1.07.4-10.fc27?

I have seen difference in height rendering of digits at certain sizes
for Liberation 1, compared to version 2 which was more consistent.

Comment 33 Nikolaus Waxweiler 2018-08-25 09:07:03 UTC
Arimo freshly downloaded from GF (files say they're from 2010 when the last rework was done in 2013?!) as well as Liberation Sans liberation-sans-fonts-1:1.07.4-11.fc28.noarch and 2 as downloaded from https://pagure.io/liberation-fonts.

Comment 34 Pravin Satpute 2018-08-27 10:10:32 UTC
@Nikolaus How are you checking it?

Comment 35 Nikolaus Waxweiler 2018-08-27 18:41:19 UTC
By downloading Arimo from Google Fonts and LS 2.0 from Pagure and editing GitHub's CSS to take one or the other family. To compare to LS 1.x, I remove 2.0 from my ~/.fonts.

Comment 36 Jens Petersen 2018-10-16 08:07:35 UTC
Nikolaus, could you recap or summarize what you are suggesting or recommending?

Comment 37 Nikolaus Waxweiler 2018-10-16 09:04:18 UTC
Possible solution #1:

- Invest the time needed to fix https://github.com/fontforge/fontforge/issues/3052  or figure out a work-around (apparently 1.x has the same problem when compiled with "newer" FFs?)
- Package Git commit with the fix for Fedora
- Upgrade to 2.x

Possible solution #2 (maybe the best long-term solution):

- Invest time into porting the Liberation fonts source to UFO format, as that is the standard open (exchange) format if you ignore the 800 kg gorilla called Glyphs.app. We use it internally for storing and building from of our (commercial) projects, maintenance of the UFO world is better than of FontForge. Plus: better scriptability with e.g. fontParts.

Possible solution #3:

- Replace Liberation with Arimo/Cousine/Tinos from Google Fonts. There is no source for them, although according to the changelog, Liberation was initially made from the TTFs of Arimo/Cousine/Tinos... I don't know if there is any maintenance done on those, though.


PS: I just found https://github.com/liberationfonts/liberation-fonts. Nice.

Comment 38 Jens Petersen 2018-10-16 09:51:39 UTC
Thanks for the comments.

(In reply to Nikolaus Waxweiler from comment #37)
> - Upgrade to 2.x

Fedora 29 is updated to liberation-fonts 2.0

Comment 39 Nikolaus Waxweiler 2018-10-21 14:18:21 UTC
Well, uh-oh. If I drop Liberation Sans Regular (downloaded from https://github.com/liberationfonts/liberation-fonts/releases) and Arial Regular into http://www.cyreal.org/Font-Testing-Page/index.php, LSR modifies Layout as it seems to have less headroom. That does not happen with Arimo. This is a show-stopper.

Comment 40 Nikolaus Waxweiler 2018-10-21 14:41:33 UTC
Got it. The problem is that the build provided on https://github.com/liberationfonts/liberation-fonts/releases has the fsSelection bit 7 (USE_TYPO_METRICS) turned on (see https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fsselection), which modifies how applications calculate vertical metrics. Turning it of in a TTX dump and re-TTX-ing into a TTF makes the vertical metrics the same as Arial.

Comment 41 Nikolaus Waxweiler 2018-10-21 14:47:04 UTC
This flag can be turned off in Fontforge: Element -> Font Info -> OS/2 -> Metrics tab -> uncheck "Really use Typo metrics".

Yes, this is hairy and "why???"-level annoying.

Comment 42 vishalvvr 2018-12-12 05:33:12 UTC
This bug is already fixed with liberation 2.
Tried it on f28 and f29 with liberation-fonts 2.00.3, not able to reproducible it.

Comment 43 Nikolaus Waxweiler 2018-12-15 17:18:43 UTC
Can confirm for F29. I suppose this bug can be closed?

Comment 44 Jens Petersen 2018-12-16 08:15:30 UTC
(In reply to vishalvvr from comment #42)
> Tried it on f28 and f29 with liberation-fonts 2.00.3, not able to
> reproducible it.

F28 still has liberation-fonts-1.07.4-11.fc28

Comment 45 sachin 2019-04-03 10:43:48 UTC
Tested on F30 with Liberation-fonts-2.00.3-3  The issue is not reproducible anymore.


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