Dear Werner,
Just I've finished 2 international meetings.
On Mon, 04 Apr 2011 05:37:33 +0200 (CEST)
Werner LEMBERG w...@gnu.org wrote:
You must have a special procedure in mind which I haven't grasped yet.
I know nothing about the linker on Macs, I just wonder why zlib is
handled differently
During the business trip, I was trying to reproduce the trouble that
Dave Viner got in
http://lists.gnu.org/archive/html/freetype/2006-05/msg00035.html ,
and I found I made an overestimation about bad impact of the chained
dependency. Please let me explain. [...]
Thanks for the analysis!
My question is: where should I look and/or what should I change, to
make them act the same?
The FT_INT64 stuff is only used in a single file, `src/base/ftcalc.c'.
However, AFAIK, the GNU C compiler always defines a 64bit data type
(`long long int'), so I'm really surprised that you experience
I've verified that replacing #undef FT_CONFIG_OPTION_FORCE_INT64
with #define in include/freetype/config/ftoption.h does prevent the
#undef FT_LONG64.
But that shouldn't be needed on LP64 archs.
Perhaps the #if FT_SIZEOF_LONG == 8 case should also #define
FT_CONFIG_OPTION_FORCE_INT64 ?
In particular, it appears to me that the ARM system is doing some
incorrect math from the metrics width value of 0x2C0 to get 0x800,
but I'm having trouble identifying why this might be.
Finally, can you decorate the various functions of ftcalc.c with
some printf calls to find out where the
ftgrid has been improved.
. Added key `f' to ftgrid to toggle forced autohinting. This might be
interesting for some of you since you can toggle vertical and
horizontal hinting independently.
. Autofit debugging messages can now be controlled via
FT_DEBUG_AUTOFIT in ftconfig.h (AF_DEBUG
WL == Werner LEMBERG w...@gnu.org writes:
JC Perhaps the #if FT_SIZEOF_LONG == 8 case should also
JC #define FT_CONFIG_OPTION_FORCE_INT64 ?
WL For the dumb guy I am this sounds reasonable :-)
WL What about `make devel; make' which checks ANSI compliance also?
I'll test that out.
WL If
