This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 752538

Summary: gtk2 widgets too "tight"
Product: [Fedora] Fedora Reporter: Pierre Ossman <pierre-bugzilla>
Component: dejavu-fontsAssignee: Nicolas Mailhot <nicolas.mailhot>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: alphsteiner, behdad, bl.bugs, fonts-bugs, kevin, mclasen, mkasik, nicolas.mailhot, paul, peter
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 21:06:40 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Description Flags
Old gnome-terminal
New gnome-terminal
Python test program
Screenshot of U+2551 none

Description Pierre Ossman 2011-11-09 14:34:02 EST
I upgraded from Fedora 14 to Fedora 16, and now I'm having problems with some applications looking too cramped. The applications in question are claws-mail and xchat, so I guess it is something in GTK2 that isn't working correctly in our new, brave GTK3 world.

The problem seems to be that there is insufficient space between lines or rows.

In xchat, the problem is in the main chat widget. The user widget to the right looks fine.

In claws-mail, the problem can be seen both in the folder view and the message list (I believe these are both the same widget though). In the folder view you can even see some of the icons getting cropped.
Comment 1 Pierre Ossman 2011-11-10 06:43:55 EST
This might be a general font issue as I'm noticing that gnome-terminal (which should be GTK3) is a lot smaller than it's older variety (compared using X forwarding). The individual glyphs look the same though, so I guess something is broken with line spacing.
Comment 2 Pierre Ossman 2011-11-10 06:44:31 EST
I also configured DejaVu Mono 10pt for both terminals to make sure it was a good comparison.
Comment 3 Pierre Ossman 2011-11-10 06:58:42 EST
Created attachment 532806 [details]
Old gnome-terminal

This is the forwarded old gnome-terminal. The 'x' is 6x7 pixels, and the marker is 10x19 pixels.
Comment 4 Pierre Ossman 2011-11-10 07:00:20 EST
Created attachment 532807 [details]
New gnome-terminal

And here is the new gnome-terminal. The 'x' is still 6x7 pixels, so the glyph size seems to be the same. However, the marker is now 10x17 pixels, and also is intruding on the space of the line above.
Comment 5 Pierre Ossman 2011-11-16 06:31:04 EST
I'm seeing this in more places, so I'm guessing it has nothing to do with GTK. Moving to freetype, as I guess that's where things are getting the line spacing information from.
Comment 6 Pierre Ossman 2011-11-19 17:17:01 EST
Created attachment 534591 [details]
Python test program

Test program that gets the extents of "x" of DejaVu Sans Mono at 10pt via Pango.

On Fedora 16, I get:

((1, 5, 6, 7), (0, 0, 8, 15))
((1024, 5120, 6144, 7168), (0, 0, 8192, 15360))

Whilst Fedora 14 gives:

((1, 6, 6, 7), (0, 0, 8, 17))
((1024, 6144, 6144, 7168), (0, 0, 8192, 17408))

Note that last number there, which matches the line height.

And for more reference, RHEL 6:

((0, 5, 8, 8), (0, 0, 8, 17))
((0, 5120, 8192, 8192), (0, 0, 8192, 17408))

Not sure why the first set of numbers change so drastically. Could be hinting differences...
Comment 7 Pierre Ossman 2011-11-19 17:22:47 EST
Managed to find a Fedora 15 machine as well:

((1, 6, 6, 7), (0, 0, 8, 17))
((1024, 6144, 6144, 7168), (0, 0, 8192, 17408))

Relevant versions:




Comment 8 Pierre Ossman 2011-11-19 17:30:43 EST
Freetype is definitely the key component here. If I take the .so from F15 and use it on F16, I get the same line height.
Comment 9 Pierre Ossman 2011-11-19 18:14:35 EST
Dug up 2.4.5-1:

((1, 6, 6, 7), (0, 0, 8, 17))
((1024, 6144, 6144, 7168), (0, 0, 8192, 17408))

And also tried rawhide's 2.4.8-1:

((1, 5, 6, 7), (0, 0, 8, 15))
((1024, 5120, 6144, 7168), (0, 0, 8192, 15360))

So the problem appeared in 2.4.6, and is still present.
Comment 10 Pierre Ossman 2011-11-19 18:46:38 EST
A small release fortunately, and it has this in the release notes:

    - For TrueType based fonts, the ascender and descender values were
      incorrect sometimes  (off by a pixel if the ppem value was not a
      multiple of 5).   Depending on the use you might now  experience
      a different  layout; the  change should  result in  better, more
      consistent line spacing.

So if the previous rendering was technically incorrect, does that mean this is a DejaVu bug (and possibly other fonts as well) in that those fonts are specifying an insufficient ascent and descent? I doubt that the font designers intended it to be no spacing at all between lines.
Comment 11 Marek Kašík 2011-11-24 09:57:34 EST
Hi Pierre,

this behaviour was introduced by this commit to freetype.
The old behaviour was incorrect. The change was also discussed here:, and

So it is not a bug in freetype.

The only problematic thing here is the marker but it is probably a problem in gnome-terminal or pango.


Comment 12 Marek Kašík 2011-11-24 10:15:16 EST
*** Bug 746920 has been marked as a duplicate of this bug. ***
Comment 13 Pierre Ossman 2011-11-24 12:36:28 EST
Sorry, but I'm not willing to accept that everything's peachy.

I'm willing to concede that the fix in freetype is correct and the world is a much more beautiful place now that this bug is squashed (I know nothing about TrueType internals). But if you look at how U+2551 from DejaVu Mono is rendered, then something is obviously off.

This glyph is supposed to precisely span one line, so that it will seamlessly connect with an identical glyp above and below it. In reality, it gets a two pixel overlap at 10pt at 96 dpi.

If you do not feel that freetype is not to blame, then feel free to pass the buck elsewhere. Either to DejaVu for giving incorrect metrics, or Pango for using freetype incorrectly.
Comment 14 Pierre Ossman 2011-11-24 12:37:04 EST
Created attachment 535985 [details]
Screenshot of U+2551
Comment 15 Marek Kašík 2011-11-25 06:05:55 EST
Hi Pierre,

yes, you are right. When considering this again I should have reassigned this instead of close. Will remember it for next time.


Comment 16 Pierre Ossman 2011-12-06 11:52:42 EST
I installed FontForge and had a look at said glyph. Using the guide lines I determined that the ascent and descent is ~1990 and ~-620 respectively. This in contrast with the global values:

   ascent:          1901
   descent:         -483

So I guess this is clearly a bug in the font then?

Is there some way to override these settings to test?
Comment 17 Nicolas Mailhot 2011-12-07 05:56:02 EST
A problem at this level needs to be tackled upstream, let's see if eimai has an opinion here
Comment 18 Pierre Ossman 2011-12-15 14:15:37 EST
Any comments from upstream?
Comment 19 Pierre Ossman 2012-01-10 05:33:20 EST
Did you get in touch with upstream? Is there an upstream bug report?
Comment 20 Nicolas Mailhot 2012-01-10 05:49:07 EST
Ben Laenen is in copy, of this bug, you don't get more upstream than that

Though of course you can also try to open a bug in upstream's bugzilla
Comment 21 Pierre Ossman 2012-01-10 06:00:57 EST
I see. :)

For completeness sake, I've opened a bug upstream:

I'll continue the technical discussion there.
Comment 22 Fedora End Of Life 2013-02-13 21:06:44 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.