Created attachment 349951 [details]
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.
Hi, please gracefully provide test procedures and versions of applications used by:
$ rpm -q firefox; rpm -q gedit
Thank you very much.
I am running rawhide. Currently
$ rpm -q xulrunner firefox gedit
1. Configure gedit to use Liberation Mono 10p
2. Create a text file containing
3. Open the created text file with gedit
Observe non monospace layout of the text
Tested such font file on F11: not reproducible. May be the problems from rendering?
I need to test further when I am free.
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.
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.
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.
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.
Needs bug #503430 to get precondition correct, with traditional kern table conserved.
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 '+'
previously couldn't reproduce because I was in ja_JP.UTF-8 which hinting was set off.
I believe this is fixed in freetype 2.3.10. Building in rawhide.
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:
rawhide currently has freetype 2.3.11 but I am still seeing this in gedit.
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.
Yes, the test in comment #10 shows misalignment with full hinting here, good without.
*** Bug 557862 has been marked as a duplicate of this bug. ***
FWIW, turning off system-wide hinting in gnome-appearance-properties in F12 made Liberation Mono look proper in Firefox.
*** Bug 561259 has been marked as a duplicate of this bug. ***
*** Bug 561318 has been marked as a duplicate of this bug. ***
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?
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)
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.
Hm, so where is this problem exactly? pango or freetype?
(pango 1.28, fretype 2.3.12 - bug reproducible)
We have the same issue on Haiku OS which uses FreeType 2.3.12. We do not use Pango.
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.
I filed an upstream bug:
Please improve as needed. I don't have permissions to set the external bug link here, so somebody please do that too.
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.
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?
Slight hinting also looks ok to me.
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.
Yes, Cody's patched font fixes the problem for me, at least when viewing this text in Liberation Mono Regular 11 with Geany:
With the patch, Haiku now identifies Liberation Monospace as a monospaced font.
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:
"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?
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).
*** This bug has been marked as a duplicate of bug 620273 ***