Subject: Re: bi-directional support
From: Tomas Frydrych (tomas@frydrych.freeserve.co.uk)
Date: Thu Apr 27 2000 - 10:51:38 CDT
Hi Martin,
I myself have only limited experience with implementing BiDi
functionality, but I will try to outline why I think the type of BiDi
implementation I have been working on, i.e., one hard-wired into to
application itself, is the most reasonable way forward. (If other
people find flaws in what follows, I am sure I will be put right.)
A GUI engine that supports BiDi text does make things much
simpler, however, the BiDi problem cannot be handled *efficiently*
on the level of the graphical output (if at all). The BiDi algorithm has
to rearange the runs on the line to an appropriate order, based on
the composition of the *entire* line. If you wish to leave the
handling of the BiDi to the GUI routines you will always have to
pass it an entire line of text and let it draw the entire line, instead
just drawing only the runs that need drawing; this is fine for a small
edit-box, but apart from being rather inefficient in principle, it is a
whole new ball game when the formating of the line is not uniform.
As far as I understand, Pango relies on FriBidi, and so will most
likely the Gtk 1.4. FriBidi cannot be *efficiently* plugged into Abi;
this is not because there would be anything wrong with FriBidi,
which is very solid, but simply the internal structures of Abi make
its incorporation awkward (I have tried ...). Basically, you need a
line of text to pass to FriBidi to analyse, then brake-up the FriBidi
output back into your runs so that you can draw them with
appropriate formating attributes. Unfortunately, a line of text does
not really exist in Abi, you have to re-create it in one way or
another from all the runs on the line; this is in itself time consuming
but has to be done every time the line changes/needs redrawing. In
reality the BiDi problem is not very complex one and it can be
handled very efficiently within the existing structures of AbiWord
after only limited adaptations to some of the classes under text/fmt
(Run[s], BlockLayout, Line, View).
As far as the BiDi support in the Gtk is concencerned, I suspect
that the library will offer BiDi-enabled editing control(s) of some
kind, that will not handle just the drawing but also the editing (the
nature of the BiDi problem requires that -- once you separate the
editing from the drawing you end up with the whole-line-only
problem); these could be useful for implementing BiDi functionality
in simple contexts; whether they will be of any practical use for
AbiWord I am not sure, since at present AbiWord does not make
use of any ready-made editing control for the actual text editing,
the whole doc/view framework being written from scratch.
Thus, I think, irrespective of what gtk 1.4 will have to offer, you are
likely to end up bulding the BiDi handling directly into the core of
the application; I have already done that ... (Whether I have done it
well or not remains to be seen.)
I realise that the need for BiDi support is not felt as very pressing
just now, but I would like to point out that the sooner it is done, the
less work it will be, since it does require some non-trivial changes
to the fmt classes, and these propagate down the tree.
with regards
Tomas
> HI Tomas,
> I know very little about unicode and bidi but I was wondering if
> you were familiar with the pango project at www.pango.org which aims to
> have full unicode and bidi support built into gtk for gtk version 1.4.
>
> I had thought that we would use gtk 1.4 (which will contain pango) to
> provide the full internationaliztion of abiword. Can you tell us what your
> project will offer that we won't get with gtk 1.4? Is it possible for you
> to cooperate with gtk 1.4?
>
> Just some suggestions and a query for more information.
>
> Cheers
>
> Martin
>
>
>
This archive was generated by hypermail 2b25 : Thu Apr 27 2000 - 10:55:21 CDT