Re: PangoF2 in win32 not applying GSUB.
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
Re: PangoF2 in win32 not applying GSUB - Fixed.
Thanks Tml,
This fixed the issue for me, now the GSUBs are working properly in win32.
I just commented out the portion in pango_ot_info_get() in
pango-1.26.2\pango\pango-ot-info.c.
PangoOTInfo *
pango_ot_info_get (FT_Face face)
{
PangoOTInfo *info;
if (G_LIKELY (face-generic.data face-generic.finalizer ==
pango_ot_info_finalizer))
return face-generic.data;
else
{
if (face-generic.finalizer)
face-generic.finalizer (face-generic.data);
info = face-generic.data = g_object_new (PANGO_TYPE_OT_INFO, NULL);
face-generic.finalizer = pango_ot_info_finalizer;
info-face = face;
/*
if (face-stream-base != NULL) {
hb_blob_t *blob;
blob = hb_blob_create ((const char *) face-stream-base,
(unsigned int) face-stream-size,
HB_MEMORY_MODE_READONLY_MAY_MAKE_WRITABLE,
NULL, NULL);
info-hb_face = hb_face_create_for_data (blob, face-face_index);
hb_blob_destroy (blob);
} else
*/
{
info-hb_face = hb_face_create_for_tables (_get_table, NULL, info);
}
hb_face_set_unicode_funcs (info-hb_face, hb_glib_get_unicode_funcs ());
/* XXX this is such a waste if not SFNT */
if (!hb_ot_layout_has_font_glyph_classes (info-hb_face))
synthesize_class_def (info);
}
return info;
}
Warm Regds,
Ravi Kiran.
--- On Mon, 3/1/10, Tor Lillqvist t...@iki.fi wrote:
From: Tor Lillqvist t...@iki.fi
Subject: Re: PangoF2 in win32 not applying GSUB.
To: Ravi Kiran. kira...@yahoo.com
Cc: gtk-i18n-list@gnome.org
Date: Monday, March 1, 2010, 10:41 AM
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
PangoF2 in win32 not applying GSUB.
Hello, I have been debugging this issue for the last few days and found that when using pango (pango-1.26.2) with ft2 backend, GSUBs are not being applied (in telugu using lohit_telugu font). I traced this to harfbuzz. When I use an older version of pango (pango-1.12.4) where harfbuzz is not being used, gsub works without any issues. I saw a similar issue mentioned for Arabic font where pango-cairo was working and pango-ft2 was not. http://www.mail-archive.com/gtk-i18n-list@gnome.org/msg01565.html I tried with cairo backend and it worked since cairo was using Uniscribe. When I forced cairo to use FT2 backend, I got back the same results of gsub not being applied. pango-1.26.2 works without any issues in linux so I compared the two using gdb and I noticed that in win32,in function indic_engine_shape, ruleset-rules-len was returning 0, but in linux it was returning valid value of 7. I traced this in hb_ot_layout_table_find_script and found that find_script_index was returning error for telugu script. You can reproduce this with the attached source file. You will notice that when using pango-1.12.4 you will get one glyph (correct) but when using pango-1.26.2 you will get two glyphs. I am using MinGW and Msys to compile just pango, I am using binary packages from GTK site for other packages. I am using the following command for compiling. g++ gTestPango.cpp `pkg-config.exe pangoft2 --cflags --libs` ./a.exe all.txt gcc gtestcairo.c `pkg-config.exe pangocairo --cflags --libs` ./a.exe test.png This is the command I am using for compiling pango. ./configure --with-included-modules --prefix=/mingw make make install Warm Regds, Ravi Kiran. gtestcairo.c Description: Binary data gTestPango.cpp Description: Binary data ___ gtk-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
