Hi, I noticed a problem in the Pango FreeType backend on Windows, where it would see a FT_StreamRec with a non-NULL base field, and thus assume it is a memory-based stream as the comment in ftsystem.h promises (and that base points to the whole font file mapped into memory).
I did some debugging, but did not really understand the root cause. Anyway, what seems to be going on is that FreeType in FT_Stream_EnterFrame() sets base to non-NULL, and then in a corresponding FT_Stream_ExitFrame() it is set back to NULL. Presumably this is supposed to all happen just internally, and the calling code outside of FreeType is not supposed to see a FT_StreamRec with non-NULL base? These functions are called repeatedly in pairs, occasionally several "enter" followed by one "exit", hmm. But then at one point the "exit" function isn't called, and a non-NULL base "escapes" into the upper levels. Any idea what could be happening? Has there been problems like this reported for other platforms where memory-mapped font files aren't used? Actually, it would be fairly trivial to add support for memory mapped font files on Windows, too. The Win32 API for that it a bit more verbose, but not really more complex, than the Unix mmap() &co. (But that doesn't make the problem, if it is a problem in FreeType, go away for platforms that are neither Windows nor Unix.) --tml _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
