bugThe FreeType Project - Bugs: bug #31995, AFM ascender / descender wronlgy...

 
 

bug #31995: AFM ascender / descender wronlgy interpreted

Submitted by:  Christian Neumair <manny>
Submitted on:  Tue 28 Dec 2010 11:40:40 AM 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 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)

Fri 31 Dec 2010 05:11:28 AM UTC, comment #7:

> The vertical centering of the small letters (rather than the
> entire text) as depicted in "unpatched.png" looked unusual to
> me


It's a matter of taste and depends on the intended purpose. To `ignore' descenders and ascenders while centering text vertically can be easily done if you use a value >= max(ascender, descender) for both ascender and descender.

I don't have a special opinion here because formatting of, say, menu entries is something completely different compared to proper layout for typographically oriented, multiline text of a printed documument. Don't forget that on paper, there is much more whitespace around the text (i.e., the paper margin), so the approach via `patched.png' might indeed be better for boxes without large whitespace boarders.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 31 Dec 2010 01:35:33 AM UTC, comment #6:

Thanks a lot for your explanation Werner! I think the information you just posted should be included in the FT2 FAQ.

The vertical centering of the small letters (rather than the entire text) as depicted in "unpatched.png" looked unusual to me, but indeed the font designer may well choose this, and it even looks quite smooth in menus once you are accustomed to it.

However, in my case the "small letter" vertical centering in GTK+ widgets did not work properly. Meanwhile, I found out that my problem seems to stem from the behavior of cairo 1.8.10. cairo_ft_scaled_font_create() includes the code

if (scaled_font->base.options.hint_metrics != CAIRO_HINT_METRICS_OFF ||
face->units_per_EM == 0) {
calculate font metrics from FT_Face's face->size->metrics
else {
calculate font metrics from FT_Face's own metrics
}

Removing the "scaled_font->base.options.hint_metrics != CAIRO_HINT_METRICS_OFF ||" check seemed to fix the vertical alignment. All labels look like "unpatched.png", and look cool. It might be due to some rounding problems for small font sizes, or some other FT internals I did not find the time to understand.

Long short story: Thank you for your feedback.

best regards,
Christian Neumair

Christian Neumair <manny>
Tue 28 Dec 2010 08:36:01 PM UTC, comment #5:

> The question to answer in the first place is: In a multiline
> text, how does one determine the "correct" (desired by the font
> designer) top and bottom spacing from the bounding box, the
> ascender and the descender?


The following can be found in the TrueType specification; this is fully valid for Type 1 fonts also:

"sTypoAscender is used to determine the optimum offset from
the top of a text frame to the first baseline.
sTypoDescender is used to determine the optimum offset from
the last baseline to the bottom of the text frame. The value
of (sTypoAscender - sTypoDescender) is recommended to equal
one em. [...]

For Western fonts, the `Ascender' and `Descender' fields in
Type 1 fonts' AFM files are a good source of `sTypoAscender'
and `sTypoDescender', respectively. The Minion Pro font
family (designed on a 1000-unit em), for example, sets
sTypoAscender = 727 and sTypoDescender = -273.

`sTypoAscender', `sTypoDescender' and `sTypoLineGap' specify
the recommended line spacing for single-spaced horizontal
text. The baseline-to-baseline value is expressed by:

OS/2.sTypoAscender - OS/2.sTypoDescender + OS/2.sTypoLineGap

`sTypoLineGap' will usually be set by the font developer such
that the value of the above expression is approximately 120%
of the em. The application can use this value as the default
horizontal line spacing. The Minion Pro font family
(designed on a 1000-unit em), for example, sets sTypoLineGap
= 200."

Does this answer your question? Note that Type 1 fonts don't have something equal to `sTypoLineGap'; TeX, for example, uses 120% by default, but most books use a larger value (e.g. 130%) which increases readability.

Not having the Frutiger PFB/AFM files, I can only say that `unpatched.png' looks much better to me.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 28 Dec 2010 03:24:36 PM UTC, comment #4:

PS: I patched Pango's pangoft2.c to attach the correct AFM file to the FT face.

Christian Neumair <manny>
Tue 28 Dec 2010 03:14:52 PM UTC, comment #3:

Thanks for your detailed explanation Werner! I totally agree that the ascender/descender is something that is determined by the designer. It seems that most libraries (cairo, pango) also misinterpret or misuse the ascender/descender.

Maybe I should have properly explained the actual issue I am trying to fix. When using the Type1 font FrutigerNext and AFM metrics, any GTK+ X11 text is vertically shifted compared to the expected position.

I'll attach two screenshots, both of which are the output of

pango-view --font="FrutigerNextLT 140" --dpi 72 --backend ft2 --text 'ABCD -- (un)patched'

with and without the patch I attached:

unpatched.png -- text vertically shifted towards top
patched.png -- text vertically centered

The question to answer in the first place is: In a multiline text, how does one determine the "correct" (desired by the font designer) top and bottom spacing from the bounding box, the ascender and the ascender?

Currently, the top and bottom spacing of any multi-line text is exclusively calculated with the ascender and descender provided by FT. It is derived from the bounding box without any AFM file (seemingly correct, patched.png), and from the AFM ascender/descender with the AFM file (seemingly incorrect, unpatched.png).

Do you know happen to know any freetype documentation how the absolute position of text should be calculated?

Thanks in advance!

best regards,
Christian Neumair

(file #22309, file #22310)

Christian Neumair <manny>
Tue 28 Dec 2010 02:15:28 PM UTC, comment #2:

With the last `incorrect' in the previous comment I mean that the global bbox for a CJK font is not suitable for proper ascender and descender values.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 28 Dec 2010 02:09:14 PM UTC, comment #1:

Thanks for your report. However, I disagree with your analysis. First of all, reading the AFM specification, I can't find a hint of your assertion that `ascender' and `descender' are local metrics values. On the contrary: Ascender and descender are always global! I think you've misinterpreted the sentences

ascender:
usually the y-value of the top of the lowercase d

descender:
typically the y-value of the bottom of the lowercase p

which essentially mean that single y-values (typically of the letters `d' and `p') are the ascender and descender values for all glyphs in a font.

Within a PFA or PFB file, there aren't global metric values except the global bbox, thus FreeType can only those values for guessing the ascender and descender. However, ascender and descender are design values not directly related to the physical dimensions of the glyphs in a font, so they often intentionally differ from the data in the PFA/PFB file.

The typical example is a CJK font: It is customary to assign the values ascender=800 and descender=200, however, not a single CJK glyph actually touches these y values; consequently, the global bbox (derived from all local bboxes) is smaller than the desired ascender and descender and thus incorrect.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Tue 28 Dec 2010 11:40:40 AM UTC, original submission:

This error report refers to freetype 2.3.11 on Ubuntu 10.04 LTS.

1. Open a Type1 PFB font, e.g., using FT_New_Face(). The ascender / descender are correctly calculated from the BBox, and correspond to ftdump()'s output.

2. Open the corresponding AFM file, e.g., using FT_Attach_File(). The ascender / descender suddently changed. They are incorrectly taken from the "Ascender" / "Descender" field of the AFM file. According to the Adobe Font Metrics File Format Specification v4.1 [1], they are however related to y values of x and d, i.e., NOT to the bounding box.

Attachment 1: A patch for the issue.

Notice that the bug is probably not observed by many users. Neither Cairo nor Pango's FT2 renderer attach any AFM files as of writing. I found the bug after hacking in AFM support.

Attachment 2: A small test program that displays the ascender / descender before and after the AFM attachment, to be compiled with `pkg-config --libs --cflags freetype2`. You will have to change AFM_FILENAME and PFB_FILENAME to existing files on your system.

Another problematic aspect of the current AFM handling is that the bounding box data is not compared to the original PFB file, but the former simply overwrites the latter. Size mismatches should be reported, or even lead to an abort.

best regards,
Christian Neumair

[1] http://partners.adobe.com/public/developer/en/font/5004.AFM_Spec.pdf

Christian Neumair <manny>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #22309:  unpatched.png added by manny (28KiB - image/png)
file #22310:  patched.png added by manny (26KiB - image/png)
file #22307:  testft.c added by manny (1KiB - text/x-csrc)
file #22305:  t1afm.diff added by manny (604B - text/x-patch - Proposed patch)
file #22306:  t1afm.diff added by manny (604B - text/x-patch - Proposed patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by manny (CCing Behdad Esfahbod, the GNOME font guru :o))
  • -unavailable- added by wl (Posted a comment)
  • -unavailable- added by manny (Submitted the item)
  •  

    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
    Tue 28 Dec 2010 03:14:52 PM UTCmannyAttached File-=>Added unpatched.png, #22309
      Attached File-=>Added patched.png, #22310
      Carbon-Copy-=>Added -unavailable-
    Tue 28 Dec 2010 02:09:14 PM UTCwlStatusNone=>Invalid
      Assigned toNone=>wl
      Open/ClosedOpen=>Closed
    Tue 28 Dec 2010 11:42:02 AM UTCmannyAttached File-=>Added testft.c, #22307
    Tue 28 Dec 2010 11:40:40 AM UTCmannyAttached File-=>Added t1afm.diff, #22305
      Attached File-=>Added t1afm.diff, #22306

    Back to the top


    Powered by Savane 3.1-cleanup1