[ft-devel] improve Carbon-free MacOS font support

[mpsuzuki]

Dear Sirs,

As I enabled --with-old-mac-font by default since
freetype-2.2.1, I received several complaints from
MacOSX users/developers: it introduces new unexpected
dependency of Carbon frameworks (freetype-2.1.x is
independent with Carbon by default. Due to inflexible
dynamic linker of MacOSX, it disturbs the smooth
update of freetype2), and the parsing behaviour of
MacOS font differs from default behaviour of
freetype-2.1.x. For smooth migration from freetype-2.1.x,
I already disabled --with-old-mac-font by default.

freetype2 already includes Carbon-free MacOS font
support by Masatake Yamato. Although its behaviour is
slightly different from Carbon-based one, I want to
fix its behaviour and replace Carbon-based MacOS font
support by it. It is long way, so I want to start
by introductions of small improvements.

Here is typical example of the difference, reported
in gtk-i18n list:

http://mail.gnome.org/archives/gtk-i18n-list/2006-July/msg00008.html
http://mail.gnome.org/archives/gtk-i18n-list/2006-August/msg00004.html
https://www.codeblog.org/blog/mpsuzuki/20060817.html

fontconfig + freetype2 + Carbon-free MacOS font support
cannot count the number of sfnt resource in suitcase font
file, although they can access. fontconfig maintains its
database by num_faces counted by freetype2, thus it
can list the 1st face of suitcase font (e.g. "Courier"
in Courier.dfont), but cannot list the 2nd and later
(e.g. "Courier Bold" in Courier.dfont).

This is because Carbon-free MacOS font support cannot
return the number of multiple faces in suitcase font.
Originally, Carbon-based MacOS font support had similar
issue, I fixed it 2005-12-19. See:

http://lists.gnu.org/archive/html/freetype-devel/2005-12/msg00046.html

Following is a patch to return the number of sfnt resource
in suitcase font file, via aface->num_faces. It makes
possible that Carbon-free freetype2 can count the 2nd and
later faces in suitcase font.

However, the patched behaviour is not 100% compatible with
Carbon-based MacOS font support, because Carbon-free FOND
parser is not implemented yet.
# In some suitcase font, FOND resource synthesizes multiple
# faces from single sfnt resource. Thus, I introduced
#  face_index_internal to accept face_index which is greater
# the number of sfnt resource.

Anyway, I think the patched version has an advantage to
provide the access to "Courier Bold" in Courier.dfont,
without Carbon framework.

Yamato-san, how do you think of?

Regards,
mpsuzuki

--- freetype2.orig/src/base/ftobjs.c
+++ freetype2/src/base/ftobjs.c
@@ -1371,6 +1371,7 @@
     FT_Long    flag_offset;
     FT_Long    rlen;
     int        is_cff;
+    FT_Long    face_index_in_resource = 0;
 
 
     if ( face_index == -1 )
@@ -1402,7 +1403,7 @@
     error = open_face_from_buffer( library,
                                    sfnt_data,
                                    rlen,
-                                   face_index,
+                                   face_index_in_resource,
                                    is_cff ? "cff" : "truetype",
                                    aface );
 
@@ -1444,6 +1445,7 @@
       error = Mac_Read_POST_Resource( library, stream, data_offsets, count,
                                       face_index, aface );
       FT_FREE( data_offsets );
+      (*aface)->num_faces = 1; /* POST exists in a LWFN providing single face 
*/
       return error;
     }
 
@@ -1453,9 +1455,13 @@
                                         &data_offsets, &count );
     if ( !error )
     {
+      FT_Long face_index_internal = face_index % count;
+
+
       error = Mac_Read_sfnt_Resource( library, stream, data_offsets, count,
-                                      face_index, aface );
+                                      face_index_internal, aface );
       FT_FREE( data_offsets );
+      (*aface)->num_faces = count;
     }
 
     return error;