Bidi Emacs: R2L paragraphs and the direction of glyph_row

[Eli Zaretskii]

This issue is borderline between design and implementation, but the
decision will affect lots of code to be written/changed later, so I'm
posting this here, in case there are some considerations that I
missed.

Display of paragraphs whose base direction is right-to-left needs to
begin at the right margin of the window, and the empty space at the
end of the line, if any, should extend all the way to the left margin.

By contrast, the terminal-specific back-end (which Emacs uses to
display what's in the glyph matrices) always draws glyphs from left to
right.  When the back-end is told that the face should be extended to
the end of the line, it just draws the amount of pixels needed to get
to the margin; the glyph matrix does not tell it how many pixels to
draw.  (The text-mode back-end is different, see below.)

To resolve this contradiction, what I plan to do is to introduce a
direction flag into the glyph_row structure.  When this flag is
left-to-right, glyphs will start at the lowest address in the
glyph_row->glyphs[] array and will proceed towards the highest
addresses, and the x coordinate will grow in that direction as well,
as it does today.  But when this flag is right-to-left, glyphs will
start at the highest address in glyph_row->glyphs[], so that the first
glyph is in glyph_row->glyphs[TEXT_AREA]+glyph_row->used[TEXT_AREA]-1
and the last glyph is in glyph_row->glyphs[TEXT_AREA].  The x
coordinate still grows left to right in this case, as it would on the
screen.

IOW, in the the right-to-left case, the glyphs in the glyph_row are
"reversed".  The code which walks glyph rows will need to process such
reversed glyph rows back to front, to keep the rest of the logic
generally intact.

The advantage of this is in the correspondence between the glyph
matrix and what's on the glass.  I expect that to minimize changes in
other parts of the code which need to find buffer position that
corresponds to a screen position, or look for glyphs in the matrices
given their screen positions.  (The alternative -- to keep glyph rows
in their current left-to-right direction, and reverse them in the
terminal-specific back-end -- sounds less attractive, as it would
require more coding in both the back-ends and in the generic parts of
the display engine.)

This idea of "reversed" glyph rows is already implemented for a
text-mode terminal, and works quite well.  Reversing the glyphs in
this case is relatively straightforward, since face extension is
implemented by filling the rest of the line with blanks.  After such
filling, reversal is trivial.  But for graphics terminals, this is
more complicated, and since I'm not an expert on those back-ends, I
thought I'd ask here if someone sees any reasons why doing the same
would be hard or require many changes in the existing code, even if
that happens only in some very special situations, like displaying
embedded images.

Does someone see any reason why calculating glyph coordinates "in
reverse" or extending the face to the left margin would be hard or
impossible on graphics terminals?  Does anyone see problems with the
idea of using "reversed" glyph_row in the display engine?

TIA


_______________________________________________
emacs-bidi mailing list
emacs-bidi@...
http://lists.gnu.org/mailman/listinfo/emacs-bidi

[Gregg Reynolds]

On Sat, Oct 17, 2009 at 3:15 AM, Eli Zaretskii <eliz@...> wrote:

This issue is borderline between design and implementation, but the
decision will affect lots of code to be written/changed later, so I'm
posting this here, in case there are some considerations that I
missed.

I've got lots of complaints about the way most bidi-enabled editors handle keyboard and cursor interaction; would a list of specific annoyances, er, use-cases be of any use?

For example, in Mellel (http://www.redlers.com/) I've discovered that if an RTL document starts with an LTR string, it is impossible to simply insert a linefeed in front of that string.  It's also a major pain to edit XML in a bidi editor.  And I do mean major.  If emacs could make it easy and natural to perform such operations it would be manna from heaven.

Cheers,

Gregg

_______________________________________________
emacs-bidi mailing list
emacs-bidi@...
http://lists.gnu.org/mailman/listinfo/emacs-bidi

[Eli Zaretskii]

> Date: Thu, 26 Nov 2009 08:58:39 -0600
> From: Gregg Reynolds <gar@...>
> Cc: emacs-devel@..., emacs-bidi@...
>
> I've got lots of complaints about the way most bidi-enabled editors handle
> keyboard and cursor interaction; would a list of specific annoyances, er,
> use-cases be of any use?

Yes, certainly.  But please try to describe each annoyance, er,
use-case in enough detail, because most probably people here (myself
included) will not be familiar with many other editors.  Thanks in
advance.

> For example, in Mellel (http://www.redlers.com/) I've discovered that if an
> RTL document starts with an LTR string, it is impossible to simply insert a
> linefeed in front of that string.

How do you mean ``impossible''? what happens if you try inserting a
newline after going to the beginning of the buffer (with the
equivalent of "M-<" or C-Home)?

> It's also a major pain to edit XML in a bidi editor.  And I do mean
> major.

Again, an explicit list of main problems would be useful (although I
deliberately decided not to handle bidirectional editing for meta
documents yet, so this specific class of problems is still a long way
from being dealt with).

Thanks.


_______________________________________________
emacs-bidi mailing list
emacs-bidi@...
http://lists.gnu.org/mailman/listinfo/emacs-bidi

["Martin J. Dürst"]

Hello Eli, Gregg,

On 2009/11/27 1:10, Eli Zaretskii wrote:
>> Date: Thu, 26 Nov 2009 08:58:39 -0600
>> From: Gregg Reynolds<gar@...>

>> It's also a major pain to edit XML in a bidi editor.  And I do mean
>> major.
>
> Again, an explicit list of main problems would be useful (although I
> deliberately decided not to handle bidirectional editing for meta
> documents yet, so this specific class of problems is still a long way
> from being dealt with).

This is a well-known problem. For some more background and some attempt
at a solution, please see:

http://www.sw.it.aoyama.ac.jp/2005/pub/IUC28-bidi/ and
http://www.sw.it.aoyama.ac.jp/2008/pub/IUC32-bidi/

Unfortunately, the test prototype available at
http://www.sw.it.aoyama.ac.jp/2008/pub/IUC32-bidi/bidi-source.html
is not very usable currently because the carret jumps around and has to
be repositioned. That problem has been solved, but I didn't get around
to make the update publicly available. Anyway, both the simulation and
the Web-based editor should make it possible to test your problem cases
and tell us whether our solutions help (we know they aren't perfect;
there is no such thing as perfect bidi, unfortunately).

Questions and comments are very welcome!

In a discussion with Ken'ichi Handa and Naoto Takahashi in 2005, they
pointed out that using bidi marks in overlays should make it possible in
bidi emacs to address this problem. Unfortunately, nobody here is
familiar enough with emacs lisp to implement this, but I'd be very glad
to help somebody with some emacs lisp skills to work on such a project.

Regards,    Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...


_______________________________________________
emacs-bidi mailing list
emacs-bidi@...
http://lists.gnu.org/mailman/listinfo/emacs-bidi

[Eli Zaretskii]

> Date: Fri, 27 Nov 2009 20:11:47 +0900
> From: "Martin J. Dürst" <duerst@...>
> CC: Gregg Reynolds <gar@...>, emacs-bidi@..., emacs-devel@...
>
> On 2009/11/27 1:10, Eli Zaretskii wrote:
> >> Date: Thu, 26 Nov 2009 08:58:39 -0600
> >> From: Gregg Reynolds<gar@...>
>
> >> It's also a major pain to edit XML in a bidi editor.  And I do mean
> >> major.
> >
> > Again, an explicit list of main problems would be useful (although I
> > deliberately decided not to handle bidirectional editing for meta
> > documents yet, so this specific class of problems is still a long way
> > from being dealt with).
>
> This is a well-known problem. For some more background and some attempt
> at a solution, please see:
>
> http://www.sw.it.aoyama.ac.jp/2005/pub/IUC28-bidi/ and
> http://www.sw.it.aoyama.ac.jp/2008/pub/IUC32-bidi/

Thanks.

As I pointed out elsewhere, this class of problems is currently beyond
the scope of what I'm trying to do in Emacs.  That is because the
display engine basically examines characters one by one, so correct
display of XML/HTML using just UAX#9 algorithm is impossible, as you
and others have found out.

I think that support for bidi editing of documents that use markup
languages should be based on the features that exist as part of the
markup: ‎/‏, the dir= directive etc.  Using these, a Lisp
application should place overlays or maybe text properties on the
portions of text that need to be reordered.  For example, one could
place an overlay on a portion of the buffer with `display' property
whose value is the reordered text of that portion (it will have to be
enclosed in LRO..PDF embedding to avoid the automatic reordering when
the display string is delivered to the glass).  Or we could add a new
overlay property that would just tell the display engine "reorder this
part".  Then the display engine will DTRT guided by these overlays and
text properties.

However, please note that the above is not something I thought about
long enough to be convinced that it is the right solution.  The only
thing I convinced myself in at this point is that bidi support for
markup languages should not be on the basic display engine level,
which is what I'm currently hacking.  Rather, it should use the basic
reordering capabilities of the display engine in some way, but do some
additional work on higher levels to implement the equivalent of the
UAX#9 ``higher protocols''.

> In a discussion with Ken'ichi Handa and Naoto Takahashi in 2005, they
> pointed out that using bidi marks in overlays should make it possible in
> bidi emacs to address this problem. Unfortunately, nobody here is
> familiar enough with emacs lisp to implement this, but I'd be very glad
> to help somebody with some emacs lisp skills to work on such a project.

Thanks for the offer.  I don't know when I will get to those parts.
For now, text properties and overlays are not yet supported in the
modified display engine -- that is the very next problem on my agenda.
When these parts are done, hopefully others could come on board and
implement markup support on top of that.



_______________________________________________
emacs-bidi mailing list
emacs-bidi@...
http://lists.gnu.org/mailman/listinfo/emacs-bidi

["Martin J. Dürst"]

Hello Eli,

Many thanks for your comments. I very much agree with what you say,
namely that good display for HTML/XML (and similar stuff) should be at a
level above the basic bidi support, and that it may be implemented by
somebody else than you.

Nevertheless, I very much look forward to hear from Gregg (and others)
about what they see as the current problems with bidi editing (such as
the issue with carret placement that Gregg mentioned).

Regards,   Martin.

On 2009/11/27 21:24, Eli Zaretskii wrote:

>> Date: Fri, 27 Nov 2009 20:11:47 +0900
>> From: "Martin J. Dürst"<duerst@...>
>> CC: Gregg Reynolds<gar@...>, emacs-bidi@..., emacs-devel@...
>>
>> On 2009/11/27 1:10, Eli Zaretskii wrote:
>>>> Date: Thu, 26 Nov 2009 08:58:39 -0600
>>>> From: Gregg Reynolds<gar@...>
>>
>>>> It's also a major pain to edit XML in a bidi editor.  And I do mean
>>>> major.
>>>
>>> Again, an explicit list of main problems would be useful (although I
>>> deliberately decided not to handle bidirectional editing for meta
>>> documents yet, so this specific class of problems is still a long way
>>> from being dealt with).
>>
>> This is a well-known problem. For some more background and some attempt
>> at a solution, please see:
>>
>> http://www.sw.it.aoyama.ac.jp/2005/pub/IUC28-bidi/ and
>> http://www.sw.it.aoyama.ac.jp/2008/pub/IUC32-bidi/
>
> Thanks.
>
> As I pointed out elsewhere, this class of problems is currently beyond
> the scope of what I'm trying to do in Emacs.  That is because the
> display engine basically examines characters one by one, so correct
> display of XML/HTML using just UAX#9 algorithm is impossible, as you
> and others have found out.
>
> I think that support for bidi editing of documents that use markup
> languages should be based on the features that exist as part of the
> markup:‎/‏, the dir= directive etc.  Using these, a Lisp
> application should place overlays or maybe text properties on the
> portions of text that need to be reordered.  For example, one could
> place an overlay on a portion of the buffer with `display' property
> whose value is the reordered text of that portion (it will have to be
> enclosed in LRO..PDF embedding to avoid the automatic reordering when
> the display string is delivered to the glass).  Or we could add a new
> overlay property that would just tell the display engine "reorder this
> part".  Then the display engine will DTRT guided by these overlays and
> text properties.
>
> However, please note that the above is not something I thought about
> long enough to be convinced that it is the right solution.  The only
> thing I convinced myself in at this point is that bidi support for
> markup languages should not be on the basic display engine level,
> which is what I'm currently hacking.  Rather, it should use the basic
> reordering capabilities of the display engine in some way, but do some
> additional work on higher levels to implement the equivalent of the
> UAX#9 ``higher protocols''.
>
>> In a discussion with Ken'ichi Handa and Naoto Takahashi in 2005, they
>> pointed out that using bidi marks in overlays should make it possible in
>> bidi emacs to address this problem. Unfortunately, nobody here is
>> familiar enough with emacs lisp to implement this, but I'd be very glad
>> to help somebody with some emacs lisp skills to work on such a project.
>
> Thanks for the offer.  I don't know when I will get to those parts.
> For now, text properties and overlays are not yet supported in the
> modified display engine -- that is the very next problem on my agenda.
> When these parts are done, hopefully others could come on board and
> implement markup support on top of that.
>

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...


_______________________________________________
emacs-bidi mailing list
emacs-bidi@...
http://lists.gnu.org/mailman/listinfo/emacs-bidi