Re: [ft-devel] endian issue in ftmac.c
I suppose, the reason why freetype-config and freetype2.pc don't include CFLAGS and LDFLAGS is to drop unexpected options like optimization, uninstalled libary linking etc. So, now I'm thinking of import ftmac.c-specific CFLAGS LDFLAGS to freetype-config freetype2.pc. How do you think of? Please go ahead! Maybe it makes sense also to contact Fink gurus or check other packages ported to Mac OS. I can't really help. Considering the binary compatibility when ftmac-enabled FreeType2 is replaced by ftmac-disabled FreeType2 on MacOS X, adding dummy functions returning just FT_Err_Unimplemented is expected to avoid problem by unresolvable symbols? However, rather I hesitate to add new functions even if they are portable dummy. I see no problems here. Adding new (dummy) functions doesn't cause a binary incompatibility if FreeType's DLL version number is increased. Please update the documentation also so that users can clearly identify the stubs. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] endian issue in ftmac.c
Hi, Werner LEMBERG [EMAIL PROTECTED] wrote: Attached is revised version that uses Endian.h macros suggested by Mr. Sean McBride. If you don't mind I would like to put the responsibility for the Mac OS part into your hands. Neither David (AFAIK) nor me are using a Mac, so please go on! Thank you for steering, just I've committed the quick workaround as temporal fix, now I've started to full byte-order cleaning of ftmac.c. BTW, considering previous posts about ftmac.c's dependency with Carbon framework, I have a few questions about FreeType2 policy. (1) freetype2.pc should include CFLAGS and LDFLAGS for ftmac.c? --- At present, both files don't refrect LDFLAGS in configuration. So, when freetype2 is configured on MacOS X to use ftmac.c with Carbon framework, both of freetype-config and pkg-config return CFLAGS LDFLAGS without options to use ftmac.c. Therefore, when package builders make some MacOS X software which is dependent with FreeType2, they have to be careful whether their prebuilt-FreeType2 is Carbon dependent or Carbon independent. In the case of MacOS X developer community, I think, the number of developers who build ./configure make, as just same with common UNIX, is not negligible. In fact, freetype-config and freetype2.pc are introduced to avoid the manual management of configuration options. I suppose, the reason why freetype-config and freetype2.pc don't include CFLAGS and LDFLAGS is to drop unexpected options like optimization, uninstalled libary linking etc. So, now I'm thinking of import ftmac.c-specific CFLAGS LDFLAGS to freetype-config freetype2.pc. How do you think of? (2) dummy functions for ftmac.c are required? - Considering the binary compatibility when ftmac-enabled FreeType2 is replaced by ftmac-disabled FreeType2 on MacOS X, adding dummy functions returning just FT_Err_Unimplemented is expected to avoid problem by unresolvable symbols? However, rather I hesitate to add new functions even if they are portable dummy. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] endian issue in ftmac.c
Hi,
2 weeks ago, I received a report from Mr. David Sachitano:
ftmac.c is dependent with system endian and does not
work on Intel Mac. Afterwards, he sent me a patch written
by Mr. Apple Lawrence Coopet (from Apple). His patch uses
CoreFoundation functions to fix endian issue, e.g.
CFSwapInt16BigToHost(). Of course, they are unavailable in
MPW environment, so I replaced them by macro functions.
Attached patch is my modified version.
# I have to apologize. My indepth rewrite of ftmac.c was
# a fix for the legacy functions which are deprecated for
# Intel Mac. But I didn't have Intel Mac at that time and
# slipped to prepair the expected endian issue.
I've tested patched ftmac.c on Intel Mac, and checked
that the outputs by ft2demos' ftoldmac are exactly same
between PowerPC binary (executed via Rosetta emulation)
and Intel native binary. So, I think, the patch is not
perfect solution (some internal data is still stored in
reverse byte-order), but it can work quick fix of endian
issue, for public API. Without the patch, almost functions
of ftmac.c causes SEGV crashes, because its core part
(FOND parser) has endian issue.
However, the coding style of ftmac.c is quite different from
official FreeType2. The patch fixes the endian issue of the
platforms without memory alignments: m68k, PowerPC and x86,
but the type declaration by raw short long should be
removed (although I don't think there is any MacOS on MIPS).
I'm thinking of rewriting ftmac.c to fit the official coding
style of FreeType2. But it spends more time, so I suppose
the quick fix is expected, until the indepth rewrite of ftmac.c.
David, Werner, how do you think of applying the patch to CVS?
Regards,
mpsuzuki
--- freetype2--official-maintrunk--0.2--patch-111/src/base/ftmac.c
2006-06-20 17:09:13.0 +0900
+++ freetype2/src/base/ftmac.c 2006-06-20 17:01:27.0 +0900
@@ -64,6 +64,7 @@
/* This is for Mac OS X. Without redefinition, OS_INLINE */
/* expands to `static inline' which doesn't survive the */
/* -ansi compilation flag of GCC. */
+#undef OS_INLINE
#define OS_INLINE static __inline__
#include Carbon/Carbon.h
#else
@@ -74,6 +75,20 @@
#include TextUtils.h
#endif
+/*
+ * XXX: convertors for byte-order issue on Intel Mac.
+ */
+#if defined( TARGET_RT_LITTLE_ENDIAN ) ( TARGET_RT_LITTLE_ENDIAN 0 )
+#define FT_INT16BE_HOST( s ) \
+ ( ( ( ( s ) 8 ) 0xFF00 ) + ( ( ( s ) 8 ) 0x00FF ) )
+#define FT_INT32BE_HOST( l ) \
+ ( ( ( ( l ) 24 ) 0xFF00 ) + ( ( ( l ) 8 ) 0x00FF ) \
+ + ( ( ( l ) 8 ) 0xFF00 ) + ( ( ( l ) 24 ) 0x00FF ) )
+#else
+#define FT_INT16BE_HOST( s ) ( s )
+#define FT_INT32BE_HOST( l ) ( l )
+#endif
+
#if defined( __MWERKS__ ) !TARGET_RT_MAC_MACHO
#include FSp_fopen.h
#endif
@@ -536,7 +551,7 @@
/* The count is 1 greater than the value in the FOND. */
/* Isn't that cute? :-)*/
-return 1 + *( (short*)( fond_data + sizeof ( FamRec ) ) );
+return FT_INT16BE_HOST( *( (short*)( fond_data + sizeof ( FamRec ) ) ) ) +
1;
}
@@ -549,13 +564,13 @@
fond = (FamRec*)fond_data;
-face_all = *( (short *)( fond_data + sizeof ( FamRec ) ) ) + 1;
+face_all = FT_INT16BE_HOST( *( (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 )
+ if ( 0 == FT_INT16BE_HOST( assoc[i].fontSize ) )
face++;
}
return face;
@@ -597,19 +612,19 @@
/* if the face at this index is not scalable,
fall back to the first one (old behavior) */
- if ( assoc-fontSize == 0 )
+ if ( FT_INT16BE_HOST( assoc-fontSize ) == 0 )
{
*have_sfnt = 1;
-*sfnt_id = assoc-fontID;
+*sfnt_id = FT_INT16BE_HOST( assoc-fontID );
}
else if ( base_assoc-fontSize == 0 )
{
*have_sfnt = 1;
-*sfnt_id = base_assoc-fontID;
+*sfnt_id = FT_INT16BE_HOST( base_assoc-fontID );
}
}
-if ( fond-ffStylOff )
+if ( FT_INT32BE_HOST( fond-ffStylOff ) )
{
unsigned char* p = (unsigned char*)fond_data;
StyleTable* style;
@@ -619,10 +634,10 @@
int i;
- p += fond-ffStylOff;
+ p += FT_INT32BE_HOST( fond-ffStylOff );
style = (StyleTable*)p;
p += sizeof ( StyleTable );
- string_count = *(unsigned short*)(p);
+ string_count = FT_INT16BE_HOST( *(unsigned short*)(p) );
p += sizeof ( short );
for ( i = 0; i string_count i 64; i++ )
@@ -770,13 +785,13 @@
Str255lwfn_file_name;
UInt8 buff[HFS_MAXPATHLEN];
FT_Error err;
+short num_faces;
have_sfnt = have_lwfn = 0;
HLock( fond );
parse_fond( *fond, have_sfnt, sfnt_id, lwfn_file_name, 0 );
-HUnlock( fond );
if (
Re: [ft-devel] endian issue in ftmac.c
Hi, On Tue, 20 Jun 2006 10:36:58 -0400 Sean McBride [EMAIL PROTECTED] wrote: On 2006-06-20 17:54, [EMAIL PROTECTED] said: CFSwapInt16BigToHost(). Of course, they are unavailable in MPW environment, so I replaced them by macro functions. Attached patch is my modified version. You must be the last person on Earth still using MPW. :) Oops :-) True, CFSwapInt16BigToHost is Mac OS X only. But I think you can use the functions in Endian.h on both Mac OS 9 and X. For example: EndianU16_BtoN(). Ah, thank you for notice. I will use them. Have you read the Universal Binary Programming Guidelines? Specifically, this page: https://developer.apple.com/documentation/MacOSX/Conceptual/ universal_binary/universal_binary_tips/chapter_5_section_14.html#// apple_ref/doc/uid/TP40002217-CH239-CJBCCBDD Again thank you for information. The page is helpful. Regards, mpsuzuki ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] endian issue in ftmac.c
Hi,
On Tue, 20 Jun 2006 10:36:58 -0400
Sean McBride [EMAIL PROTECTED] wrote:
True, CFSwapInt16BigToHost is Mac OS X only. But I think you can use
the functions in Endian.h on both Mac OS 9 and X. For example:
EndianU16_BtoN().
Attached is revised version that uses Endian.h macros
suggested by Mr. Sean McBride.
Regards,
mpsuzuki
--- freetype2--official-maintrunk--0.2--patch-111/src/base/ftmac.c
2006-06-20 17:09:13.0 +0900
+++ freetype2/src/base/ftmac.c 2006-06-21 11:45:17.0 +0900
@@ -64,11 +64,13 @@
/* This is for Mac OS X. Without redefinition, OS_INLINE */
/* expands to `static inline' which doesn't survive the */
/* -ansi compilation flag of GCC. */
+#undef OS_INLINE
#define OS_INLINE static __inline__
#include Carbon/Carbon.h
#else
#include Resources.h
#include Fonts.h
+#include Endian.h
#include Errors.h
#include Files.h
#include TextUtils.h
@@ -536,7 +539,7 @@
/* The count is 1 greater than the value in the FOND. */
/* Isn't that cute? :-)*/
-return 1 + *( (short*)( fond_data + sizeof ( FamRec ) ) );
+return EndianS16_BtoN( *( (short*)( fond_data + sizeof ( FamRec ) ) ) ) +
1;
}
@@ -549,13 +552,13 @@
fond = (FamRec*)fond_data;
-face_all = *( (short *)( fond_data + sizeof ( FamRec ) ) ) + 1;
+face_all = EndianS16_BtoN( *( (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 )
+ if ( 0 == EndianS16_BtoN( assoc[i].fontSize ) )
face++;
}
return face;
@@ -597,19 +600,19 @@
/* if the face at this index is not scalable,
fall back to the first one (old behavior) */
- if ( assoc-fontSize == 0 )
+ if ( EndianS16_BtoN( assoc-fontSize ) == 0 )
{
*have_sfnt = 1;
-*sfnt_id = assoc-fontID;
+*sfnt_id = EndianS16_BtoN( assoc-fontID );
}
else if ( base_assoc-fontSize == 0 )
{
*have_sfnt = 1;
-*sfnt_id = base_assoc-fontID;
+*sfnt_id = EndianS16_BtoN( base_assoc-fontID );
}
}
-if ( fond-ffStylOff )
+if ( EndianS32_BtoN( fond-ffStylOff ) )
{
unsigned char* p = (unsigned char*)fond_data;
StyleTable* style;
@@ -619,10 +622,10 @@
int i;
- p += fond-ffStylOff;
+ p += EndianS32_BtoN( fond-ffStylOff );
style = (StyleTable*)p;
p += sizeof ( StyleTable );
- string_count = *(unsigned short*)(p);
+ string_count = EndianS16_BtoN( *(short*)(p) );
p += sizeof ( short );
for ( i = 0; i string_count i 64; i++ )
@@ -770,13 +773,13 @@
Str255lwfn_file_name;
UInt8 buff[HFS_MAXPATHLEN];
FT_Error err;
+short num_faces;
have_sfnt = have_lwfn = 0;
HLock( fond );
parse_fond( *fond, have_sfnt, sfnt_id, lwfn_file_name, 0 );
-HUnlock( fond );
if ( lwfn_file_name[0] )
{
@@ -787,9 +790,12 @@
}
if ( have_lwfn ( !have_sfnt || PREFER_LWFN ) )
- return 1;
+ num_faces = 1;
else
- return count_faces_scalable( *fond );
+ num_faces = count_faces_scalable( *fond );
+
+HUnlock( fond );
+return num_faces;
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] endian issue in ftmac.c
Attached is revised version that uses Endian.h macros suggested by Mr. Sean McBride. If you don't mind I would like to put the responsibility for the Mac OS part into your hands. Neither David (AFAIK) nor me are using a Mac, so please go on! Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
