freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: mpsuzuki
Subject: [ft-devel] Re: Problem with OptaneCompactExtrabold.fam font suitcase
Date: Fri, 15 Feb 2008 15:54:08 +0900

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]