I think I found the cause to the problem. Pango assumes that the FT_StreamRec::base field, if non-zero, points to the whole font file read or mapped into memory. See pango_ot_info_get(). As such this is correct according to FreeType documentation, as said in ftsystem.h, "base :: For memory-based streams, this is the address of the first stream byte in memory. This field should always be set to NULL for disk-based streams."
Now, for some reason the base field is not set to NULL on Windows when pango_ot_info_get() gets called, even if the FT stream is not memory-based. (FreeType doesn't contain code to map fonts into memory on Windows, even if the API as such is almost as easy to use as mmap() &co.) Freetype, a bit dangerously, uses the FT_StreamRec::base field internally while reading stuff from the font file, setting it in FT_Stream_EnterFrame() and resetting it to NULL in FT_Stream_ExitFrame(). Before pango_ot_info_get() gets called, FT_Stream_EnterFrame() has been called but the corresponding call to FT_Stream_ExitFrame() doesn't seem to have happened yet. Whether this is a bug in FreeType, a Windows- or MinGW-specific problem, or whether Pango uses FreeType in some wrong/undefined way, no idea. So face->stream->base is non-NULL and Pango thinks it is a memory-based stream even if base points to some random buffer with just a part of the font file. A quick fix is to make the code in pango_ot_info_get() always use the "else" branch on Windows, and then indeed for instance in GIMP's text tool Arabic shaping works again, and hopefully also your Telugu problem is solved. At least the result looks different. I now notice that FreeType 2.3.12 has been released, but it doesn't seem to work any differently. --tml _______________________________________________ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list