Re: [ft] Carbon-free fonts support for Mac OS X 10.5 (Leopard) compatibility

[mpsuzuki]

Hi,

Just a few days ago, I found that freetype-2.3.5 cannot load
the resource fork TrueType font on Mac OS X if built without
--with-old-mac-fonts to include Carbon-based ftmac.c.
The freetype-2.3.4 (and possibly previous releases) could load
such fonts via Yamato-san's ftrfork.c even if built without
--with-old-mac-fonts. I recovered the functionalities on 2007-11-20.
Some LaserWriter PS font (the pair of "Helvetica LT MM" and
"HelvLTMM" etc) are not well supported yet, I will take a look
again.

Dipsy Po, please tell me about the safety of Carbon dependency.
Possibly removing Carbon dependency completely makes FreeType2
safe even in forked process. But switching to such FreeType2
(built without --with-old-mac-fonts) may cause troubles of
unresolved symbol. So, I'm thinking about the solution like
"Cabon symbols are linked but not used in execution". How do
you think of?

The next issue is the fallback when the access to resource
fork via "/rsrc" (and via "/..namedfork/rsrc" too?) is disabled.

As George said, I could generate warning
        "file access by '/rsrc' was deprecated in 10.4"
But I could not generate warning something like
        "file access by '/..namedfork/rsrc' was deprecated in 10.4"
So I'm not sure if it will be deprecated in future. I don't see
serious advantage of '/..namedfork/rsrc' in comparison with '/rsrc'.

I tried to access resource fork via getxattr() which was
introduced since Mac OS X 10.4 (getxattr() itself is not
a function by Apple designed for resource fork, but Apple's
getxattr() can access resource fork).

By giving "com.apple.ResourceFork" to getxattr() as a
name of extended attribute, I can copy the content of
resource fork to buffer. The structure is exactly same
with what I could access via "/rsrc" or "/..namedfork/rsrc".
The fallback is inserted into load_face_in_embedded_rfork(),
after the failure of all file-based access. Following
patch can do that.

Sorry it's not ready to propose as a committable patch.
I think such function should be included in ftrfork.c,
configure must check the availability of xattr.h, and
we have to care the compatibility with legacy Mac OS X
missing getxattr(). But I want to hear the comments on
such implementation.

Regards,
mpsuzuki

Index: src/base/ftobjs.c
===================================================================
RCS file: /cvsroot/freetype/freetype2/src/base/ftobjs.c,v
retrieving revision 1.287
diff -u -r1.287 ftobjs.c
--- src/base/ftobjs.c   20 Nov 2007 14:00:17 -0000      1.287
+++ src/base/ftobjs.c   23 Nov 2007 07:22:08 -0000
@@ -38,6 +38,8 @@
 
 #define GRID_FIT_METRICS
 
+#include <sys/xattr.h>
+
   FT_BASE_DEF( FT_Pointer )
   ft_service_list_lookup( FT_ServiceDesc  service_descriptors,
                           const char*     service_id )
@@ -1567,6 +1569,50 @@
 
 
   static FT_Error
+  load_face_in_xattr_rfork( FT_Library           library,
+                            FT_Stream            stream,
+                            FT_Long              face_index,
+                            FT_Face             *aface,
+                            const FT_Open_Args  *args )
+  {
+     FT_Memory  memory = library->memory;
+     FT_Error   error = FT_Err_Cannot_Open_Resource;
+     FT_Stream  stream2;
+     ssize_t    rfork_size;
+     char*      rfork_buff;
+     FT_UNUSED( stream );
+
+
+     rfork_size = getxattr( args->pathname, XATTR_RESOURCEFORK_NAME, NULL, 0, 
0, 0 );
+     if ( 0 >= rfork_size )
+       return FT_Err_Cannot_Open_Resource;
+
+     if ( FT_ALLOC( rfork_buff, rfork_size ) )
+       return FT_Err_Out_Of_Memory;
+
+     rfork_size = getxattr( args->pathname, XATTR_RESOURCEFORK_NAME, 
rfork_buff, rfork_size, 0, 0 );
+     if ( 0 < rfork_size )
+     {
+       if ( !FT_NEW( stream2 ) )
+       {
+         FT_Stream_OpenMemory( stream2, (const FT_Byte*)rfork_buff, rfork_size 
);
+         error = IsMacResource( library, stream2, 0, face_index, aface );
+         FT_FREE( stream2 );
+       }
+       else
+         error = FT_Err_Out_Of_Memory;
+     }
+     else
+       error = FT_Err_Cannot_Open_Resource;
+
+     if ( error )
+       FT_FREE( rfork_buff );
+
+     return error;
+  }
+
+
+  static FT_Error
   load_face_in_embedded_rfork( FT_Library           library,
                                FT_Stream            stream,
                                FT_Long              face_index,
@@ -1629,6 +1675,9 @@
         FT_FREE( file_names[i] );
     }
 
+    if ( error )
+      error = load_face_in_xattr_rfork( library, stream, face_index, aface, 
args );
+
     /* Caller (load_mac_face) requires FT_Err_Unknown_File_Format. */
     if ( error )
       error = FT_Err_Unknown_File_Format;










On 07 Nov 2007 09:46:11 -0800
George Williams <address@hidden> wrote:

>On Tue, 2007-11-06 at 19:59, Benjamin Reed wrote:
>
>> I was told it was deprecated by one of the Xar developers.
>
>Ah. A quick google search reveals nothing from Apple (thanks) but lots
>of people complaining about /rsrc being deprecated.
>
>If you look at /var/log/system.log you will see messages like:
>Nov 6 15:27:59 george-williams-powerbook-g4-12 kernel[0]: foo.c/rsrc
>file access by /rsrc was deprecated in 10.4
>
>On the other hand there seems to be another mechanism to get at it from
>POSIX
>    strcat(filename,"/..namedfork/rsrc")
>(using this does not cause a warning message to appear in my 10.5 system
>log). Said to work back to 10.3.
>
>However, there are warnings that ..namedfork doesn't work on all file
>systems.
>
>So my solution will be:
>   First try to append "/.....namedfork/rsrc"
>   If that fails try "/rsrc"
>
>Thanks for the heads up. Perhaps I should read /var/log/system.log more
>often!
>


-- 
鈴木