Issue 84553 - UI strings with ellipsis in menus of Arabic OOo are not RTL
Summary: UI strings with ellipsis in menus of Arabic OOo are not RTL
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 2.3.1 RC1
Hardware: PC All
: P2 Trivial (vote)
Target Milestone: OOo 2.4
Assignee: stefan.baltzer
QA Contact: issues@gsl
Depends on:
Reported: 2007-12-13 19:02 UTC by okhayat
Modified: 2008-06-19 16:54 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Dialog in RTL (17.42 KB, image/gif)
2007-12-13 19:03 UTC, okhayat
no flags Details
Dialog in RTL (6.41 KB, image/gif)
2007-12-13 19:05 UTC, okhayat
no flags Details
sample with RLE/LRE markers (7.78 KB, application/vnd.oasis.opendocument.text)
2008-01-18 08:38 UTC,
no flags Details
Image courtesy of Abdelmonam. This happens across various places in OOo. (20.58 KB, image/png)
2008-01-18 11:56 UTC, djihed
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description okhayat 2007-12-13 19:02:16 UTC
The UI content (like menus and dialogs) in Arabic translated OOo is not
right-to-left. It's only right aligned.
You can know that because the punctuation marks are not correctly displayed.
I'll attach to screen shots to show what I mean.
Comment 1 okhayat 2007-12-13 19:03:38 UTC
Created attachment 50301 [details]
Dialog in RTL
Comment 2 okhayat 2007-12-13 19:05:29 UTC
Created attachment 50302 [details]
Dialog in RTL
Comment 3 okhayat 2007-12-13 19:08:53 UTC
Comment 4 rafaella.braconi 2007-12-14 12:48:48 UTC
This is a very critical issue. Please forward to the responsible developer to
have it fixed in 2.3.1. Thx!
Comment 5 Joost Andrae 2007-12-14 14:30:19 UTC
Version 2.3.1 has already been released. Code changes are only possible for the
upcoming version.

ja->hdu: Could you please fix that in 2.4.0 ?
Comment 6 Martin Hollmichel 2007-12-18 11:21:43 UTC
confirm issue.
Comment 7 Martin Hollmichel 2007-12-18 11:22:13 UTC
set Prio to 2
Comment 8 2008-01-07 16:01:42 UTC
Fixed in CWS vcl85. The BiDi preference has been tipped to RTL for these situations.
Comment 9 2008-01-11 15:43:49 UTC
It would be better though if the translated strings were consistent regarding their BiDi behaviour in weak 
RTL and LTR contexts, so we could avoid this fragile balancing act.

To illustrate what I mean by this copy one of the problematic translation strings into Writer. Then toggle 
the paragraph's left-to-right and right-to-left preference. If the string's BiDi layout is influenced by the 
toggle and one of the resulting BiDi arrangements are not sufficient, then the translated string should be 
extended with RLE or LRE unicode markers.
Comment 10 2008-01-14 11:10:16 UTC
@sba: please verify in CWS vcl85
Comment 11 stefan.baltzer 2008-01-16 14:59:11 UTC
SBA: Verifed in CWS vcl85.
Comment 12 djihed 2008-01-17 18:08:37 UTC
@ hdu

Punctuation is direction neutral, so menu entries with that shouldn't need LRE
or LRM.
Comment 13 2008-01-18 08:38:55 UTC
Created attachment 50959 [details]
sample with RLE/LRE markers
Comment 14 2008-01-18 08:49:02 UTC
To illustrate my point about using RLE markers wisely please
1. load the sample document above
2. select all the text (e.g. with CTRL-A)
3. toogle the paragraph direction from left-to-right to right-to-left back and forth
the lines with the embedding markers remain stable, the one without changes
Comment 15 djihed 2008-01-18 09:47:05 UTC
Yes, so that's a bug in how OpenOffice handles neutral characters.

In brief: Arabic characters + neutral characters = the whole thing should be
displayed RTL. That is if they stand on their own and they are not polluted by
other latin characters.

Otherwise it is a bug, you shouldn't need RLE or RLM.

To illustrate this, try opening gedit and putting the same sequence ( لا...)
alone on a new line.

You will see the correct behaviour.

I don't follow OOo closely otherwise I would have discovered this, but indeed, I
think OOo does need some serious testing from us RTL'ers.
Comment 16 2008-01-18 10:05:12 UTC
@djihed: if it is a bug that OOo does not use the auto-discoverable writing direction for the paragraph in 
Writer then please submit a followup bug to OOo's SW project.
Comment 17 djihed 2008-01-18 10:43:03 UTC
@hdu : I will study what OOo does and present a complete bug report some time. 

Apparently, the issue is not just in writer, it's in the whole interface: Even
text on the installation dialogue is badly directed: I don't know the
architecture of OOo, so I don't know what element in the stack renders text in
user interfaces. Is it the same as Writer's?

The thing is, there are two issues at play: the direction algorithm (What you
called auto-discoverable writing) and the class of a character (Strong RTL, Weak
RTL, neutral, etc).

See this for more:

Sorry for the repetitive attempts to clear this up, I've just stumbled into this
and discovered that OOo's issues with RTL are deeper than I thought, while I am
still very unfamiliar with OOo and its code.
Comment 18 2008-01-18 11:17:45 UTC
Referring to the document mentioned above here is the current situation: The paragraph level 
is not determined by the rules P1 or P2 mentioned in chapter 3.3.1 of the document but by "a higher-
level protocol", which is visible in the UI (the arrow pointing left or right toward a paragraph symbol). 
Thoughts about a more intuitive user interface are welcome. Please submit a new issue as "enhancement 
request" for the SW project and outline your suggested solution there. Please keep the issue here ontopic 
of the solved problem of wrongly positioned ellipsis in UI menus.

> so I don't know what element in the stack renders text in user interfaces. Is it the same as Writer's?

It's the EditEngine, which was supposed to be a lightweight cousin of the WriterEngine.
Comment 19 djihed 2008-01-18 11:55:11 UTC
That makes sense for Writer - Thanks for the explanation.

RE: "Please keep the issue here ontopic of the solved problem of wrongly
positioned ellipsis in UI menus."

You mean unsolved? Setting a higher level BiDi preference is not the solution.
The solution is to make the EditEngine (that renders the interfaces) correctly
apply the BiDi algorithm, for the interface. Let's leave Writer out of this for
now since that uses a different thing.

I will attach a screenshot that shows that, just a dot "." will make the whole
text LTR, which is quite wrong.

I wanted to report a new bug for this, but there is no "EditEngine" in the
product list, so I'm not sure what the right component is. It spans the whole
list of openoffice programs.
Comment 20 djihed 2008-01-18 11:56:22 UTC
Created attachment 50964 [details]
Image courtesy of Abdelmonam. This happens across various places in OOo.
Comment 21 2008-01-18 12:22:00 UTC
EditEngine belongs to the SW project.

Regarding the screenshot: please check again with a developer version when "CWS vcl85" has been 
Comment 22 djihed 2008-01-18 12:48:27 UTC
Filed under issue #85360
Comment 23 stefan.baltzer 2008-06-19 16:54:30 UTC
OK in DEV300_m20. Closed.