Bug 1336042

Note that I don't have any fonts from Microsoft installed. I doublechecked, Liberation fonts are used on websites on all systems.

Same thing happens after upgrading to F23, but for me it's only in Google Chrome. Fonts in Firefox look ok.

Which locale do you use?

It's German. de_DE.

en_US here.

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.

Yes, i can reproduce bug. Its tricky issue, trying to find root cause.

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?

(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?

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.

Created attachment 1211620 [details]
Comparison: left: COPR, right: fedorahosted

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.

Hm. The metrics in the OS/2 table appear identical in both LiberationSans-Regular.ttf files (from the site and in the archive).

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.

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.

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/.

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.

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)

Seems like the margin/padding above the glyphs is missing in the COPR Version just like in Liberation V1 from the official Fedora repository.

Is there any way to fix it in Fedora 25?

Thanks.

Yes. Use the files from fedorahosted.

Thanks, I've already used those. What I was looking for is an update to official rpm.

(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.

https://github.com/fontforge/fontforge/issues/3052

Hm!

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.

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.

Seems like nobody is interested in fixing it neither in FontForge itself nor in Fedora :(

Would it maybe make more sense to switch to Google's Arimo, Tinos and Couisine? The Liberation package is derived from those anyway...

Can we reproduce this issue with Arimo, Tonis and Couisine?

I see no height difference when switching between Arimo and Liberation Sans on a random GitHub page.

(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?

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.

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.

@Nikolaus How are you checking it?

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.

Nikolaus, could you recap or summarize what you are suggesting or recommending?

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.

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

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.

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.

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.

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.

Can confirm for F29. I suppose this bug can be closed?

(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

Tested on F30 with Liberation-fonts-2.00.3-3  The issue is not reproducible anymore.