[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bidi looks bad
- To: general at arabeyes dot org
- Subject: Re: bidi looks bad
- From: "ahmad khalifa" <ahmadkhalifa at hotmail dot com>
- Date: Fri, 14 May 2004 21:25:25 +0000
- Cc: developer at arabeyes dot org
From: Muhammad Alkarouri <malkarouri at yahoo dot co dot uk>
Please vote for this bug in Open Office:
http://qa.openoffice.org/issues/show_bug.cgi?id=18024
called 'Direction of weak characters: A new method for dealing with text
direction without using keyboard layout'.
AFAIK this bug is related to hebrew only, because there
are hebrew spaces and english spaces. so hebrew spaces
inside english words mess up the ordering of english text.
there are no arabic spaces, so the bug is irrelevant to us.
your bug (dubbed duplicate of the one above) is what
i meant, but after looking around, it should be solved by
actually setting the paragraph level to the _paragraph level_
i.e if the line contains english chars at the begining it should
be an english paragraph (with paragraph level = 0) so the
punctuation at the end would look correctly positioned.
but in case od (for example) XCHAT, it treats all lines as
paragraph level = 1 (i.e containing Arabic at the begining)
which is not always the case, so the smileys end up on the
left side of the line as if they were on an arabic line.
i think this is caused by XCHAT looking at the env var LANG,
and trying to be too smart.
as your bug's description says "LTR text ending with
punctuation in RTL paragraph misordered"
i think this is the proper way to do it. other than that
you can set Explicit marks (LRM, LRE, LRO) or the paragraph
might be wrongly set (as in XCHAT's case) to arabic.
to sum up the above, after some consideration (didnt
extensively look into it) the ugly text is mainly the
implementation's fault. the algorithm is OK.
And can someone figure out if the new Unicode 4.0.1
http://www.unicode.org/versions/Unicode4.0.1/ has anything about that as
they
seem to indicate in the end of the bug report?
i think the new additions to tr-9 (UAX#9) which are HLX that
deal with higher level protocols (like html tables) should solve
the problem.
thanks for the link. i need to look over the new additions.
I am really interested. I have submitted a bug report some time before to
open
office about that. http://qa.openoffice.org/issues/show_bug.cgi?id=14590
and
they said it is the algorithm. I actually did mention it in developer
before.
The bug was evaluated as a duplicate of the bug mentioned above.
i dont think its a duplicate, they're not the same bug.
i have CCed developer so we can continue the discussion there,
to bring all bidi-concerned parties into this ;-)
i apologize for the redundancy.
ak.
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail