[ft-devel] embedding Carbon dependency info into freetype2.pc & freetype-config

[mpsuzuki]

Dear Sirs,

Since freetype-2.2.1 release, I received several complains
from MacOSX developers/users saying as: freetype-2.2.1 links
Carbon library (non POSIX, MacOS-specific APIs) by default,
but freetype-config/freetype2.pc does not mention whether
libfreetype depends on Carbon /or not.

To link Carbon library, non-standard option "-Xlinker -framework
-Xlinker CoreServices ..." is added to LDFLAGS. If I could
embed this option to freetype2.pc and freetype-config (if
libfreetype is configured to use Carbon), the reported problem
will be solved.

Although I was afraid such non-standard option introduce some
confusion, recently I heard that sdl.pc includes such option:
"-Wl,-framework,Cocoa". So now I think embedding such option
is into freetype2.pc and freetype-config (when required) is
acceptable.

Please let me know how do you think of.

Regards,
mpsuzuki


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

[ft-devel] Re: embedding Carbon dependency info into freetype2.pc & freetype-config

[Werner LEMBERG]

> Since freetype-2.2.1 release, I received several complains from
> MacOSX developers/users [...]
>
> To link Carbon library, non-standard option "-Xlinker -framework
> -Xlinker CoreServices ..." is added to LDFLAGS. If I could embed
> this option to freetype2.pc and freetype-config (if libfreetype is
> configured to use Carbon), the reported problem will be solved.

Please do whatever you think is the right solution!  I trust in you
that you will correct any problems which might arise later on :-)

Thanks in advance.


Werner


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

[ft-devel] Re: embedding Carbon dependency info into freetype2.pc & freetype-config

[mpsuzuki]

Dear Sir,

On Wed, 11 Oct 2006 20:32:41 +0200 (CEST)
Werner LEMBERG <[EMAIL PROTECTED]> wrote:

>
>> Since freetype-2.2.1 release, I received several complains from
>> MacOSX developers/users [...]
>>
>> To link Carbon library, non-standard option "-Xlinker -framework
>> -Xlinker CoreServices ..." is added to LDFLAGS. If I could embed
>> this option to freetype2.pc and freetype-config (if libfreetype is
>> configured to use Carbon), the reported problem will be solved.
>
>Please do whatever you think is the right solution!  I trust in you
>that you will correct any problems which might arise later on :-)

Thank to you for comment. Just I've fixed configure.raw. It uses
new macro FT2_EXTRA_LIBS to embed extra dependency to freetype2.pc
and freetype-config.

Of course, if freetype is built without Carbon (on most Unix),
the macro is substituted by blank, and has no effect.

Regards,
mpsuzuk


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

[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/msg8.html
http://mail.gnome.org/archives/gtk-i18n-list/2006-August/msg4.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_Longflag_offset;
 FT_Longrlen;
 intis_cff;
+FT_Longface_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;





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

[ft-devel] autoconf-based cross-building patch ([ft] FT2 Cross-compile Error)

[mpsuzuki]

Dear Sirs,

Since my previous notice as "I will do within 1 or 2 months"
for cross-building issue (reported in freetype list), 1.8 month
has already passed. Sorry for long lating.

Just I've finished a preliminary patch to enable cross-
building by GNU autoconf, I attached it.

# After applying the patch, I can build freetype2 on Linux/i386
# for Linux/MIPS, aslike,
#
#   $ ./configure \
#   --build=i386-pc-linux-gnu \
#   --host=mips-ip22-linuxelf-gnu
#   $ make
#
# is OK. However, often I find people doing wrong style as:
#
#   $ env CC=/usr/local/mips-ip22-linuxelf-gnu/bin/gcc \
#   ./configure
#
# or
#
#   $ env CC=/usr/local/bin/mips-ip22-linuxelf-gcc \
#   ./configure
#
# There are too many people doing such, so I'm afraid there are
# some building systems (or script tools) doing such. I don't
# have working solution for such people.

I'm unfamiliar with the naming convension in .mk files,
so I want comments by David or Werner about the variable
names like "CCraw_build" "E_BUILD".

Regards,
mpsuzuki


--- orig/builds/unix/configure.raw
+++ mod/builds/unix/configure.raw
@@ -25,6 +25,8 @@
 
 # checks for system type
 
+AC_CANONICAL_BUILD
+AC_CANONICAL_HOST
 AC_CANONICAL_TARGET
 
 
@@ -32,6 +34,42 @@
 
 AC_PROG_CC
 AC_PROG_CPP
+AC_SUBST(EXEEXT)
+
+
+# checks for native programs to generate building tool
+
+if test ${cross_compiling} = yes; then
+  AC_CHECK_PROG(CC_BUILD, ${build}-gcc, ${build-gcc})
+  test -z "${CC_BUILD}" && AC_CHECK_PROG(CC_BUILD, gcc, gcc)
+  test -z "${CC_BUILD}" && AC_CHECK_PROG(CC_BUILD, cc, cc, , , /usr/ucb/cc)
+  test -z "${CC_BUILD}" && AC_MSG_ERROR([cannot find native C compiler])
+
+  AC_MSG_CHECKING([for suffix of native executables])
+  rm -f a.* b.* a_out.exe conftest.*
+  echo > conftest.c "int main() { return 0;}"
+  ${CC_BUILD} conftest.c || AC_MSG_ERROR([native C compiler is not working])
+  rm -f conftest.c
+  if test -x a.out -o -x b.out -o -x conftest; then
+EXEEXT_BUILD=""
+  elif test -x a_out.exe -o -x conftest.exe; then
+EXEEXT_BUILD=".exe"
+  elif test -x conftest.* ; then
+EXEEXT_BUILD=`echo conftest.* | sed -n '1s/^.*\.//g'`
+  fi
+  AC_MSG_RESULT($EXEEXT_BUILD)
+else
+  CC_BUILD=${CC}
+  EXEEXT_BUILD=${EXEEXT}
+fi
+
+
+if test ! -z ${EXEEXT_BUILD}; then
+  EXEEXT_BUILD=."${EXEEXT_BUILD}"
+fi
+AC_SUBST(CC_BUILD)
+AC_SUBST(EXEEXT_BUILD)
+
 
 
 # get compiler flags right


--- orig/builds/unix/unix-cc.in
+++ mod/builds/unix/unix-cc.in
@@ -25,6 +25,12 @@
 SO := o
 
 
+# The executable file extension. Although most Unix platform use no extension,
+# we copy the extension detected by autoconf, useful for cross building on
+# Unix system for non-Unix system.
+#
+E  := @EXEEXT@
+
 # The library file extension (for standard and static libraries).  This can
 # be .a, .lib, etc., depending on the platform.
 #
@@ -88,10 +94,12 @@
 LDFLAGS := @LDFLAGS@
 
 
-# export symbols (XXX: HOW TO DEAL WITH CROSS COMPILATION ?)
+# export symbols
 #
+CCraw_build  := @CC_BUILD@ # native CC of building system
+E_BUILD  := @EXEEXT_BUILD@ # extension for exexutable on building system
 EXPORTS_LIST := $(OBJ_DIR)/ftexport.sym
-CCexe:= $(CCraw)   # used to compile "apinames" only
+CCexe:= $(CCraw_build) # used to compile "apinames" only
 
 
 # Library linking


--- orig/builds/exports.mk
+++ mod/builds/exports.mk
@@ -48,7 +48,7 @@
   # Note that $(APINAMES_OPTIONS) is empty, except for Windows compilers.
   #
   APINAMES_SRC := $(TOP_DIR)/src/tools/apinames.c
-  APINAMES_EXE := $(OBJ_DIR)/apinames$E
+  APINAMES_EXE := $(OBJ_DIR)/apinames$(E_BUILD)
 
   $(APINAMES_EXE): $(APINAMES_SRC)
  $(CCexe) $(TE)$@ $<






On Mon, 21 Aug 2006 21:17:53 +0900
[EMAIL PROTECTED] wrote:

>Hi,
>
>On Mon, 21 Aug 2006 19:49:39 +0800
>"littertiger" <[EMAIL PROTECTED]> wrote:
>>When I cross compile directfb，I found it needs FreeType 2.
>>so I donloaded it, and cross compile it.
>>My cross compiler is arm_v4t_le-gcc. I type the following cmd in
>>FreeType2 source path: CC=arm_v4t_le-gcc ./configure --host=arm-linux；
>>make  It seems it prodused a arm format program apinames, and execute
>>it, then errors.
>
>Ah, cross-building on Unix systems in freetype-2.2.x is
>temporarily broken at present, I will fix it within 1 or
>2 months. Please try freetype-2.1.10 which can be built
>without apinames.
>
># apinames is a tool to hide internal symbols from public.
>
>Regards,
>mpsuzuki




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

[ft-devel] Re: autoconf-based cross-building patch ([ft] FT2 Cross-compile Error)

[Werner LEMBERG]

> Just I've finished a preliminary patch to enable cross-
> building by GNU autoconf, I attached it.

Great!  Thanks for your work.

> However, often I find people doing wrong style as: [...]

Don't worry.  We just have to document the right way, perhaps in a new
file called `INSTALL.CROSS'.

> I'm unfamiliar with the naming convension in .mk files, so I want
> comments by David or Werner about the variable names like
> "CCraw_build" "E_BUILD".

Just go on.


Werner


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