Bug 508899

Summary: Liberation Monospace no more with hinting
Product: [Fedora] Fedora Reporter: Yanko Kaneti <yaneti>
Component: liberation-fontsAssignee: Pravin Satpute <psatpute>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 13CC: arekm, behdad, bill-bugzilla.redhat.com, bmason, cody, conradsand.fb, fonts-bugs, i18n-bugs, K9, kevin, kolyshkin, mefoster, petersen, psatpute, sflaniga, superlance2k, sven, vansloot
Target Milestone: ---Keywords: i18n, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-03 00:51:58 UTC Type: ---
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
buggy monospace
none
yakuake htop freetype-2.3.11-3.fc12.x86_64 @400% none

Description Yanko Kaneti 2009-06-30 13:10:38 UTC
Created attachment 349951 [details]
buggy monospace

Description of problem:
The new liberaion-mono font from liberation-fonts-1.05.1.20090630-1.fc12 , no longer appears monospaced in verious applications (firefox, gedit). Attached a composite of the new and old monospaced font rendering of the same thing in gedit.

Comment 1 Caius Chance 2009-07-01 01:13:00 UTC
Hi, please gracefully provide test procedures and versions of applications used by:

$ rpm -q firefox; rpm -q gedit

Thank you very much.

Comment 2 Yanko Kaneti 2009-07-01 04:54:35 UTC
I am running rawhide. Currently

$ rpm -q xulrunner firefox gedit 
xulrunner-1.9.1-2.fc12.x86_64
firefox-3.5-1.fc12.x86_64
gedit-2.27.2-1.fc12.x86_64
fontconfig-2.7.0-1.fc12.x86_64
pango-1.24.3-1.fc12.x86_64

same result.

Comment 3 Yanko Kaneti 2009-07-01 06:22:36 UTC
The procedure:
1. Configure gedit to use Liberation Mono 10p
2. Create a text file containing
--- a/metadata/rb-metadata-gst.c
+++ b/metadata/rb-metadata-gst.c
3. Open the created text file with gedit

Observe non monospace layout of the text

Comment 4 Caius Chance 2009-07-01 06:30:07 UTC
Tested such font file on F11: not reproducible. May be the problems from rendering?

I need to test further when I am free.

Comment 5 Yanko Kaneti 2009-07-01 11:56:08 UTC
That's odd because I just tested the same koji liberation-fonts-1.05.1.20090630-1.fc12 rpm on uptodate F11 , and it produced the exact same effect.

Comment 6 Caius Chance 2009-07-06 06:53:24 UTC
Tested on F11 with:

$ pango-view  --font='Liberation Mono Regular' test_mono 

(test_mono has the contents in comment #3)

I guess is pango problem.

Comment 7 Caius Chance 2009-07-06 06:59:42 UTC
These also have monospace issues:

$ pango-view  --font='DejaVu Sans Mono:style=Book' test_mono

$ pango-view  --font='Nimbus Mono L:style=Bold Oblique' test_mono

Change component to pango.

Comment 8 Caius Chance 2009-07-06 07:14:29 UTC
Sorry it should be tested without suffix after and include ':'

$ pango-view  --font='Liberation Mono' test_mono 

$ pango-view  --font='DejaVu Sans Mono' test_mono

$ pango-view  --font='Nimbus Mono L' test_mono

Still tracing for source of bug.

Comment 9 Caius Chance 2009-07-08 01:07:28 UTC
Needs bug #503430 to get precondition correct, with traditional kern table conserved.

Comment 10 Caius Chance 2009-07-27 04:44:54 UTC
Tested with liberation-mono-fonts-1.05.1.20090630-1.fc12.noarch on both F11 and rawhide. Bug is reproducible. It may be hinting problem:

-----

$ pango-view  --font='Liberation Mono' --hinting='none' --dpi=200 test_mono

results: without problem, width of '-' and '+' are the same

-----

$ pango-view  --font='Liberation Mono' --hinting='full' --dpi=200 test_mono

results: with problem, width of '-' is shorter than '+'

Comment 11 Caius Chance 2009-07-27 04:47:41 UTC
previously couldn't reproduce because I was in ja_JP.UTF-8 which hinting was set off.

Comment 12 Behdad Esfahbod 2009-10-22 15:57:43 UTC
I believe this is fixed in freetype 2.3.10.  Building in rawhide.

Comment 13 Bug Zapper 2009-11-16 10:33:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 14 Yanko Kaneti 2009-11-25 06:29:40 UTC
rawhide currently has freetype 2.3.11 but I am still seeing this in gedit.

Comment 15 Bill McGonigle 2010-01-05 19:32:38 UTC
I see this in yakuake.  Switching to Deja Vu Mono gives me nicely aligned columns, back to Liberation Mono and not so much.

To test in yakuake, right click on the terminal and then edit the current profile.  The terminal updates immediately, so it's an easy test.

Comment 16 Bill McGonigle 2010-01-05 20:02:43 UTC
Yes, the test in comment #10 shows misalignment with full hinting here, good without.

pango-1.26.2-1.fc12.x86_64
freetype-2.3.11-3.fc12.x86_64

LANG=en_US.UTF-8

Comment 17 Kirill Kolyshkin 2010-01-25 08:43:47 UTC
*** Bug 557862 has been marked as a duplicate of this bug. ***

Comment 18 Bryan Mason 2010-01-28 22:59:49 UTC
FWIW, turning off system-wide hinting in gnome-appearance-properties in F12 made Liberation Mono look proper in Firefox.

Comment 19 Yanko Kaneti 2010-02-03 08:33:59 UTC
*** Bug 561259 has been marked as a duplicate of this bug. ***

Comment 20 Yanko Kaneti 2010-02-05 11:09:37 UTC
*** Bug 561318 has been marked as a duplicate of this bug. ***

Comment 21 C Sand 2010-02-05 13:43:36 UTC
Through having my bug report (561318) marked as a duplicate of an old bug, I can see that the original bug hasn't been fixed since 2009-06-30.  This is more than 7 months. There's no soft words to express this -- it's pathetic.

Even though this bug is marked as "low priority", it's a high-impact and high-visibility bug, affecting the professional appearance of Fedora, and hence the downstream RHEL 6 product.  What would an IT professional think of the rest of RHEL if we can't even get a simple font layout problem fixed ?

Is this a problem with the font or one of the layout engines?  Pango? GTK? Qt? X? Why isn't someone from Red Hat looking at this?

Comment 22 C Sand 2010-02-26 12:14:56 UTC
Reassigning to component "pango", as the bug is most likely to be there.

(also, this bug has existed since 2009-06-30 and nothing has been done about it)

Comment 23 Hans 2010-03-30 15:16:47 UTC
FWIW, when using this font in Windows 7, it is not recognized as a "proper" monospaced font.  This can be tested by attempting to select a display font in GVIM 7.2.  Not sure if this helps, I just thought I would throw it out there.

Comment 24 Arkadiusz Miskiewicz 2010-05-25 19:48:23 UTC
Hm, so where is this problem exactly? pango or freetype?

(pango 1.28, fretype 2.3.12 - bug reproducible)

Comment 25 superlance2k 2010-05-25 20:24:42 UTC
We have the same issue on Haiku OS which uses FreeType 2.3.12.  We do not use Pango.

Comment 26 Kevin Kofler 2010-07-28 11:26:03 UTC
Comment #15 is about Yakuake, a KDE 4 app which uses Qt 4's font rendering mechanism. So there too, only FreeType is the common element.

Comment 27 Bill McGonigle 2010-07-28 15:24:30 UTC
I filed an upstream bug:
  https://bugs.freedesktop.org/show_bug.cgi?id=29280

Please improve as needed.  I don't have permissions to set the external bug link here, so somebody please do that too.

Comment 28 Bill McGonigle 2010-07-28 18:48:45 UTC
Upstream says this is solved w/ 2.4.  I'm not able to reproduce with 2.3 on f13 (liberation mono 9 w/ yakuake w/ htop is OK now, my pango-view's look OK) - perhaps somebody who can reproduce can do a 2.4 build and verify?  I don't see any 2.4's in Koji, though.

Comment 29 Bill McGonigle 2010-07-28 19:07:59 UTC
Created attachment 435107 [details]
yakuake htop freetype-2.3.11-3.fc12.x86_64 @400%

no, I'm wrong, my eyes are bad.  Attaching a zoomed screenshot showing a p's left descender over the middle of an 'r'.  There is a preceding '-' - do the font metrics communicate across multiple characters with full hinting on?

Comment 30 Jens Petersen 2010-07-29 02:41:57 UTC
Slight hinting also looks ok to me.

Comment 31 Cody Boisclair 2010-08-02 23:19:35 UTC
This is likely fixed by the patch in Bug 620273. In short, as I found out, Liberation Mono *wasn't* technically a monospaced font in recent versions, because one character had the wrong width. The patch fixes this so that the font is properly identified as monospaced, making it so that the hinter doesn't alter character widths.

Comment 32 Sean Flanigan 2010-08-03 00:04:02 UTC
Yes, Cody's patched font fixes the problem for me, at least when viewing this text in Liberation Mono Regular 11 with Geany:

-------------------------------------
+++++++++++++++++++++++++++++++++++++

Thanks!

Comment 33 superlance2k 2010-08-03 00:13:37 UTC
With the patch, Haiku now identifies Liberation Monospace as a monospaced font.

Comment 34 Bill McGonigle 2010-08-03 00:18:06 UTC
I tried Cody's font files on my f13 box and put my nose to the screen.  I didn't see any obvious problems running an htop session in yakuake(Konsole renderer).

If I understand it correctly, this seems to be the breaking commit:

http://git.fedorahosted.org/git/?p=liberation-fonts.git;a=commitdiff;h=bb59c4be0e046d067fe112f2440798629ebb47d5

"Re-generated SFDs from original TTFs with newer method".  I wonder if 'newer method' introduced any other gremlins?  I'll re-add Caius, just in case.

So, is there any case where we'd want this font to work with the auto-hinter, or is that just a nonsensical question?

Comment 35 Cody Boisclair 2010-08-03 00:22:19 UTC
Whatever the "newer method" was, it fixed issues that affected bytecode hinting of certain characters in the 1.04 builds (which is of significance now that bytecode hinting is no longer patented).

Comment 36 Kevin Kofler 2010-08-03 00:51:58 UTC

*** This bug has been marked as a duplicate of bug 620273 ***