Re: [ft-devel] aface-num_faces of FT_New_Face() in ftmac.c

2005-12-18 Thread mpsuzuki
Hi all,

Attached is patch for ftmac.c, make it to return the number
of unique scalable faces. I've tested with TrueType fonts
bundled to MacOS. The functionalities for resource-fork based
PS font (LWFN font) are not tested at all (although I think
I don't change behaviour for LWFN resource), please give me
informations about where I can obtain from.

Also I attached ftoldmac.c that is (unifinished) small test
program: scanning fonts in a directory and passing them to
FT_New_Face_From_FSSpec(). If anybody interested in regression
test, ask me to hurry for the documentation.

NOTE: this is a part of forthcoming jumbo patch to fix ftmac.c's
  obsolete functions issue on Tiger.

Regards,
mpsuzuki




original patched
 ---
* face-num_faces is always 0* face-num_faces is the number of
   included sfnt or LWFN resource

* face-num_fixed_size is set* face-num_fixed_size is set
  to the number of embeddedto the number of embedded
  bitmap in sfnt resource. bitmap in sfnt resource.
   The number of NFNT resource is
   ignored.
  
* face index counts both of  * face index does not count NFNT
  sfnt and NFNT resource,  resource (until the day NFNT
  although FT_New_Face()   bitmap font is supported).
  with the face index to
  NFNT resource returns the
  previous sfnt resource.
  In following example,
  when you call face 1/2/3,
  you receive face 0.


  +-+- sfnt A  face 0  +--+- sfnt A  face 0
  | |  |  |
  | +- NFNT A1 face 1  |  +- NFNT A1   x
  | +- NFNT A2 face 2  |  +- NFNT A2   x
  | +- NFNT A3 face 3  |  +- NFNT A3   x
  ||
  +-+- sfnt B  face 4  +--+- sfnt B  face 1
  | |  |  |
  | +- NFNT B1 face 5  |  +- NFNT B1   x
  | +- NFNT B2 face 6  
  | +- NFNT B3 face 7
  |
  

--- freetype2.orig/src/base/ftmac.c 2005-12-14 09:10:29.0 +0900
+++ freetype2_ftmacfix/src/base/ftmac.c 2005-12-14 10:42:49.0 +0900
@@ -23,15 +23,11 @@
 support this I use the face_index argument of FT_(Open|New)_Face()
 functions, and pretend the suitcase file is a collection.
 
-Warning: Although the FOND driver sets face-num_faces field to the
-number of available fonts, but the Type 1 driver sets it to 1 anyway.
-So this field is currently not reliable, and I don't see a clean way
-to  resolve that.  The face_index argument translates to
-
-  Get1IndResource( 'FOND', face_index + 1 );
-
-so clients should figure out the resource index of the FOND.
-(I'll try to provide some example code for this at some point.)
+Warning: fbit and NFNT bitmap resources are not supported yet.
+In old sfnt fonts, bitmap glyph data for each sizes are stored in
+each NFNT resources, instead of bdat table in sfnt resource.
+Therefore, face-num_fixed_sizes is set to 0, because bitmap
+data in NFNT resource is unavailable at present.
 
 The Mac FOND support works roughly like this:
 
@@ -267,6 +263,8 @@
   }
 
 
+  /* count_faces_sfnt() counts both of sfnt  NFNT refered by FOND */
+  /* count_faces_scalable() counts sfnt only refered by FOND   */
   static short
   count_faces_sfnt( char *fond_data )
   {
@@ -277,6 +275,28 @@
   }
 
 
+  static short
+  count_faces_scalable( char *fond_data )
+  {
+AsscEntry*  assoc;
+FamRec* fond;
+short   i, face, face_all;
+
+
+fond   = (FamRec*)fond_data;
+face_all   = *( (short *)( fond_data + sizeof ( FamRec ) ) ) + 1;
+assoc  = (AsscEntry*)( fond_data + sizeof ( FamRec ) + 2 );
+face   = 0;
+
+for ( i = 0; i  face_all; i++ )
+{
+  if ( 0 == assoc[i].fontSize )
+face ++;
+}
+return face;
+  }
+
+
   /* Look inside the FOND data, answer whether there should be an SFNT
  resource, and answer the name of a possible LWFN Type 1 file.
 
@@ -411,7 +431,7 @@
 if ( have_lwfn  ( !have_sfnt || PREFER_LWFN ) )
   return 1;
 else
-  return count_faces_sfnt( *fond );
+  return count_faces_scalable( *fond );
   }
 
 
@@ -744,36 +764,33 @@
  FT_Long face_index,
  FT_Face*aface )
   {
-FT_Error  error = FT_Err_Ok;
+FT_Error  error = FT_Err_Cannot_Open_Resource;
 short res_index;
 Handlefond;
-short num_faces;
+short num_faces_in_res, num_faces_in_fond;
 
 
 UseResFile( res_ref );
 
+num_faces_in_res = 0;
 for ( res_index = 1; ; ++res_index )
 {
   fond = Get1IndResource( 'FOND', res_index );
   if ( ResError() )
-  {
-error = FT_Err_Cannot_Open_Resource;
-goto Error;
-  }
-  if ( face_index  0 )
 break;
 
-  

Re: [ft-devel] aface-num_faces of FT_New_Face() in ftmac.c

2005-11-30 Thread Werner LEMBERG

 In the regression test, I've found that FT_New_Face() in ftmac.c
 does not return correct aface-num_faces.  [...]

 ...So, now I'm going to fix this, and I want to ask about binary
 compatibility.  At present, via FT_New_Face() in ftmac.c, we can
 access the 2nd sfnt resource as the 2nd face of the font, although
 we don't know how many sfnt resources are included in the font.
 Other resources, like fbit bitmap, NFNT bitmap, are ignored and not
 counted at all.

Where's the problem with binary compatibility?  You are going to
extend the functionality, not to change, aren't you?

 At present, fbit and NFNT bitmap resources are not supported by
 FreeType, but I want to support it in future (I've ever written a
 ruby script to parse it).  In my understanding, the usage of NFNT
 bitmap is similar to the bitmap font in sfnt.

Hmm, is it really just a `strike'?  Or is it more like a full-featured
face, similar to the faces in WINFNT files?  Because of encoding
issues I have changed the bitmap handling for this driver from strikes
to faces.

 So, it is expected to ignore the number of NFNT in
 available-face-counting.  Possibly FreeType user don't want to
 receive the number of embedded bitmap font (numSizes of EBLC table)
 via aface-num_faces.  I wish so.

I fully agree.  Applications can use FT_IS_SCALABLE() to ignore bitmap
fonts.


Werner


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel


Re: [ft-devel] aface-num_faces of FT_New_Face() in ftmac.c

2005-11-30 Thread Werner LEMBERG
 NFNT resources are separated for each sizes, just aslike strike of
 sbit. Could I know more about WINFNT encoding issue in ft-devel
 archive?

As soon as there is an encoding difference you have to use faces.


Werner


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel