> 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 _______________________________________________ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
