Re: about P1 part of BIDI alogrithm

From: Philippe Verdy <>
Date: Tue, 11 Oct 2011 17:44:12 +0200

2011/10/11 Eli Zaretskii <>:
>> Date: Tue, 11 Oct 2011 13:39:36 +0900
>> From: "Martin J. Dürst" <>
>> CC:,
>> > Sorry, I don't follow you.  There's no such "line-folding" in the
>> > Emacs implementation of the UBA.  A line that doesn't fit the window
>> > width is reordered as a whole.  Conceptually, reordering is done
>> > before breaking a long line into continuation lines.
>> This is exactly what I meant. In Emacs, reordering is done before
>> breaking a long line into smaller segments to fit into the width of the
>> display window.
> Okay, then what we have is a simple misunderstanding.  Thanks for
> clearing it up.
>> I called this "line-folding", you call it continuation lines.
> Well, "continuation lines" _is_ the Emacs terminology ;-)
>> But in the bidi algorithm itself, line breaking (be it automatic due to
>> a layout algorithm or explicit due to LS or something similar) is
>> applied *before* reordering. This is very important, because otherwise,
>> content that is logically earlier may appear on later lines, which would
>> be very confusing for readers.
> I know, but implementing this in the Emacs display engine means
> terrible complications, so I opted not to do that, at least for the
> first version of it.

Then your implementation is completely couterintutive: imagine what
will happen if you press enter in a RTL context a line that is
continued below, but all lines parts of a LTR paragraph or document:
all RTL characters in the line after this position (including possily
all the continuation lines below) would suddenly move upward before
the position where you pressed Enter to insert a forced linebreak, and
all RTL characters before that position (including on previous
continued lines) would swap down...

You need to make a distinction between breaks introduced only visually
by automatic linewraps before continuation lines, and true
line/paragraph separators that are encoded in the edited text. They
behave very differently. If you cannot do that, then disable all
linewraps and accept an edit mode where long paragraphs wil scroll

The UBA does not see where you'll insert linewraps as they are
(usually) not encoded (the exception being the LINE SEPARATOR which is
used to indicate the position of a forced linewrap, but not the end of
the paragraph, so it will still blocks the reordering, but NOT the
contextual directionality and the margin side on which the paragraph
will be aligned)

This means that you need to break lines in two separate steps: first
between paragraphs or forced line breaks, then a second after
determining the the direction of all characters and then remplacing
their possible mirroring to infer the position of inserted linewraps
(i.e. the virtual position where there could be a LINE SEPARATOR
producing the same effect; most often where there are whitespaces or
SHY). Reordering will still occur only after this step, and remains
limited to a line not to a full paragraph.
Received on Tue Oct 11 2011 - 10:47:50 CDT

This archive was generated by hypermail 2.2.0 : Tue Oct 11 2011 - 10:47:51 CDT