Re: [platform-swt-dev] SWT Bidi Text Support

[Havoc Pennington <hp@xxxxxxxxxx>]

"Lynne Kues/RAL/OTI" <Lynne_Kues@xxxxxxx> writes: 
> If you decide to use BidiUtil, we can certainly answer questions for you, 
> discuss the issues we ran into, etc..  It would also be useful to get your 
> feedback as to what you (or anyone for that matter) think API for bidi 
> support should look like.

We have added support for bidi and other text i18n issues in GTK 2
(which the Eclipse GTK port should probably be using ASAP, it is
worlds better from both a programmer and end-user standpoint than
1.2).  This is done via the Pango i18n library, documentation here:
http://developer.gnome.org/doc/API/2.0/pango/index.html Also see
http://www.pango.org, though that's partially outdated.

Pango does actually run on Windows as well, which may be an
interesting property of it, I don't know. We use it for i18n text
rendering on the win32 version of GTK+. The AbiWord word processor
project is considering using Pango cross-platform, even on win32 (they
do not use GTK+ on win32, they use native win32 widgets).

The primary API of Pango is an object called PangoLayout, which is the
high-level interface we expect applications to use.  See
http://developer.gnome.org/doc/API/2.0/pango/pango-layout-objects.html
Most of the other APIs are too low-level for anyone but an i18n expert
to use successfully. PangoLayout represents a paragraph, together with
style information, and cached computations of layout (where glyphs are
located, etc.)

Pango uses the bidi algorithm from fribidi:
http://fribidi.sourceforge.net/
but this is just a low-level detail, most apps don't need to use it. 
We actually have a cut-and-paste from fribidi stuck in Pango, and
there's some talk of just merging the two libraries.

Reading the SWT docs I noticed a possible issue with GTK+ - one of
the examples has this:

 gc.stringExtent (text)

In GTK 2, that is a reasonably expensive operation, because it needs
to create a PangoLayout and do all the complex stuff involved in
Unicode text rendering. Thus we would typically keep the precomputed
layout object around, and use it e.g. in both the computeSize() and
the redraw handler.

I'm just coming off of several months spent implementing GtkTextView
which is our new fully-i18n-enabled text widget for GTK 2; we had to
expend substantial effort to make the widget efficient, because while
in GTK 1.2 many text operations such as getting string extents can be
"brute forced" and are fast, in a fully internationalized Unicode
world it's just not the case. So smart data structures and
incremental/nonblocking computation turned out to be necessary.

The SWT text widget is substantially simpler than ours (and should be
- for a code editor, GtkTextView is pretty huge overkill). So it's
probably easier to sort out.

Anyhow, even though GtkTextView is quite complex, it uses only the
relatively high level PangoLayout API. I think an API on that level is
probably most appropriate for general use. Very few apps will need to
drop down and care about the lower-level details; generally, apps that
need more text attributes or more layout control than PangoLayout
offers, such as word processors, will need to implement their own
layout engine.

Anyone interested in i18n in unix/Linux GUIs probably wants to join
gtk-i18n-list@xxxxxxxxx, see
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list, interesting
discussions appear there from time to time, and many of the relevant
persons are subscribed to that list.

Obviously (to the IBM people here) ICU is another interesting
technology to be investigating. http://oss.software.ibm.com/icu/

Havoc