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 [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >>>> >>>> >>>> [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 >[email protected] >http://lists.nongnu.org/mailman/listinfo/freetype-devel -- 鈴木 _______________________________________________ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
