Hi Alan,
Thanks for pointing out some of my unclear thinking in this discussion to
date. Here is my revised take on the problems that the Unicode directional
formatting codes solve:
1. LRE/RLE/PDF
OOo deals pretty well with embedded texts as it is now, both RTL text in
English paragraphs and English in RTL text paragraphs.
I think that I introduced some confusion about this in my earlier posts.
Sorry.
So there should be no need for explicit LRE/RLE/PDF in OOo.
2. LRO/RLO/PDF
No one brought up the "part number problem" that LRO/RLO/PDF solves. It
seems to be pretty rare.
It would be nice to have an easy way to add these characters that came
built-in to OOo.
3. LRM/RLM
The solution that [EMAIL PROTECTED] proposes really is "original" as
claimed, and solves the weak character problem that we all know about in a
very elegant way, and is probably what the user wants, even if it is
"automatic". All that is needed is a way to make sure that the
position of the character is indicated and that the cursor "sees" the
character and the delete key deletes it.
I think that if we are putting this character in automatically, then we
should also offer a convenient way to insert it explicitly.
Finally, I would think that it wouldn't be too hard for us to make up an
OOo build with this feature (the [EMAIL PROTECTED] solution). Can you
or Oleg look into what's involved?
Regards,
- yba
On Tue, 12 Oct 2004, Alan Yaniger wrote:
>
> Hi Jonathan,
>
> It is true that adding an option for the user to insert RTL of LTR
> overrides will solve the problem of weak character direction partially,
> but it's worth noting that it won't solve the problem completely. There
> are 3 types of explicit directional format codes, of which LRO/RLO
> (overrides) is only one. There are also LRE/RLE (embeddings), which act
> differently, since they don't change the directionality of the characters
> that follow it. This becomes apparent in words which combine Latin
> letters, digits, and Hebrew letters. For example, if your base direction
> is RTL, and you type:
>
> FUNCTION <LRE>v12LOW, your display will be : v12WOL NOITCNUF
>
> On the other hand, if you type:
> FUNCTION <LRO>v12LOW, your display will be : v12LOW NOIRCNUF
>
> Actually, the solution suggested in 18024 uses neither RLO/LRO
> or RLE/LRE, but a third type of directive: RLM/LRM (Left-to-Right
> Mark). This simply acts as an invisible RTL or LTR character, with the
> same effect as if it were a visible one.
>
> So on the third (?) hand, if you type:
> FUNCTION <LRM>v12LOW, your display will be : WOLv12 NOITCNUF
>
> Do we want to add options for all three types of markers, to allow for
> more possibilities?
>
> On Sun, 10 Oct 2004, Jonathan Ben Avraham wrote:
>
> > > As for the IME problem, adding a tab that let you manually change it would
> > > be good enough for nix users I think.
> >
> > This is a *great* idea. I have been trying to get Falko Tesch and the
> > Hamburg team to agree to this since August 2002. In fact, it is a
> > generalization of the explicit LRO/LRO/PDO solution that was originally
> > suggested in IssueZilla issue 18024. The tab could be set automatically in
> > MS Windows and possibly MAC OSX and some "well-behaved" *nix
> > systems, and manually in all others. The idea would work well for other
> > languages as well besides Arabic and Hebrew when there is no way to tell
> > from the OS what the OOo language contexts is.
> >
>
>
--
EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il -
==============================================================
To unsubscribe, send mail to [EMAIL PROTECTED]
with "unsubscribe hebrew" in the message body.
