[Bidi] Automatic text direction

Behdad Esfahbod behdad at cs.toronto.edu
Thu Mar 10 17:12:10 PST 2005

On Mon, 28 Feb 2005, Ely Levy wrote:

> Hey,

Hi Ely,

Thanks for bringing up.  I think I have a fairly good picture of
the whole thing.  Lets see:

> I think we should create a standard for automatic text direction.
> There are few issues on how to detect the text direction (RTL or LTR)
> for example numbers should not be the setter of direction, the ability
> to manual override, split text ( for example gaim nick in english line is
> in hebrew or arabic what should be the text direction?should it be splited
> nick from one side text from the other? should it ignore the nick and
> detect it by the text?)
> What about html text?how do we ignore tags as direction setters?
> the big question, can a good autodetect actually be done? or should we
> give up on it and do maunal setting only?

Yes.  Here is my view of the stack of bidi support:

* Unicode Bidirectional Algorithm (UBA from now on on this list),
  for paragraphs of plain text.  This is already implemented in
  GNU FriBidi and used by Pango, in the GNOME stack, for example.

* Some low-level markup is defined for better bidi override, etc,
  like the unicode-bidi property in CSS for example.  In the GNOME
  stack this goes inside Pango.  We don't have it yet.  Got to
  design.  Dov brought the issue up some time ago on this list
  IIRC.  This should solve the GAIM problem above.

* The algorithm implemented by Dov in GNOME, with some
  refinements, for determining direction of paragraphs in a plain
  text document.  This works pretty good most of them.  Some
  people say it makes them less productive, but almost all
  examples they give is of markup languages, not plain text.

* Seems like we need a layer here to allow manually override
  paragraph directions, etc...

* For non-plain text, like markup languages (XML, HTML, ...), and
  programming languages (C, Python, JavaScript, ...), we
  standardize the data that a highlighting engine can use for
  proper rendering.  See my comment in this feature request on
  gtksourceview for details:


I believe if we get to implement these all, we're almost there.
Remains exotic things like LaTeX source, etc, that cannot be
reaaly handled anyway in an editor.

Pointers to documents cited above are all on the project page at

> Ely Levy
> System group
> Hebrew University
> Jerusalem Israel


More information about the bidi mailing list