Re: Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM

In article <[email protected]>, Eli Zaretskii <[email protected]> writes:

> > For instance, if you have this text:
> >   r2l contents is embeded here [RLE] R2L CONTENTS [PDF].
> > the current bidi code generates glyphs in this visual order:
> >    ... here [PDF] STNETNOC L2R [RLE].

> Yes, this is intentional: when these formatting characters are
> revealed, they should enclose the text they affect.

There is another way to enclose the text:

    ... here [RLE] STNETNOC L2R [PDF].

I don't know which is good.  Does the current code conform
to "5.2 Retaining Format Codes" of UAX#9?

> > and that means we can't compose [PDF] with the following ".".

> Hmm.. I thought composition works on the buffer text level, i.e. it
> examines characters in logical order (even if it sometimes does it
> backwards).  So you should be able to compose PDF with the period that
> follows it, no?

The current code never composes characters striding over
bidi boundary.

In the above example, when bidi_move_to_visually_next sets
IT's position at [PDF], scan direction is changed, and thus
composition_compute_stop_pos is called to find the next
stop.  In this case, composition_compute_stop_pos scans
buffer backward, and thus it never finds the sequence
"[PDF]."

> > And what should we do when the last character is one of
> > formatting characters?
> > 
> > At last, it seems like an abuse of composition in this case
> > because those formatting characters don't construct a
> > grapheme cluster with the following char.

> OK, I'm convinced.  Let's go with the hide mode instead.  I hope the
> need for one more C-f/C-b will not be confusing.  Maybe we should
> modify cursor motion commands to automatically move past these
> characters?  What do other application do, for example OpenOffice?

In OpenOffice (3.2), we must type Left key twice to move
past one formatting characters.  Gedit is the same.

---
Kenichi Handa
[email protected]