bugThe 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: 

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.

Werner LEMBERG <wl>
Group administrator
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?

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

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.

Werner LEMBERG <wl>
Group administrator
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?

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

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.

Werner LEMBERG <wl>
Group administrator
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.


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...

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.

Werner LEMBERG <wl>
Group administrator
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?

Note that the changed return values for global ascender and descender values do NOT influence the shape or the metrics of glyphs!

Werner LEMBERG <wl>
Group administrator
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


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, ...
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.

Werner LEMBERG <wl>
Group administrator
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)

Sergey Tereschenko <partizan>
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?

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.

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.

Werner LEMBERG <wl>
Group administrator
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.


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.

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.

Werner LEMBERG <wl>
Group administrator
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>

 

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

Attached Files
file #23752:  ftview.png added by partizan (178KiB - image/png - ftview results)
file #23742:  fonts compared.png added by partizan (118KiB - image/png - comparing fonts, old freetype at left, new at right)
file #23739:  urxvt.png added by partizan (23KiB - image/png)
file #23734:  f2.4.5.png added by partizan (102KiB - image/png - f2.4.5 - correct, f2.4.6 - decreased line height)
file #23735:  f2.4.6.png added by partizan (185KiB - image/png - f2.4.5 - correct, f2.4.6 - decreased line height)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by icesunrise (Voted in favor of this item)
  • -email is unavailable- added by icesunrise (Posted a comment)
  • -email is unavailable- added by razrfalcon (Voted in favor of this item)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by partizan (Submitted the item)
  •  

    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 StatusNeed Info Invalid
        Open/ClosedOpen Closed
    2011-08-04 partizan Attached File- Added urxvt.png, #23739
    2011-08-04 wl StatusNone Need Info
        Assigned toNone wl
    2011-08-03 partizan Attached File- Added f2.4.5.png, #23734
        Attached File- Added f2.4.6.png, #23735

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code