Re: [ft-devel] endian issue in ftmac.c

[mpsuzuki]

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

Re: [ft-devel] ftvalid

[Masatake YAMATO]

 Sorry, when the internal validators are disabled, FT_XXX_Validate()
 should return FT_Err_Unimplemented, instead of FT_Err_Invalid_Argument.
 It was my mistake. I remember we had ever discussed this issue and
 agreed to implement so, when validation functions are decided to
 be disabled by default (around 2005-11?), but I slipped to fix that.
 Within 6 hours, I will fix it in CVS.

After rethinking, I found a case that FT_Err_Unimplemented is not
enough. With current code, FT_Err_Unimplemented is returned even if a
bdf face is passed to FT_TrueTypeGX_Validate. From the return value 
the user cannot distinguish (1) a validator is just disabled when building
libfreetype2 nor (2) a validator service doesn't support the face
passed as an argument.

With following patch FT_TrueTypeGX_Validate returns FT_Err_Unimplemented_Feature
for the case (1); and FT_Err_Invalid_Argument for the case (2).

Toshiya-san and Werner, do you think this is over kill?

If I get approval from you, I'll install patches for GX and OT.

Masatake YAMATO

--- ftgxval.c   16  6月 2006 04:42:51 +0900  1.4
+++ ftgxval.c   22  6月 2006 13:23:26 +0900  
@@ -61,8 +61,10 @@
  validation_flags,
  tables,
  table_length );
-else
+else if ( FT_Get_Module( FT_FACE_LIBRARY( face ), gxvalid ) == NULL )
   error = FT_Err_Unimplemented_Feature;
+else
+  error = FT_Err_Invalid_Argument;
 
   Exit:
 return error;




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