[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unicode support
From: |
Eli Zaretskii |
Subject: |
Re: Unicode support |
Date: |
Tue, 24 Jul 2001 13:32:18 +0300 (IDT) |
On Tue, 24 Jul 2001, Werner LEMBERG wrote:
> I think a text layout engine is necessary between the Emacs Lisp layer
> and the glyph engine to make Emacs work with characters, not glyphs.
I'm not sure I understand: the display code is not (normally) called from
Lisp, it is called as part of the command loop, which is a C level
mechanism. 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.
In other words, the main connection between Lisp and display is indirect:
Lisp programs change the buffer text or variables which affect how the
text is displayed, and the next redisplay reflects those changes.
> I don't know which language would be suited best. Probably as with
> the rest of Emacs, some core C functions should be accompanied with
> Lisp code (probably mostly in CCL).
I think pretty much everything will have to be in C, since redisplay is a
very complex piece of code and its performance is critical for Emacs
responsiveness. Even today, if you disable most of the special
optimization cases in redisplay, it becomes unbearably slow on anything
slower than a 500-MHz machine, even for such trivial operations as cursor
motion. So any code added to redisplay should run as fast as possible.
> . 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.
> . 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.
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).
- Re: Unicode support, (continued)
- Re: Unicode support, Werner LEMBERG, 2001/07/18
- Re: Unicode support, Eli Zaretskii, 2001/07/18
- Re: Unicode support, Werner LEMBERG, 2001/07/19
- Re: Unicode support, Eli Zaretskii, 2001/07/19
- Re: Unicode support, Werner LEMBERG, 2001/07/19
- Re: Unicode support, Eli Zaretskii, 2001/07/19
- Re: Unicode support, Kai Großjohann, 2001/07/19
- Re: Unicode support, Eli Zaretskii, 2001/07/19
- Re: Unicode support, Dave Love, 2001/07/23
- Re: Unicode support, Werner LEMBERG, 2001/07/24
- Re: Unicode support,
Eli Zaretskii <=
- Re: Unicode support, Werner LEMBERG, 2001/07/24
- Re: Unicode support, Eli Zaretskii, 2001/07/24
- Re: Unicode support, Roozbeh Pournader, 2001/07/24
- Re: Unicode support, Eli Zaretskii, 2001/07/25
- Re: Unicode support, Roozbeh Pournader, 2001/07/24
- Re: Unicode support, Eli Zaretskii, 2001/07/25
- Re: Unicode support, Miles Bader, 2001/07/25
- Re: Unicode support, Roozbeh Pournader, 2001/07/25
- Re: Unicode support, Eli Zaretskii, 2001/07/25
Re: Unicode support, Dave Love, 2001/07/22