Wed 07 Sep 2011 06:25:50 PM UTC, comment #16:
To get a larger font, the solution is obvious: Select a larger font.
To get a larger baseline distance: Ask the gvim maintainer to implement this. What you see right now is the line distance as envisioned by the font designer.
It's a pity that FreeType had this bug for such a long time, and that it is the duty of the applications to restore the old (incorrect) behaviour.
|
Wed 07 Sep 2011 10:09:29 AM UTC, comment #15:
Hello!
After upgrade to freetype-2.4.6 I've found significant changes in monospace font rendering in my gvim application. The font itself and spacing between lines became smaller. I've read all previous posts but couldn't understand how can I return the old rendering style?
|
Sun 07 Aug 2011 05:27:34 AM UTC, comment #14:
Since version 2.4.5, a TrueType font without hints will be automatically handled by the autohinter (except if you explicitly disable autohinting).
I'm quite sure that the fonts you are using are well-hinted ones. Within your fontconfig setup, you must override the global `light hinting' mode (which implies that autohinting is always used) with native hinting mode for those fonts.
|
Sat 06 Aug 2011 09:43:59 AM UTC, comment #13:
Thanks for help :)
And my last questions:
Hinting. Every font must contains instructions for rendering hinted fonts? Or if this instructions was not found renderer will use autohinter?
If we can not influence values selected by autohinter, maybe we can provide right hinting instructions for the font?
|
Sat 06 Aug 2011 05:06:21 AM UTC, comment #12:
Ah, yes, I forgot that (and you need the -r 96 flag for ftview to see the size jumping).
However, the new ascender and descender values are the correct ones, I still believe. The autohinter uses them to compute the blue zones for aligning the outline to it; this explains the different vertical sizes in 2.4.6.
And to anticipate your question: No, the vertical size selected by the autohinter for a given ppem value can't be influenced; we've never guaranteed that the autohinter will yield identical results in different FreeType versions.
And that you see different advance widths for a mono-width font with 2.4.5 if you force autohinting and switch hinting on and off is clearly inferior to the new, fixed behaviour.
|
Fri 05 Aug 2011 09:14:23 PM UTC, comment #11:
I think i was found who changes height of glyphs. It is hinting(autohinting in ftview, and slight hinting in gtk apps).
with hinting disabled old vesion and new produces the same output, but with hinting height of glyphs (for some font size) increased a little.
on attached screenshot at left old vesion, at right - new. at top - hinting enabled, at bottom - disabled.
(file #23752)
|
Fri 05 Aug 2011 08:32:19 PM UTC, comment #10:
Hmm. In case the application doesn't fiddle around with the value of height, depth, or width, they are given by the font...
Please try ftview and look how DejaVuSansMono gets rendered. If you compare 2.4.6 with a previous version, the only small horizontal difference is how the waterfall gets rendered (after pressing key `6').
My corollary is that your application (or the used framework) simply selects a different font size to fit into the now correctly given global ascender and descender.
You should really contact the GTK people.
|
Fri 05 Aug 2011 05:57:51 PM UTC, comment #9:
I mean "too small glyph height" or "too big glyph width"
|
Fri 05 Aug 2011 05:52:04 PM UTC, comment #8:
What do you mean with `squashed' in the image comments? A too small baseline distance?
Note that the changed return values for global ascender and descender values do NOT influence the shape or the metrics of glyphs!
|
Fri 05 Aug 2011 08:39:05 AM UTC, comment #7:
I don't exepc to see any linear relation nor execly matching of aspect ratio.
But i expect that aspect ratio can differ as little as possible for different font sizes.
Thanks for test font, but i can't use it, becouse of affected only monospaced fonts(DejaVu Sans Mono and Monaco at least). Hmmm, and Droid Sans Mono not. Maybe it's font related issue?
// attached another screenshot, you can observer font squashing
(file #23742)
|
Thu 04 Aug 2011 10:09:26 PM UTC, comment #6:
There is no linear relationship between width and height due to rounding to integer values! I already told you that some ppem pairs use the same widths; here an extended list (unit is ppem): 8/9, 11/12, 13/14, 16/17, 18/19, 21/22, 23/24, 26/27, 28/29, ...
In other words, it is not possible to get reliable estimates if you rely on the aspect ratio.
There is a special font which has been explicitly designed for testing glyph height, width, and baseline distances:
http://www.w3.org/Style/CSS/Test/Fonts/Ahem/
maybe you can use it for further tests.
|
Thu 04 Aug 2011 09:37:55 PM UTC, comment #5:
old and new, 9pt: 7/9, 0.77
old and new, 12pt: 10/12 0.83
with this sizes old and new behavior exactlu the same.
this aspect ratio close to 0.8, so i can suggest that correct values for 10pt is 8/10(old), and for 11 9/12(new)
|
Thu 04 Aug 2011 09:27:29 PM UTC, comment #4:
Hello again.
I was measured font sizes with old and new freetype
letter "M" with DejaVu Sans Mono at 96 dpi.
version, size: width/height(pixels) aspect_ratio
old, 10pt: 8/10 0.8
old, 11pt: 9/10 0.9
new, 10pt: 8/9 0.888...
new, 11pt: 9/12 0.75
old font with 11pt size looks like new 10pt and
old 11pt like new 10pt.
maybe here is incorrect values again, but for differet font sizes?
|
Thu 04 Aug 2011 09:40:56 AM UTC, comment #3:
The spacing between lines is usually dependent on the application. TeX, for example, ignores the font's values completely. Instead, you have to explicitly specify the baseline distance. Other applications might vertically insert some additional pixels to increase the baseline distance.
I don't think that fontconfig provides an interface to manipulate font properties. Maybe GTK2, as you've already concluded, provides access to them.
For now, I'm closing this report. In case you have new informations please don't hesitate to re-open the issue.
|
Thu 04 Aug 2011 08:25:32 AM UTC, comment #2:
On my screenshots it is not a terminal, it's gvim. But gnome-terminal show the same result, so we can suggest is gtk-related issue.
I was checked another terminal (rxvt-unicode, attached screenshot). With 2.4.5 font looks too wide, with 2.4.6 a little better(just as in gnome-terminal and gvim).
I checked also other font sizes, 11pt fonts looks exactly the same on 2.4.5 and 2.4.6.
I don't think i must contact with maintainers of gnome-terminal or gvim, instead i try to find someone maintaining gtk2.
And maybe here is a way to specify correct (or "incorrect" in my case) values for ascender and descender? like ~/.fonts.conf, or so.
(file #23739)
|
Thu 04 Aug 2011 06:35:44 AM UTC, comment #1:
It is expected that some fonts get rendered at smaller sizes, yes, because the ascender and descender values of fonts have been returned incorrectly in many cases (this is, one pixel too large). The question is whether the line height is indeed incorrect, as you maintain, or whether you are just accustomed to the old behaviour.
To decide that, I need more information. Unfortunately, your screen shots don't give enough clues to identify the problem (if it actually is a problem at all). If possible, please contact the maintainer of your terminal program so that he or she can investigate the issue.
Note that DejaVuSansMono uses exactly the same advance values for 13ppem and 14ppem; it seems that the application has now chosen to select 13ppem instead of 14ppem. Have you tried to increase the used font size? At 72dpi, this is 13pt vs. 14pt; at 96dpi (as used by Windows), it is 9.75pt vs. 10.5pt.
|
Wed 03 Aug 2011 05:29:16 PM UTC, original submission:
After updating to 2.4.6 line height of monospaced fonts was decreased (DejaVu Sans Mono on screenshot)
|