×××× ×××××, 4 ×××××× 2004, 13:25, ××××:
> Hi Yosef,
> I think that the planning of the solution to iussues 18024 and  27174
> needs to go through Falko Tesch and needs to include input from the Arabic
> users as well.
>
> One way to solve the problem, as you suggest, is to have some user
> initiated signal such as a button on the toolbar that the user can press
> to start an embedded LTR or RTL run. Pressing the button a second time
> inserts a PDO to stop the run.
>
> The problem with this solution is that it requires a lot of user knowledge
> about bidi.
I'm not sure. Encapsulating all English sentence in a square one only need to 
"exit from" in order to stop the English writing is pretty intuitive.
One shouldn't think about it as LRM auto-insertion, but as "Tell OOo when your 
English sentence is over".
Much more intuitive than, say, MS approach for assigning each letter 
directionality without letting the user any sign or explanation about it.
> It also can result in the user starting a run but only 
> pressing the button after the begining of the run, which could result in
> some confusion.
I didn't quite get the case. bressing the STOP button after the beggining of a 
run seems just fine LICH'ORA.
>
> I would prefer a more automatic solution.
Either do I, but it seems a fully working automatical sollution is not 
availible without implementing ThoughtReading facilities :-). There's a 
document showing many cases of context dependant cases of the problem 
mentioned.
>
> An alternative solution might be to automatically insert an RLO or LRO
> whenever the user types a character whose direction is opposite that of
> the paragraph base direction, and then automatically insert a PDO when the
> user types a character whose direction is the same ase the paragraph base
> direction. This would solve the problem with neutral puctuation marks at
> the end of embedded runs that are in the opposite direction from the
> direction of the paragraph.
This IMHO won't solve the problem, as sometimes the user wants the comma after 
the English text and sometimes before.
for instance
I HAVE A KANGAROO WHOSE SPECIES IS kanga manga. HE'S VERY KIND.
you're sollution will result
.DNIK YREV S'EH kanga manga. SI SEICEPS ESOHW OORAGNAK A EVAH I
when of course the correct renderring will be
.DNIK YREV S'EH .kanga manga SI SEICEPS ESOHW OORAGNAK A EVAH I
>
> In either solution, there are cursor control problems that need some
> thought. LRO, RLO and PDO are all zero-width characters. Dispite the fact
> that they are not displayed, we would need to have the cursor stop on them
> so that the user can erase them when need be. It might be best to have a
> double flag on the cursor after an RLO or LRO so the user is aware that a
> there is a directional override character behind the cursor.
In both sollutions these must be invisible, the naive user will be very 
confused to find about these symbols.
> Regards,
>
>  - yba
>
> On Thu, 1 Apr 2004, Yosef Leibovich wrote:
> > Thank you for your quick answer. I proposed this two methods, I thought
> > of the first method at first, but now I think the second method is
> > better. What I actually wanted is your reference to my specific
> > sollution, of which I think highly, but not sure it is really a good one
> > and is it easy enough to implement so that the developers will eventually
> > implement it.
> > So if you're having time (although Pesach is coming) I'll be glad for a
> > comment through the mailing list or through the issuezilla (if you'd
> > like I'll paste your message from the mailing list to the issuezilla and
> > vice versa).
> > Thanks Again.
> > Oh and I'm fixing the classification of the bugs as you explained.
> >
> > Jonathan Ben Avraham wrote:
> > >Hi Chen and YL,
> > >It looks to me like both issues 18024 and  27174 are reporting the same
> > >problem but propose different solutions. Both of these issues are
> > > reported as DEFECT which is incorrect. They might be "defects" at the
> > > level of product requirements, but at the engineering level they are
> > > certainly a missing feature, so they should be either reported as
> > > either FEATURE or ENHANCEMENT.
> > >
> > >To paraphrase the problem: There is currently no way to embed RTL text
> > > in LTR paragraphs or LTR text in RTL paragraphs when the embedded run
> > > of text ends with neutral characters such as a period, question mark or
> > > other punctuation mark, such that the visual placement of the ending
> > > neutral character is at the visual end of the embedded run of text.
> > >
> > >This is certainly an essential feature, whithout which the product could
> > >reasonably be considered defective for bidi users.
> > >
> > > - yba
> > >
> > >On Thu, 1 Apr 2004, Chen Levy wrote:
> > >>-----BEGIN PGP SIGNED MESSAGE-----
> > >>Hash: SHA1
> > >>
> > >>Well, the main bug that sucks in, as a black hole, all the other bugs
> > >>regarding combination of L2R, R2L and neutral characters is: "[Issue
> > >> 18024] - Direction of weak characters: A new method for dealing with
> > >> text direction without using keyboard layout"
> > >>see: http://www.openoffice.org/issues/show_bug.cgi?id=18024
> > >>
> > >>The resolution of this issue suppose to solve the control over
> > >>directionallity, if I understand it correctly.
> > >>
> > >>Unfortunately, the solution that is going to be implemented relies on
> > >> the OS IME (like in Win2K and beyond), and it leaves the rest of us
> > >> (*nix, Win9x) out in the cold.
> > >>
> > >>IMHO you raised a valid point, because control over text directionality
> > >> isn't a nicety. Its a necessity, and I for any solution that will
> > >> solve this problem on all platforms.
> > >>
> > >>>×××× ×××××, 1 ×××××× 2004, 12:45, ××××:
> > >>>Hi,
> > >>>Nowadays there's a big problem to combine English and Hebrew text in
> > >>> the OpenOffice. As of Now, in an R2L paragraph, all punctuations are
> > >>> using CTL fonts and considered R2L, another side-effect of this
> > >>> phenomena is, once an English sentence is typed, and it ends with
> > >>> closing braces they'll be shown in the end of the sentence ("I LIKE
> > >>> MY DOG STYE (cockerspynel) is good" will render as "cockespynel) is
> > >>> good) ELYTS GOD YM EKIL I" see attachment). As of now there's no way
> > >>> for the naive user (who don't know how to insert LRM/RLM signs) to
> > >>> overcome this two troubles, eLaTex's feature \L{}\R{} should solve
> > >>> this issue and will allow the user 100% controll on the document.
> > >>>
> > >>>>Hi YL,
> > >>>>Why do you think that this feature is necessary?
> > >>>>
> > >>>> - yba
> > >>>>
> > >>>>On Thu, 1 Apr 2004, YL wrote:
> > >>>>>What do you think? I'd like to hear comments from hebrew speaking
> > >>>>>users. http://qa.openoffice.org/issues/show_bug.cgi?id=27174
> > >>>>>In short:
> > >>>>>This feature will, once an English character is typed, encapsulate
> > >>>>> it within a square which will denote an in-paragraph English
> > >>>>> sentence. When a special key is pressed the English sentence will
> > >>>>> end, and reguar writing mode will return. Obviously all text inside
> > >>>>> English box will be treated like L2R text, (solving us problems of
> > >>>>> punctuations font, directionality, and many other problems).
> > >>>>>
> > >>>>>BTW this can be implemented using LRM signs in the end of each
> > >>>>>English-sentence box, so that the implementation doesn't need to
> > >>>>>interfere with BIDi and copy/pasting the text will be possible.
> > >>>>>
> > >>>>>==============================================================
> > >>>>>To unsubscribe, send mail to [EMAIL PROTECTED]
> > >>>>>with "unsubscribe hebrew" in the message body.
> > >>>
> > >>>===============================
> > >>>To unsubscribe, send mail to [EMAIL PROTECTED]
> > >>>with "unsubscribe hebrew" in the message body.
> > >>
> > >>- --
> > >>Levy, Chen (mailing lists mail) <mailist at chenlevy dot com>
> > >>Fingerprint: E547 54F9 0246 6533 66B1  8A58 5D9D CF61 2322 0E21
> > >>-----BEGIN PGP SIGNATURE-----
> > >>Version: GnuPG v1.2.3 (GNU/Linux)
> > >>
> > >>iD8DBQFAbCFJXZ3PYSMiDiERAj8OAJ9YD43GExJRrhXNPhZY4cF7tsQHIwCfQOVs
> > >>NioDtljAPLgoqj9lz1mfzoQ=
> > >>=vDkL
> > >>-----END PGP SIGNATURE-----
> > >>===============================
> > >>To unsubscribe, send mail to [EMAIL PROTECTED]
> > >>with "unsubscribe hebrew" in the message body.

=============================================================To unsubscribe, send mail 
to [EMAIL PROTECTED]
with "unsubscribe hebrew" in the message body.

לענות