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
|
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.
|
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.
|
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?
|
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...
|
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.
|
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.
|
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?
|
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.]
|
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)
|
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.
|
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)
|
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.
|
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.
|