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

 
 

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

Submitted by:  None
Submitted on:  Sat 27 Aug 2011 09:52:10 PM UTC  
 
Severity: 3 - NormalItem Group: Incorrect behaviour
Status: InvalidPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project AdministratorIn charge of this item.
Wed 14 Sep 2011 07:24:36 AM UTC, comment #11:

I can confirm that metrics for bold and normal fonts in https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-ttf-1.06.0.20100721.tar.gz are the same while in https://fedorahosted.org/releases/l/i/liberation-fonts/liberation-fonts-ttf-1.07.0.tar.gz are not.

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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.

(file #23960)

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>
Project AdministratorIn charge of this item.
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.

(file #23958, file #23959)

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>
Project AdministratorIn charge of this item.
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.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #23960:  tabbed.png added by rkagan (55kB - image/png)
file #23958:  bad.png added by None (4kB - image/png - screenshots of "xterm -fa 'liberation sans mono' -fs 10")
file #23959:  good.png added by None (4kB - 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
  • -unavailable- added by rkagan (Updated the item)
  • -unavailable- added by rkagan ((comment #2 is from me))
  • -unavailable- added by wl (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 29 Sep 2011 09:47:23 PM UTCwlStatusNeed Info=>Invalid
      Open/ClosedOpen=>Closed
    Wed 14 Sep 2011 08:32:54 AM UTCwlSummaryFont metrix for DejaVu Sans wrong with 2.4.6=>Font metrics for DejaVu Sans/LiberationMono wrong with 2.4.6
    Fri 09 Sep 2011 02:27:11 PM UTCrkaganAttached File-=>Added tabbed.png, #23960
    Fri 09 Sep 2011 01:22:18 PM UTCrkaganCarbon-Copy-=>Added rkagan
    Fri 09 Sep 2011 11:29:07 AM UTCNoneAttached File-=>Added bad.png, #23958
      Attached File-=>Added good.png, #23959
    Tue 30 Aug 2011 06:16:52 AM UTCwlStatusNone=>Need Info
      Assigned toNone=>wl

    Back to the top


    Powered by Savane 3.1-cleanup