emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unicode support


From: Werner LEMBERG
Subject: Re: Unicode support
Date: Tue, 24 Jul 2001 17:44:47 +0200 (CEST)

[This mail is about how to implement advanced Unicode support (level 2
 and 3) in Emacs.]

> If you want to draw a diagram like this:
> 
> >                    Emacs Lisp
> >                        |
> >                        | characters
> >                        |
> >                Text Layout Engine
> >                        |
> >                        | characters
> >                        |
> >                 GPOS/GSUB Engine
> >                        |
> >                        | glyphs
> >                        |
> >                  Display Engine
> 
> then the top level is the buffer text, not Emacs Lisp.

Yes, I was imprecise.  I meant the data which Emacs Lisp should
handle, and this is characters, in buffers and strings, and not
glyphs.

> >   . For Arabic scripts, adding initial, medial, final, and isolate
> >     properties to the characters.
> 
> Shouldn't Arabic presentation forms addition be delayed for some
> (short) time, in case the user types more characters of the same
> word?  Emacs will not normally know how to display the character
> just typed: as initial, medial, or final form, since it doesn't know
> what will be typed next.

I've CCed Roozbeh Pournader to this mail; he is actively researching
this topic and can tell us which possibilities have been shown as
practical.

> >   . For Indic scripts, reordering of glyphs according to the
> >     Unicode standard.
> > 
> >   . For Right-To-Left scripts, reeordering from logical to visual
> >     order, taking care of nested levels etc. as described in the
> >     Unicode standard.
> > 
> >   . For everything else, applying data from the various Unicode
> >     tables to make the glyph engine aware of non-spacing accents,
> >     combining characters, etc.

BTW, I forgot to mention language tags.

> We discussed similar issues related to bidirectional support with
> Gerd.  The current state of thinking, as I understand it, is that
> the rearrangement of characters for display (i.e. conversion between
> the logical and visual order) should happen inside the functions
> which walk the buffer and supply the next character for display to
> the next layer (which generates glyphs).

Eli, you are the expert here.  Maybe it is possible to use some freely
available Unicode BIDI algorithms to avoid the reinvention of the
wheel.


    Werner



reply via email to

[Prev in Thread] Current Thread [Next in Thread]