bugThe FreeType Project - Bugs: bug #32902, Font file failed to load

 
 

bug #32902: Font file failed to load

Submitted by:  Jozef Baranec <joxy>
Submitted on:  Fri 25 Mar 2011 07:49:51 AM UTC  
 
Severity: 3 - NormalItem Group: None
Status: ConfirmedPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: 2.5.3

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Wed 19 Feb 2014 08:28:51 AM UTC, comment #4:

I've now applied the patch from sumatrapdf to fix this issue, thanks!

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 13 Sep 2013 04:50:37 PM UTC, comment #3:

We've just seen such a font in a PDF in the wild (cf. https://code.google.com/p/sumatrapdf/issues/detail?id=2408 ) and would also appreciate a fix since e.g. Adobe Reader handles that font just fine.

What about adding a new argument to T1_Get_Private_Dict to allow not skipping n whitespace characters before the eexec data and then retrying T1_Get_Private_Dict with an increased value for n whenever the parse_dict call fails with error 3 in T1_Open_Face (up to the point where n equals the number of whitespace between eexec and the first non-whitespace character)?

Or instead first decode the first 32 bytes and if they're obvious garbage re-add whitespace and re-decode until it either looks like Postscript or there's no whitespace left?

Anonymous
Fri 25 Mar 2011 11:09:51 AM UTC, comment #2:

To be more precise: I don't know an easy way to make this invalid font being accepted by FreeType (again).

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 25 Mar 2011 11:03:16 AM UTC, comment #1:

The font file is invalid. It can't be handled by either t1disasm or FontForge. Reason for the failure is that it violates one of the restrictions given in section 7.2, `eexec Encryption', of the T1 specification: The first byte after encryption has been applied must not be an ASCII white space character code (blank, tab, carriage return or line feed). In your font, the first encrypted byte is ^M. As a consequence, while decrypting, the ^M gets skipped because it immediately follows the newline character after `eexec', making it a CRLF pair.

It seems that the modified URW font has been created by FontForge; this would indicate a bug in this program. And indeed, looking into the source code of FontForge in the current git repository (file `dumppfa.c', functions `startfileencoding' and `encodebin'), I can't find a check which prevents the first encrypted byte from being whitespace.

I've CCed George to this bug report.

Unfortunately, I'm not sure how to fix that in FreeType. Any suggestions are highly welcomed.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 25 Mar 2011 07:49:51 AM UTC, original submission:

Attached font file fail to load. Function FT_New_Memory_Face returns error code 3.

It wor working fine in freetype version 2.3.11. I'm on the latest release not (4.2.4), but found that fail occurs from freetype 2.3.12.

Attached is file with font data.

Jozef Baranec <joxy>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #23008:  font.dat added by joxy (92kB - application/octet-stream)

 

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 wl
  • -unavailable- added by joxy (Submitted the item)
  • -unavailable- added by joxy
  •  

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

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 19 Feb 2014 08:28:51 AM UTCwlOpen/ClosedOpen=>Closed
      Planned ReleaseNone=>2.5.3
    Fri 25 Mar 2011 11:03:16 AM UTCwlStatusNone=>Confirmed
      Assigned toNone=>wl
      Carbon-Copy-=>Added pfaedit
    Fri 25 Mar 2011 07:49:51 AM UTCjoxyAttached File-=>Added font.dat, #23008
      Carbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup