bugThe FreeType Project - Bugs: bug #36169, odd stretching with CFF font and...

 
 

bug #36169: odd stretching with CFF font and FT_LOAD_TARGET_LIGHT

Submitted by:  None
Submitted on:  Fri 13 Apr 2012 11:18:28 PM UTC  
 
Severity: 3 - NormalItem Group: None
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.

 

Mon 14 May 2012 11:22:00 PM UTC, comment #2:

Ah, ok, I hadn't realized that the FT_LOAD_TARGET_LIGHT flag switches from the native hinter to the autohinter. Looking at the docs, that is spelled out, so my fault for not reading carefully.

Thanks.

Derek Noonburg <derekn>
Tue 24 Apr 2012 01:18:14 PM UTC, comment #1:

The behaviour you see is a combination of various unfortunate effects.

. The subsetted font is not suited for being handled by the autohinter. To save space, it no longer contains valid mapping data from input character codes to glyph ID values. Instead, it abuses the standard Adobe encoding so that glyph names like `one' or `o' are used for the mathematical glyphs. FreeType trustfully maps them to the corresponding ASCII code points. Since FreeType's autohinter relies on a valid Unicode cmap within the font, it thinks that the font really contains ASCII glyphs.

. To find global parameters for hinting, various glyphs like `Z' and `i' are examined for height and depth values. This results in completely silly values for this font, causing spectacular failure you are observing.

To summarize, only use the autohinter for fonts which contain valid cmap files.

I've added a sentence to the FT_LOAD_XXX flags to emphasize that.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 13 Apr 2012 11:18:28 PM UTC, original submission:

I'm seeing some weird behavior with one CFF font when the FT_LOAD_TARGET_LIGHT flag is passed to FT_Load_Glyph.

The font is a subset that I pulled out of a PDF file. The "P" glyph is an uppercase sigma (summation symbol in an equation).

At smaller sizes, the character appears vertically stretched, i.e., the width is correct, but the height is too large. At tiny sizes, the character vanishes entirely. At larger sizes, the problem disappears (or at least isn't noticeable). If I remove the FT_LOAD_TARGET_LIGHT flag, the problem also disappears.

To reproduce:

ftview -l 1 -m PPPP 20 subset.t1c
ftview -l 1 -m PPPP 10 subset.t1c
ftview -l 1 -m PPPP 9 subset.t1c

At 20 pts, the character looks approximately normal (actually still a bit too tall). At 10 pts, it's the correct width, but still nearly the same height as at 20 pts. At 9 pts, it just vanishes.

If you drop the "-l 1" option, the output looks fine at all sizes.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #25638:  subset.t1c added by None (4KiB - application/octet-stream - problematic CFF font)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by derekn (Posted a comment)
  • -unavailable- added by wl (Posted a comment)
  •  

    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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 24 Apr 2012 01:18:14 PM UTCwlStatusNone=>Invalid
      Assigned toNone=>wl
      Open/ClosedOpen=>Closed
    Fri 13 Apr 2012 11:18:28 PM UTCNoneAttached File-=>Added subset.t1c, #25638

    Back to the top


    Powered by Savane 3.1-cleanup1