bugThe FreeType Project - Bugs: bug #34156, Font metrics for DejaVu...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #34156: Font metrics for DejaVu Sans/LiberationMono wrong with 2.4.6

Submitter:  None
Submitted:  Sat 27 Aug 2011 09:52:10 PM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Invalid Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  None

Jump to the original submission

Wed 14 Sep 2011 12:45:15 PM UTC, comment #13: 

I've filed bug on liberation-fonts in Fedora's bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=738264

Roman Kagan <rkagan>
Wed 14 Sep 2011 08:31:08 AM UTC, comment #12: 

Thanks.  I've just downloaded version 1.07, and I can confirm the problem: The ascender difference between 1.06 and 1.07 is only two font units, but if you scale it, you get

  1705 / 2048 * 15 = 12.48779296875 -> 12
  1707 / 2048 * 15 = 12.50244140625 -> 13

(2048 font units equal 1em, and we are interested in 15ppem).

It's debatable whether this counts as a font bug (I would say yes).  However, I think that xterm could probably provide a better solution for such cases.

Note that the TrueType specification mandates rounding, not using floor and ceil, so the metrics correction applied by the font driver is justified.

Werner LEMBERG <wl>
Group administrator
Wed 14 Sep 2011 07:24:36 AM UTC, comment #11: 
Roman Kagan <rkagan>
Wed 14 Sep 2011 06:46:01 AM UTC, comment #10: 

Oops, sorry, I didn't notice that I experimented with freetype without commit 57b6a6148d072d30d7bcd071411316369190a57c which adds tracing to FT_Request_Size.

Now that indeed shows the difference:


# FT2_DEBUG=any:7 ./bin/ftview -r 106 10 /usr/share/fonts/liberation/LiberationMono-{Regular,Bold}.ttf 2>&1 |
 grep -F -e FT_Request_Metrics -e FT_Request_Size -A 8
FT_Request_Metrics:
  x scale: 30144 (0.459961)
  y scale: 30144 (0.459961)
  ascender: 13.000000
  descender: -5.000000
  height: 17.000000
  max advance: 9.000000
  x ppem: 15
  y ppem: 15
FT_Request_Size (font driver's `request_size'):
  x scale: 30720 (0.468750)
  y scale: 30720 (0.468750)
  ascender: 12.000000
  descender: -4.000000
  height: 17.000000
  max advance: 9.000000
  x ppem: 15
  y ppem: 15
--
FT_Request_Metrics:
  x scale: 30144 (0.459961)
  y scale: 30144 (0.459961)
  ascender: 13.000000
  descender: -5.000000
  height: 17.000000
  max advance: 9.000000
  x ppem: 15
  y ppem: 15
FT_Request_Size (font driver's `request_size'):
  x scale: 30720 (0.468750)
  y scale: 30720 (0.468750)
  ascender: 13.000000
  descender: -4.000000
  height: 17.000000
  max advance: 9.000000
  x ppem: 15
  y ppem: 15

So this raises two questions:

1) is it a font's bug or freetype's that the bold and the normal versions of the font have different metrics after FT_Request_Size at the same resolution and size?

2) which metrics should be used for rendering?

Roman Kagan <rkagan>
Tue 13 Sep 2011 06:21:50 PM UTC, comment #9: 

Here's a bit of new data:

seems like looking at the traces of FT_Request_Metrics as you suggested is not quite correct: in tt_size_request() the manipulations made by the commit mentioned by the original reporter are made after FT_Request_Metrics is run.  I.e. FT_Request_Metrics() indeed returns equal metrics for both normal and bold fonts; however, later in the code they are overridden by the metrics calculated in tt_size_reset() which are different.

Here are the metrics as found in tt_size_request() right after the call to tt_size_reset() (src/truetype/ttdriver.c:250):

normal font:

(gdb) p ttsize->root.metrics
$43 = {x_ppem = 15, y_ppem = 15, x_scale = 30016, y_scale = 30016, ascender = 832, descender = -320, height = 1088, max_advance = 576}
(gdb) p ttsize->metrics
$44 = {x_ppem = 15, y_ppem = 15, x_scale = 30720, y_scale = 30720, ascender = 768, descender = -256, height = 1088, max_advance = 576}


bold font:

(gdb) p ttsize->root.metrics
$46 = {x_ppem = 15, y_ppem = 15, x_scale = 30016, y_scale = 30016, ascender = 832, descender = -320, height = 1088, max_advance = 576}
(gdb) p ttsize->metrics
$47 = {x_ppem = 15, y_ppem = 15, x_scale = 30720, y_scale = 30720, ascender = 832, descender = -256, height = 1088, max_advance = 576}


Then ttsize->root.metrics is assigned ttsize->metrics (since that commit), and it's those metrics which are used by Xft/xterm (and this is why xterm's tracing reports different values from freetype's).

This doesn't look correct, but I'm too dumb in font handling to tell who's wrong here...

Roman Kagan <rkagan>
Tue 13 Sep 2011 09:20:23 AM UTC, comment #8: 

Thanks for the hint.  With FT tracing on, I get in xterm

FT_Request_Metrics:
  x scale: 30016 (0.458008)
  y scale: 30016 (0.458008)
  ascender: 13.000000
  descender: -5.000000
  height: 17.000000
  max advance: 9.000000
  x ppem: 15
  y ppem: 15

for both regular and bold fonts (liberation fonts 1.07 from Fedora 15).

However, xterm's own tracing reports the values I quoted in the previous comments: 17 (12 + 4) for regular and 17 (13 + 4) for bold.

Something's wrong with Xft or xterm's usage of Xft.

Roman Kagan <rkagan>
Mon 12 Sep 2011 07:07:03 PM UTC, comment #7: 

This difference in the global bbox (in font units) shouldn't be relevant; the bytecode used within the fonts assure that the height at the specified resolution is the same.  You should really try the ftview demo program of FreeType to see this.

Compile FreeType with `make devel; make', then use the statically linked ft2demo binary with

  FT2_DEBUG=any:7 \
  ftview -r 106 10 LiberationMono-Regular.ttf \
                   LiberationMono-Bold.ttf &> Liberation.log

Press `n' to display the second font, then `q' to quit the program, and you can find the following twice in the log file:

  FT_Request_Size (font driver's `request_size'):
    x scale: 30720 (0.468750)
    y scale: 30720 (0.468750)
    ascender: 12.000000
    descender: -4.000000
    height: 17.000000
    max advance: 9.000000
    x ppem: 15
    y ppem: 15

In other words, height, ascender, and descender are the same for Bold and Regular.

[This is Liberation version 1.06 at 106 dpi; you get the same metrics values for 105dpi.]

Something is fishy in xterm, it seems.

Werner LEMBERG <wl>
Group administrator
Mon 12 Sep 2011 05:46:41 PM UTC, comment #6: 

[ Sorry for hijacking the bug, I'm not totally sure this is the same problem as the original reporter had; let me know if I should better fork it into another bug ]

Upon brief investigation, I observe that at the resolution specified, the LiberationMono Regular and LiberationMono Bold have different metrics in Xft (as reported by xterm's tracing):

Regular: height = 17, ascent = 12, descent = 4
Bold:    height = 17, ascent = 13, descent = 4

This may explain the shift of bold glyphs down by one pixel (although I'd expect them to be baseline-aligned).


The fonts are indeed slightly different:

# diff -u <(ftdump /usr/share/fonts/liberation/LiberationMono-Bold.ttf) <(ftdump /usr/share/fonts/liberation/LiberationMono-Regular.ttf)
--- /dev/fd/63 2011-09-12 21:32:31.565813937 +0400
+++ /dev/fd/62 2011-09-12 21:32:31.565813937 +0400
@@ -4,8 +4,8 @@
 
 font name entries
    family:     Liberation Mono
-   style:      Bold
-   postscript: LiberationMono-Bold
+   style:      Regular
+   postscript: LiberationMono
 
 font type entries
    FreeType driver: truetype
@@ -15,10 +15,10 @@
    fixed width:     yes
    glyph names:     yes
    EM size:         2048
-   global BBox:     (-55,-615):(1259,1707)
-   ascent:          1707
+   global BBox:     (-50,-615):(1247,1705)
+   ascent:          1705
    descent:         -615
-   text height:     2322
+   text height:     2320
    glyph count: 673
 
 charmaps


Is is a bug in the fonts, or I should dig deeper in xterm?

Roman Kagan <rkagan>
Fri 09 Sep 2011 05:13:07 PM UTC, comment #5: 

Well, yes, xterm and gnome-terminal.  This isn't a guarantee for error-free code...

Thanks in advance for your assistance!  BTW, you might experiment with the Ahem font:

  http://hixie.ch/resources/fonts/

Note that FreeType exactly returns the expected metrics values.

[I've just added some more tracing code to the FreeType git repository: It now also displays the font driver's corrections to the size metrics.]

Werner LEMBERG <wl>
Group administrator
Fri 09 Sep 2011 02:27:11 PM UTC, comment #4: 

Well, "my terminal program" is actually xterm and gnome-terminal: two very popular terminal emulators, so quite a few users are affected...

I'm observing similar issues in some other gnome applications (e.g. see the tab labels in the attached shot of gedit).

I'll try to take a deeper look when I have a some time.


Roman Kagan <rkagan>
Fri 09 Sep 2011 01:20:57 PM UTC, comment #3: 

This `vertical jumping' only shows how your terminal program implements the positioning of glyphs.  If you use, say, the ftview program, you don't get this effect.

I still think that the current behaviour of FreeType is correct, and that the terminal program must be adjusted.  It's unfortunate, I know, but many other applications benefit from the fix of this long-standing bug.

It would be great if you could contact the maintainers of the affected terminal program (pointing to this bug report) so that they can comment.

Werner LEMBERG <wl>
Group administrator
Fri 09 Sep 2011 11:29:07 AM UTC, comment #2: 

I'm experiencing the same problem with Liberation Mono at 10 pt at 105.6 dpi: bold glyphs are 1 pixel lower than normal ones.

The same thing at 11pt renders OK.

Reverting the mentioned commit fixes the problem.


Anonymous
Tue 30 Aug 2011 06:16:52 AM UTC, comment #1: 

75dpi using which point size?  The default in xterm is 14.0pt, according to the man page.

With DejaVuSans 2.25, face->size->metrics.descender of the underscore glyph at this size (75dpi at 14pt is 15ppem) is -4.  If you open the font with FontForge and debug the bytecode of the underscore, you can also see that -4 is the correct value for the descender.

Please be more precise.  BTW, I've added some tracing code to FT_Request_Metrics; this simplifies the issue, I hope.

Werner LEMBERG <wl>
Group administrator
Sat 27 Aug 2011 09:52:10 PM UTC, original submission:  

Commit b0962ac34e66052ccfee7996e5468f30d4bd5a72 says to fix metrics for fonts. But for DejaVu Sans, it produces incorrect results. At dpi=75 for instance, xterm fails to display '_'.
My debugging shows that this char has a decent of -3 but the new font metrix say -2.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #23960:  tabbed.png added by rkagan (55KiB - image/png)
file #23958:  bad.png added by None (4KiB - image/png - screenshots of "xterm -fa 'liberation sans mono' -fs 10")
file #23959:  good.png added by None (4KiB - image/png - screenshots of "xterm -fa 'liberation sans mono' -fs 10")

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rkagan (Updated the item)
  • -email is unavailable- added by rkagan ((comment #2 is from me))
  • -email is unavailable- added by wl (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-29 wl StatusNeed Info Invalid
        Open/ClosedOpen Closed
    2011-09-14 wl SummaryFont metrix for DejaVu Sans wrong with 2.4.6 Font metrics for DejaVu Sans/LiberationMono wrong with 2.4.6
    2011-09-09 rkagan Attached File- Added tabbed.png, #23960
    2011-09-09 rkagan Carbon-Copy- Added rkagan
    2011-09-09 None Attached File- Added bad.png, #23958
        Attached File- Added good.png, #23959
    2011-08-30 wl StatusNone Need Info
        Assigned toNone wl

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code