bugThe FreeType Project - Bugs: bug #35374, Glyphs are sometimes loaded and/or...

 
 

bug #35374: Glyphs are sometimes loaded and/or rendered inconsistently

Submitted by:  J. Edward Sanchez <spire>
Submitted on:  Thu 26 Jan 2012 02:21:14 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.

 

Mon 20 Feb 2012 06:30:20 AM UTC, comment #3:

You obviously haven't followed the thread...

In the thread's second email I wrote that the MS rasterizer exhibits exactly the behaviour, this is, changes in the CVT table with WCVTF and WCVTP within a glyph's bytecode are always global. Note that this is a very useful feature (for example, I use it in the bytecode produced by my ttfautohint program), and font developers have to be careful to avoid side effects.

I repeat: The problem is in the font. As the situation currently stands, I can't and won't do anything. Please contact the DejaVu team so that they fix this issue as soon as possible.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Mon 20 Feb 2012 12:40:12 AM UTC, comment #2:

Thanks for your reply.

My understanding from reading the thread you linked to is: The problem with DejaVu Sans is considered a non-issue because its GASP table specifies that the bytecode interpreter be disabled at 4 ppem (which is where the problem had previously been observed).

However, this does not help my situation because I'm seeing the same problem at 13 ppem (i.e., 10 points at 96 ppi). The GASP value for DejaVu Sans at 13ppem is FT_GASP_DO_GRIDFIT | FT_GASP_DO_GRAY. According to the FreeType documentation, FT_GASP_DO_GRIDFIT means that bytecode interpretation should be performed.

Unless I'm misunderstanding the situation, this indicates that the problem is more serious than originally reported. How should this problem be handled? My current workaround (described in my original post) is pretty unpleasant.

If you are open to considering a modification of FreeType's behavior to address the problem, my vote would be for option 2 as described in the thread: "WCVTP and WCVTF are allowed and are applied locally. All modified CVT entries are restored after rendering of [the problematic glyph]."

J. Edward Sanchez <spire>
Sun 29 Jan 2012 03:10:28 PM UTC, comment #1:

This is indeed a font bug. See the discussion in this thread:

http://lists.gnu.org/archive/html/freetype-devel/2011-09/msg00021.html

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Thu 26 Jan 2012 02:21:14 AM UTC, original submission:

I've identified what appears to be a bug in FreeType's bytecode interpreter: Under some circumstances, glyphs are loaded and/or rendered inconsistently by identical calls to FT_Load_Char()/FT_Load_Glyph().

I've found several cases where this happens. Here's how to reproduce one of them:

  1. Build FreeType version 2.4.8 (or the current revision, 7b02b7044321b1771b73465dd5c59b372906f8c4) using the default build options.
  2. Load the "DejaVu Sans" font (DejaVuSans.ttf from dejavu-fonts-ttf-2.33.zip).
  3. Set the font size to 10 points and the resolution to 96 pixels per inch.
  4. Load and/or render the "DIGIT ZERO" character (U+0030). Observe that the bounding box of the glyph is six pixels wide and nine pixels high.
  5. Load and/render the "DINGBAT NEGATIVE CIRCLED DIGIT FIVE" character (U+277A).
  6. Load and/or render the "DIGIT ZERO" character (U+0030) a second time. Observe that the bounding box of the glyph is now seven pixels wide and nine pixels high.

I would think it reasonable to assume that identical calls to FT_Load_Char()/FT_Load_Char() should produce identical results, and that this behavior constitutes a bug.

Because my application caches font metrics at startup and relies on calculations made from those cached metrics whenever it needs to render a glyph, this bug causes any affected glyphs to be rendered as garbage. I'm currently working around this by loading every single glyph in the font twice at startup and trusting the metrics only the second time around. Although this works, it's both inelegant and slow.

Disabling FreeType's bytecode interpreter by undefining TT_CONFIG_OPTION_BYTECODE_INTERPRETER or by specifying FT_LOAD_FORCE_AUTOHINT when loading glyphs makes the problem going away. In the specific example I used above, editing the font itself to remove the hinting instructions for U+277A also makes the problem go away.

It appears that there's something inside the hinting instructions for U+277A that is confusing FreeType's bytecode interpreter in such a way that its behavior changes for the rest of the font face's lifetime. I don't know what's so special about that one character, and I don't know enough about the internals of FreeType to investigate more deeply, but I hope this information serves as a good starting point for someone else.

J. Edward Sanchez <spire>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by wl (Posted a comment)
  • -unavailable- added by spire (Submitted the item)
  • -unavailable- added by spire
  •  

    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
    Sun 29 Jan 2012 03:10:28 PM UTCwlStatusNone=>Invalid
      Assigned toNone=>wl
      Open/ClosedOpen=>Closed
    Thu 26 Jan 2012 02:21:14 AM UTCspireCarbon-Copy-=>Added spire

    Back to the top


    Powered by Savane 3.1-cleanup1