The FreeType Project - Bugs: bug #33939, Incorrect line height for...
You are not allowed to post comments on this tracker with your current authentication level.
bug #33939: Incorrect line height for monospaced fonts in 2.4.6
Submitter: | Sergey Tereschenko <partizan> | ||
Submitted: | Wed 03 Aug 2011 05:29:16 PM UTC | ||
Votes: | 200 | ||
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 07 Sep 2011 06:25:50 PM UTC, comment #16: |
Werner LEMBERG <wl> |
Wed 07 Sep 2011 10:09:29 AM UTC, comment #15: Hello!
|
Dmitry Bigunyak <icesunrise> |
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).
|
Werner LEMBERG <wl> |
Sat 06 Aug 2011 09:43:59 AM UTC, comment #13: Thanks for help :)
|
Sergey Tereschenko <partizan> |
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).
|
Werner LEMBERG <wl> |
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).
|
Sergey Tereschenko <partizan> |
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...
|
Werner LEMBERG <wl> |
Fri 05 Aug 2011 05:57:51 PM UTC, comment #9: I mean "too small glyph height" or "too big glyph width" |
Sergey Tereschenko <partizan> |
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?
|
Werner LEMBERG <wl> |
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.
|
Sergey Tereschenko <partizan> |
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, ...
|
Werner LEMBERG <wl> |
Thu 04 Aug 2011 09:37:55 PM UTC, comment #5: old and new, 9pt: 7/9, 0.77
|
Sergey Tereschenko <partizan> |
Thu 04 Aug 2011 09:27:29 PM UTC, comment #4: Hello again.
|
Sergey Tereschenko <partizan> |
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.
|
Werner LEMBERG <wl> |
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.
|
Sergey Tereschenko <partizan> |
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.
|
Werner LEMBERG <wl> |
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) |
Sergey Tereschenko <partizan> |
Depends on the following items: None found
Items that depend on this one: None found
There are 200 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 11 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2011-09-07 | icesunrise | Carbon-Copy | - | Added icesunrise | |
2011-08-05 | partizan | Attached File | - | Added ftview.png, #23752 | |
2011-08-05 | razrfalcon | Carbon-Copy | - | Added razrfalcon | |
2011-08-05 | partizan | Attached File | - | Added fonts compared.png, #23742 | |
2011-08-04 | wl | Status | Need Info | Invalid | |
Open/Closed | Open | Closed | |||
2011-08-04 | partizan | Attached File | - | Added urxvt.png, #23739 | |
2011-08-04 | wl | Status | None | Need Info | |
Assigned to | None | wl | |||
2011-08-03 | partizan | Attached File | - | Added f2.4.5.png, #23734 | |
Attached File | - | Added f2.4.6.png, #23735 |
Powered by Savane 3.13-4448.
Corresponding source code
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.