RE: [ft] Glitchy stroker output

[Stephan T. Lavavej]

> I've fixed this now.  Thanks again for your help!  Please test the
> CVS.

Awesome! I was unable to build the CVS because builds/unix/configure wasn't
present (it appears to be generated by some process I'm unfamiliar with, and
which my MSYS installation may not even contain). However, I simply patched
2.3.7, and it works!

http://stl.nuwen.net/pub/freetype/fixed.png

Thank you so much!

While I've got your ear, I have some lesser concerns, though I can easily
live with the current state of things.

1. It would be great if super-thick borders didn't cause the "detachment"
that I was talking about earlier. This appears to happen to only those
glyphs that contain dotlike components, '.' being the canonical example, and
':', '!', '?', '`', etc. being other examples. It appears that the inner
border is inverting. But it doesn't happen for glyphs with long and narrow
components, Zeroes Three's 'I' being a good example.

2. This is a straightforward bug when using FT_RASTER_FLAG_DIRECT:
FT_Outline_Render() dereferences params.target when it is non-null. So, if
you leave params.target uninitialized, you'll get crashes and other badness.
params.target must be initialized to null if you want the code to actually
work.

FreeType's documentation at
http://freetype.sourceforge.net/freetype2/docs/ft2faq.html#other-depth does
not mention this; it depicts using FT_RASTER_FLAG_DIRECT with params.target
uninitialized. I faithfully followed this, and spent a long time trying to
understand why my game was crashing at certain optimization levels until I
figured this out. (I'm obsessive about initializing my own variables; I
should have been more paranoid here.)

When using FT_RASTER_FLAG_DIRECT, either FT_Outline_Render() should not
inspect params.target, or the documentation (both the FAQ and the API
Reference) should explain that FT_RASTER_FLAG_DIRECT requires params.target
to be null.

3. It would be nice if the include path restructuring described in
ft2build.h were performed. Currently, I do this manually when building
freetype.

4. Between 2.3.5 and 2.3.7, something in freetype's build system became
slightly broken. As I build libraries in MSYS in order to use them with
MinGW (outside of MSYS), I never want libraries to be installed to the
default location (which would be inside MSYS). Therefore, I use --prefix
with configure, which works for basically everything. It worked with
freetype 2.3.5, but stopped working with 2.3.7. Even after configuring with
--prefix=/path/to/somewhere, "make install" installed freetype to the
default location. After cleaning out the files that it had installed to my
MSYS directories, I found that I had to use "make install
prefix=/path/to/somewhere" in order to restore correctness.

Here's a slimmed-down version of my build script (removing patches that I
apply, but none of the important parts), demonstrating what I'm doing
(C:\Temp\gcc is my working directory):

#!/bin/sh

cd /c/temp/gcc
tar xf freetype-2.3.7.tar
mv freetype-2.3.7 src
mkdir build dest
cd build
../src/configure --prefix=/c/temp/gcc/dest
make

# prefix=/c/temp/gcc/dest shouldn't be necessary.
# This was broken between 2.3.5 and 2.3.7.
make install prefix=/c/temp/gcc/dest

cd /c/temp/gcc
rm -rf build src
mv dest freetype-2.3.7

I don't know if this happens on a real unix machine (I am not eager to
contaminate my RHEL3 server), but as building freetype in MSYS appears to
use the ordinary unix machinery, it might.


Once again, thanks for the fix - this unblocks my game development.

Stephan