Re: [ft-devel] Re: Problem with OptaneCompactExtrabold.fam font suitcase

[mpsuzuki]

Dear Deron Kazmaier,

Just I've committed your proposed patch to CVS head.
According to Apple Resource Manager Reference,
I think GetResource() and similar functions will never
returns a handle with undefined values. If error occurs,
they sets error AND returns NULL. So I simplified
the error checking by NULL handle only. In fact,
Get1Resource() is checked by NULL handle (without
ResError()) in other part of ftmac.c.

I wish if the bug you reported was closed, at present.

Regards,
mpsuzuki

On Fri, 15 Feb 2008 15:54:08 +0900
address@hidden wrote:

>Hi,
>
>Thank you for helpful comment that you can recontact with
>the bug reporter. At present, I'm a maintainer of ftmac.c
>(although I'm not the original author of it), so the limited
>permission for me to use the font during the debugging activity
>would be sufficient.
>
>On Thu, 14 Feb 2008 09:31:05 -0700
>Deron Kazmaier <address@hidden> wrote:
>>I do know that 7 unique faces were loaded from the suitcase, but it
>>reported 8 faces.
>
>I see, it's the exact point what I was interested in.
>I think you would agree FreeType2 should report 7 faces
>are available, not 8 faces, if it's possible to check
>without expensive cost.
>
>>While tracking this down I created some simple debug output that might
>>help answer your question as to face count being wrong. I can provide
>>the modified ftmac.c if you want to see where these calls come from.
>>Most is obvious. The log I have is as follows.
>
>Attached log is quite helpful. I have no sample fonts
>including multiple FONDs, but the font you reported
>has multiple FONDs. The sfnt_id for the 3rd face (which
>cannot be opened) looks like as if it's normal value,
>but GetResource() cannot open it.
>
>Thus, to exclude the 3rd face during the counting of
>available faces, we have to call GetResource(). Yet
>I have not evaluated the additional latency, but
>the repeating the parse of FOND for each faces and
>use GetResource() for each sfnt_id may be slightly
>too expensive. I will leave the unexpected behaviour
>of count_faces() including broken faces and apply your
>minimum workaround to avoid the crashing.
>
>So, you don't have to negociate with the original
>bug reporter about this issue. BUT, due to fragile
>Carbon since Mac OS X 10.5, I'm going to replace
>Carbon-dependent ftmac.c by Carbon-free support for
>legacy MacOS fonts. The Carbon-free have to parse
>the internal of resource fork by itself, so the font
>that caused this issue may cause different problem
>in Carbon-free impplementation. So I want you to
>negociate with the original bug reporter to give me
>the font, to prevent the issue in future release of FT2.
>
>Regards,
>mpsuzuki
>
>>FT_New_Face_From_Suitcase
>>path:/Users/deron/Fonts/IanHutchinson/OptaneCompactExtrabold.fam face:0
>>FT_New_Face_From_Suitcase res_index:1 num_faces_in_fond:4 fond:171735A0
>>FT_New_Face_From_FOND fond:171735A0 face_index:0
>>FT_New_Face_From_FOND fond_type:464F4E44 fond_id:2984
>>FT_New_Face_From_FOND #2
>>FT_New_Face_From_FOND #3
>>FT_New_Face_From_FOND #4
>>FT_New_Face_From_FOND #5
>>FT_New_Face_From_FOND #6
>>FT_New_Face_From_FOND #7
>>FT_New_Face_From_FOND #8
>>FT_New_Face_From_FOND #9
>>FT_New_Face_From_SFNT sfnt_id:18320
>>FT_New_Face_From_SFNT sfnt:171735A4
>>FT_New_Face_From_SFNT sfnt_size:52184
>>FT_New_Face_From_SFNT sfnt_data:1757D000
>>FT_New_Face_From_SFNT mem copied
>>FT_New_Face_From_SFNT
>>FT_New_Face_From_SFNT is_cff:0
>>FT_New_Face_From_FOND done:0
>>FT_New_Face_From_Suitcase res_index:2 num_faces_in_fond:2 fond:171735A4
>>FT_New_Face_From_Suitcase res_index:3 num_faces_in_fond:2 fond:171735A8
>>
>>FT_New_Face_From_Suitcase
>>path:/Users/deron/Fonts/IanHutchinson/OptaneCompactExtrabold.fam face:1
>>FT_New_Face_From_Suitcase res_index:1 num_faces_in_fond:4 fond:171735A0
>>FT_New_Face_From_FOND fond:171735A0 face_index:1
>>FT_New_Face_From_FOND fond_type:464F4E44 fond_id:2984
>>FT_New_Face_From_FOND #2
>>FT_New_Face_From_FOND #3
>>FT_New_Face_From_FOND #4
>>FT_New_Face_From_FOND #5
>>FT_New_Face_From_FOND #6
>>FT_New_Face_From_FOND #7
>>FT_New_Face_From_FOND #8
>>FT_New_Face_From_FOND #9
>>FT_New_Face_From_SFNT sfnt_id:16602
>>FT_New_Face_From_SFNT sfnt:171735A4
>>FT_New_Face_From_SFNT sfnt_size:51760
>>FT_New_Face_From_SFNT sfnt_data:1757D000
>>FT_New_Face_From_SFNT mem copied
>>FT_New_Face_From_SFNT
>>FT_New_Face_From_SFNT is_cff:0
>>FT_New_Face_From_FOND done:0
>>FT_New_Face_From_Suitcase res_index:2 num_faces_in_fond:2 fond:171735A4
>>FT_New_Face_From_Suitcase res_index:3 num_faces_in_fond:2 fond:171735A8
>>
>>FT_New_Face_From_Suitcase
>>path:/Users/deron/Fonts/IanHutchinson/OptaneCompactExtrabold.fam face:2
>>FT_New_Face_From_Suitcase res_index:1 num_faces_in_fond:4 fond:171735A0
>>FT_New_Face_From_FOND fond:171735A0 face_index:2
>>FT_New_Face_From_FOND fond_type:464F4E44 fond_id:2984
>>FT_New_Face_From_FOND #2
>>FT_New_Face_From_FOND #3
>>FT_New_Face_From_FOND #4
>>FT_New_Face_From_FOND #5
>>FT_New_Face_From_FOND #6
>>FT_New_Face_From_FOND #7
>>FT_New_Face_From_FOND #8
>>FT_New_Face_From_FOND #9
>>FT_New_Face_From_SFNT sfnt_id:12994
>>FT_New_Face_From_SFNT sfnt:171735A4
>>FT_New_Face_From_SFNT sfnt_size:55232
>>FT_New_Face_From_SFNT sfnt_data:1757D000
>>FT_New_Face_From_SFNT mem copied
>>FT_New_Face_From_SFNT
>>FT_New_Face_From_SFNT is_cff:0
>>FT_New_Face_From_FOND done:0
>>FT_New_Face_From_Suitcase res_index:2 num_faces_in_fond:2 fond:171735A4
>>FT_New_Face_From_Suitcase res_index:3 num_faces_in_fond:2 fond:171735A8
>>
>>FT_New_Face_From_Suitcase
>>path:/Users/deron/Fonts/IanHutchinson/OptaneCompactExtrabold.fam face:3
>>FT_New_Face_From_Suitcase res_index:1 num_faces_in_fond:4 fond:171735A0
>>FT_New_Face_From_FOND fond:171735A0 face_index:3
>>FT_New_Face_From_FOND fond_type:464F4E44 fond_id:2984
>>FT_New_Face_From_FOND #2
>>FT_New_Face_From_FOND #3
>>FT_New_Face_From_FOND #4
>>FT_New_Face_From_FOND #5
>>FT_New_Face_From_FOND #6
>>FT_New_Face_From_FOND #7
>>FT_New_Face_From_FOND #8
>>FT_New_Face_From_FOND #9
>>FT_New_Face_From_SFNT sfnt_id:4632
>>FT_New_Face_From_FOND done:32
>>FT_New_Face_From_Suitcase res_index:2 num_faces_in_fond:2 fond:171735A4
>>FT_New_Face_From_Suitcase res_index:3 num_faces_in_fond:2 fond:171735A8
>>
>>FT_New_Face_From_Suitcase
>>path:/Users/deron/Fonts/IanHutchinson/OptaneCompactExtrabold.fam face:4
>>FT_New_Face_From_Suitcase res_index:1 num_faces_in_fond:4 fond:171735A0
>>FT_New_Face_From_Suitcase res_index:2 num_faces_in_fond:2 fond:171735A4
>>FT_New_Face_From_FOND fond:171735A4 face_index:0
>>FT_New_Face_From_FOND fond_type:464F4E44 fond_id:2349
>>FT_New_Face_From_FOND #2
>>FT_New_Face_From_FOND #3
>>FT_New_Face_From_FOND #4
>>FT_New_Face_From_FOND #5
>>FT_New_Face_From_FOND #6
>>FT_New_Face_From_FOND #7
>>FT_New_Face_From_FOND #8
>>FT_New_Face_From_FOND #9
>>FT_New_Face_From_SFNT sfnt_id:2349
>>FT_New_Face_From_SFNT sfnt:171735A8
>>FT_New_Face_From_SFNT sfnt_size:51576
>>FT_New_Face_From_SFNT sfnt_data:1757D000
>>FT_New_Face_From_SFNT mem copied
>>FT_New_Face_From_SFNT
>>FT_New_Face_From_SFNT is_cff:0
>>FT_New_Face_From_FOND done:0
>>FT_New_Face_From_Suitcase res_index:3 num_faces_in_fond:2 fond:171735A8
>>
>>FT_New_Face_From_Suitcase
>>path:/Users/deron/Fonts/IanHutchinson/OptaneCompactExtrabold.fam face:5
>>FT_New_Face_From_Suitcase res_index:1 num_faces_in_fond:4 fond:171735A0
>>FT_New_Face_From_Suitcase res_index:2 num_faces_in_fond:2 fond:171735A4
>>FT_New_Face_From_FOND fond:171735A4 face_index:1
>>FT_New_Face_From_FOND fond_type:464F4E44 fond_id:2349
>>FT_New_Face_From_FOND #2
>>FT_New_Face_From_FOND #3
>>FT_New_Face_From_FOND #4
>>FT_New_Face_From_FOND #5
>>FT_New_Face_From_FOND #6
>>FT_New_Face_From_FOND #7
>>FT_New_Face_From_FOND #8
>>FT_New_Face_From_FOND #9
>>FT_New_Face_From_SFNT sfnt_id:3050
>>FT_New_Face_From_SFNT sfnt:171735A8
>>FT_New_Face_From_SFNT sfnt_size:56284
>>FT_New_Face_From_SFNT sfnt_data:1757D000
>>FT_New_Face_From_SFNT mem copied
>>FT_New_Face_From_SFNT
>>FT_New_Face_From_SFNT is_cff:0
>>FT_New_Face_From_FOND done:0
>>FT_New_Face_From_Suitcase res_index:3 num_faces_in_fond:2 fond:171735A8
>>
>>FT_New_Face_From_Suitcase
>>path:/Users/deron/Fonts/IanHutchinson/OptaneCompactExtrabold.fam face:6
>>FT_New_Face_From_Suitcase res_index:1 num_faces_in_fond:4 fond:171735A0
>>FT_New_Face_From_Suitcase res_index:2 num_faces_in_fond:2 fond:171735A4
>>FT_New_Face_From_Suitcase res_index:3 num_faces_in_fond:2 fond:171735A8
>>FT_New_Face_From_FOND fond:171735A8 face_index:0
>>FT_New_Face_From_FOND fond_type:464F4E44 fond_id:2594
>>FT_New_Face_From_FOND #2
>>FT_New_Face_From_FOND #3
>>FT_New_Face_From_FOND #4
>>FT_New_Face_From_FOND #5
>>FT_New_Face_From_FOND #6
>>FT_New_Face_From_FOND #7
>>FT_New_Face_From_FOND #8
>>FT_New_Face_From_FOND #9
>>FT_New_Face_From_SFNT sfnt_id:2594
>>FT_New_Face_From_SFNT sfnt:171735AC
>>FT_New_Face_From_SFNT sfnt_size:40240
>>FT_New_Face_From_SFNT sfnt_data:1757D000
>>FT_New_Face_From_SFNT mem copied
>>FT_New_Face_From_SFNT
>>FT_New_Face_From_SFNT is_cff:0
>>FT_New_Face_From_FOND done:0
>>
>>FT_New_Face_From_Suitcase
>>path:/Users/deron/Fonts/IanHutchinson/OptaneCompactExtrabold.fam face:7
>>FT_New_Face_From_Suitcase res_index:1 num_faces_in_fond:4 fond:171735A0
>>FT_New_Face_From_Suitcase res_index:2 num_faces_in_fond:2 fond:171735A4
>>FT_New_Face_From_Suitcase res_index:3 num_faces_in_fond:2 fond:171735A8
>>FT_New_Face_From_FOND fond:171735A8 face_index:1
>>FT_New_Face_From_FOND fond_type:464F4E44 fond_id:2594
>>FT_New_Face_From_FOND #2
>>FT_New_Face_From_FOND #3
>>FT_New_Face_From_FOND #4
>>FT_New_Face_From_FOND #5
>>FT_New_Face_From_FOND #6
>>FT_New_Face_From_FOND #7
>>FT_New_Face_From_FOND #8
>>FT_New_Face_From_FOND #9
>>FT_New_Face_From_SFNT sfnt_id:2855
>>FT_New_Face_From_SFNT sfnt:171735AC
>>FT_New_Face_From_SFNT sfnt_size:43128
>>FT_New_Face_From_SFNT sfnt_data:1757D000
>>FT_New_Face_From_SFNT mem copied
>>FT_New_Face_From_SFNT
>>FT_New_Face_From_SFNT is_cff:0
>>FT_New_Face_From_FOND done:0
>>
>>
>>> Hi,
>>>
>>> Thank you for very very quick reply.
>>>
>>> Umm, in the viewpoint of coding at atomic level,
>>> your suggestion to check the pointer returned by
>>> GetResource() is good idea, definitely.
>>>
>>> However, it makes me afraid there are more similar
>>> bugs are left that I have to fix. Following is my
>>> understanding of the crashing scenario.
>>>
>>> --
>>>
>>> * OptaneCompactExtraBold.fam includes multiple faces.
>>>   The FOND references in OptaneCompactExtraBold.fam
>>>   declare as if N (>= 7) sfnt faces are available
>>>   in total.
>>>
>>> * The declared total face number N is obtained by
>>>   summing the faces counted by count_faces_sfnt().
>>>   It parses memory image of each FOND header,
>>>   so it's independent with how Carbon counts the
>>>   included faces in given suitcase font file.
>>>
>>> * When FT2 tries to get the handle for the 3rd sfnt
>>>   resource by Carbon API GetResource() with sfnt_id
>>>   (sfnt_id is also obtained by direct parsing of FOND
>>>    image, independent with how Carbon calculates),
>>>   GetResource() successfully returns NULL handle.
>>>
>>>   The part you referred is slight confusing. The
>>>   resource type 'sfnt' is apparently known, in fact,
>>>   the 1st and 2nd sfnt resources could be accessed.
>>>   So, I guess, sfnt_id is invalid, or
>>>   sfnt_id is valid but the offset to access the sfnt
>>>   resource for given sfnt_id is broken, or
>>>   the data structure of the sfnt resource for the given
>>>   sfnt_id is broken, in the scope of Carbon implementation.
>>>
>>> --
>>>
>>> Anyway, FT2 is crashed when NULL sfnt handle is
>>> successfully returned. Your suggestion improves
>>> that FT2 can stand with such case.
>>>
>>> I will apply your suggestion, but I think that
>>> such broken faces should be excluded when the
>>> available faces in suitcase font file is being
>>> counted. If cannot exclude (or too expensive to
>>> check), appropriate error should be printed.
>>>
>>> So here are my 2 questions.
>>>
>>> * The NULL handle for 3rd sfnt resource is
>>>   casued by any problems in font file?
>>>   Or, caused by any reason out of font file?
>>>
>>> * After your fix, the 7 faces accessed by FT2
>>>   are all different? I'm afraid that 3rd and
>>>   4th faces are same.
>>>
>>> Regards,
>>> mpsuzuki
>>>
>>> On Wed, 13 Feb 2008 20:32:00 -0700
>>> Deron Kazmaier <address@hidden> wrote:
>>>
>>>   
>>>> Hello,
>>>>
>>>> I have no idea where the font can be obtained legally. The user was not 
>>>> clear as to copyright and I deleted the font after getting it to work. I 
>>>> can recontact him about getting any details you might need such as 
>>>> copyright holder for the font.
>>>>
>>>> I also should mention that the Apple Docs for GetResource states:
>>>>
>>>> "... If you call GetResource with a resource type that can’t be found in 
>>>> any of the resource maps of the open resource forks, the function 
>>>> returns NULL, but ResError returns the result code noErr. You should 
>>>> always check that the value of the returned handle is not NULL...."
>>>>
>>>> Let me know what I can do to help,
>>>>
>>>> Deron
>>>>
>>>>
>>>> address@hidden wrote:
>>>>     
>>>>> Hi,
>>>>>
>>>>> I checked google but all OptaneCompactExtraBold I could
>>>>> download were for Windows TTF (including only 1 face).
>>>>> Could you tell me where I can download the suitcase version?
>>>>>
>>>>> Regards,
>>>>> mpsuzuki
>>>>>
>>>>> On Sat, 02 Feb 2008 12:42:06 -0700
>>>>> Deron Kazmaier <address@hidden> wrote:
>>>>>   
>>>>>       
>>>>>> A Mac user provided to me a font suitcase file 
>>>>>> (OptaneCompactExtrabold.fam) that crashes FreeType (2.3.5 and latest 
>>>>>> CVS) when referencing face index #3. I tracked it down to the first call 
>>>>>> in FT_New_Face_From_SFNT (ftmac.c).
>>>>>>
>>>>>>    sfnt = GetResource( FT_MAKE_TAG( 's', 'f', 'n', 't' ), sfnt_id );
>>>>>>    if ( ResError() )
>>>>>>      return FT_Err_Invalid_Handle;
>>>>>>
>>>>>> GetResource would return 0, but ResError did not return true. Checking 
>>>>>> for a NULL handle was required to get FreeType to skip it without 
>>>>>> crashing.
>>>>>>
>>>>>>    if ( sfnt == NULL || ResError() )
>>>>>>      return FT_Err_Invalid_Handle;
>>>>>>
>>>>>> I can now access the 7 faces that is reported to be inside with this 
>>>>>> change.
>>>>>> Hope that is helpful.
>>>>>>         
>
>
>_______________________________________________
>Freetype-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/freetype-devel


-- 
鈴木