Bug 752538

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.

I also configured DejaVu Mono 10pt for both terminals to make sure it was a good comparison.

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.

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.

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.

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

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:

pango-1.28.1-3.el6_0.5.x86_64
freetype-2.3.11-6.el6_1.7.x86_64

pango-1.28.1-5.fc14.x86_64
freetype-2.4.2-5.fc14.x86_64

pango-1.28.4-1.fc15.x86_64
freetype-2.4.4-6.fc15.x86_64

pango-1.29.4-1.fc16.x86_64
freetype-2.4.6-3.fc16.x86_64

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.

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.

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.

Hi Pierre,

this behaviour was introduced by this commit http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=b0962ac34e66052ccfee7996e5468f30d4bd5a72 to freetype.
The old behaviour was incorrect. The change was also discussed here:
http://savannah.nongnu.org/bugs/?34507,
http://savannah.nongnu.org/bugs/?33939 and
http://savannah.nongnu.org/bugs/?34156.

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.

Regards

Marek

*** Bug 746920 has been marked as a duplicate of this bug. ***

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.

Created attachment 535985 [details]
Screenshot of U+2551

Hi Pierre,

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

Regards

Marek

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?

A problem at this level needs to be tackled upstream, let's see if eimai has an opinion here

Any comments from upstream?

Did you get in touch with upstream? Is there an upstream bug report?

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

I see. :)

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

https://bugs.freedesktop.org/show_bug.cgi?id=44624

I'll continue the technical discussion there.

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.