Apache OpenOffice (AOO) Bugzilla – Issue 84553
UI strings with ellipsis in menus of Arabic OOo are not RTL
Last modified: 2008-06-19 16:54:30 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.
Created attachment 50301 [details] Dialog in RTL
Created attachment 50302 [details] Dialog in RTL
Reassigning
This is a very critical issue. Please forward to the responsible developer to have it fixed in 2.3.1. Thx!
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 ?
confirm issue.
set Prio to 2
Fixed in CWS vcl85. The BiDi preference has been tipped to RTL for these situations.
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.
@sba: please verify in CWS vcl85
SBA: Verifed in CWS vcl85.
@ hdu Punctuation is direction neutral, so menu entries with that shouldn't need LRE or LRM.
Created attachment 50959 [details] sample with RLE/LRE markers
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
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.
@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.
@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: http://www.unicode.org/unicode/reports/tr9/ 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.
Referring to the unicode.org 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.
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.
Created attachment 50964 [details] Image courtesy of Abdelmonam. This happens across various places in OOo.
EditEngine belongs to the SW project. Regarding the screenshot: please check again with a developer version when "CWS vcl85" has been integrated.
Filed under issue #85360
OK in DEV300_m20. Closed.