Re: Pango for internationalization.

[Havoc Pennington <hp redhat com>]

Martin Sevior <msevior mccubbin ph unimelb edu au> writes: 
> I cross posted this to Abiword so the real experts can answer. Just a
> quick response though. There is no reason we can't use our current system
> for raw GTK and Pango/libunicode etc for gnome. I haven't been involved in
> this.

GTK 2.0 depends on Pango, so Pango is below the GTK layer, not a GNOME
feature. libunicode is going away; it just got merged into GLib. Pango
is ported to win32 for GTK/win32. Anyhow, my thought is that
GLib/Pango are pretty trivial to maintain as cross-platform libraries,
and already are maintained for that, and using them on all platforms
would not impact look-and-feel.

> Do you use iconv to convert between different X font maps? Or does GTK 2.0
> solve all that for us automatically? We've been plauged with compatibility
> problems between different versions of iconv. The latest glibc returns 16
> bit wide chars byte swapped compared to earlier versions. Even earlier
> version segfault on valid input.
> 
> When GTK 2.0 is pronounced "Stable" we will certainly look at what is
> implemented for internationalization.
> 
> Only the GTK version of Abi has CJK support right now.
> 

In GTK 1.2 you have one "current language." The app is running in
English, in Japanese, etc. The purpose of Unicode is to allow you to
have a document with all kinds of different languages in it.

GTK 2.0 makes all the stuff about current encoding go away. The
encoding is always Unicode. You only need iconv when importing from
files in another encoding. GLib has g_iconv() which is a portable
iconv, and will also have some built-in conversions between flavors of
Unicode.

X fonts are entirely concealed; Pango will map from a font description
to one or more platform-specific fonts. So it can create a "Sans 14"
font that is made up of one X font for Japanese, another for Arabic,
etc. You can use the same Pango font API on all platforms Pango has
been ported to.

Pango takes care of all the glyph selection, reordering, finding text
boundaries, etc. that is kind of scary code it would be good if you
didn't have to write. 

You can't use PangoLayout, which does the text layout, since a word
processor will have more elaborate layout requirements. But you can
definitely use pango_itemize(), pango_break(), and pango_shape(), and
the Pango font abstraction and language engines.

Another issue is input methods; GTK 2.0 will support custom input
method modules, and AbiWord will need to be hacked to support those.
(See gtk/gtkimcontext.h in the devel tree.)

Havoc