Apache OpenOffice (AOO) Bugzilla – Issue 95259
Misplacement of Separation characters in BiDi text
Last modified: 2013-11-04 16:25:53 UTC
Hi This issue is actually a re-call of Issue: 92325, except for raising the severity to P2 (instead of P3) and setting the OS to Mac OS X - although I am confident that the problem lies in the base core of the product. Trying to switch to OOo 3 from NeoOffice, I opened a document, which was created on a PC with MS Word, and found that the Separation characters (like: "()", "[]") are misplaced. For example: "(אבגדה)" is displayed: ")אבגדה(". This text is correctly displayed in NeoOffice. Is there a fix for the issue or do you plan fixing it? Thanks!! Shay Zukerman.
Reassigned to SBA.
I see similar behavior in Impress (OOo 3.0 on WinXP). When I create a slide with parentheses enclosing hebrew text, it looks correct, but when I display that slide the parentheses appear "reversed". The exact same presentation, when displayed with OOo 2.4.2, appears correctly both when editing slides and when running the slide show.
I can confirm the Writer bug running OOo version 3.0.0 on Debian Etch.
Duplicate. *** This issue has been marked as a duplicate of 93695 ***
Ooops. Not that one. Reopened. SBA->HDU: Known issue?
Hi As you can see the issue is really crucial and avoids a regular and safe use of the product. The only way to overcome the problem is by placing the formatting right-to-left and left-to-right characters, but that's unacceptable!! Could you please escalate the issue and force to solve it? Thanks!!! Shay
SBA: There is no higher force than the responsible engineer. Having more than one issue in the pipeline and working with things like priority lists. Sad but true, but there is many fish to catch for Mac. OOo 3.0 is the first serious shot. Feel free to make someone contribute more developer ressources as they do not rain yet. Prio2 clearly marks out a severe hinderance equal to crash and data loss, see http://www.openoffice.org/scdocs/ddIssues_EnterModify.html#priority SBA->HDU: A connection to issue 93695? Please proceed.
The problem of reversed RTL parentheses that Micha Silver saw in Impress may be related to Issue 89214. One user reported this problem, and turning off Hardware Acceleration caused the presentation to be shown properly.
I can verify that the issue on WinXP is solved by disabling Hardware Acceleration -- Micha
@thb: why would the directx canvas behave differently?
Hi First I must apologize "SBA" for not replying him. As a software engineer and and as ex-Support Engineer I totally accept his answer about my criticism... Now, it looks like that the latest comment for the above issue are turning to the wrong direction. The original problem was reported for the Mac OSX version, but seems to be related to the core of OOo 3.0. Unfortunately, all the workarounds that were reported lately are related to Windows XP. Has anybody found any workaround for the Mac or Linux? Thanks!! Shay
I haven't seen the problem on Linux, only on MAC OS X. On my Debian Linux OS, it's fine.
@hdu: sure this is the right issue? Otherwise, no idea really, also using vcl, but with a VDev-from-HDC :/
.
Focussing on the Mac-specific part of the problem. The canvas problem is handled in issue 92325. Fixed in CWS ooo31gsl1_ the application-requested BiDi-settings need to be applied to the ATSUI-layout. The remaining problem with ATSUI having problem with mirrored chars is handled in issue 98790.
@sba: please verify in CWS ooo31gsl1. testing hint: compare character ordering with other platforms. If mirroring chars are mirrored wrongly try with a different AAT-font (issue 98790).
Verified in CWS ooo31gsl1
As far as issue 95259 concerned there is no problem when using Russian language in Microsoft Word for Mac OS. It was tested in in master version OOo-dev 3.1 .0 (OOO310m7 Build:9393) for for Mac OS 10.5.6.
Hi I was very disappointed that the problem was not solved in version 3.1.0 and even in the latest version: 3.1.1, which I have just installed. The workaround, which was suggested - using specific kind of fonts do work is a very cumbersome. NeoOffice 3.0 and its predecessors handle the complex text correct, and they're bases on Open Office. Could you please check if it's possible to fix the issue on Mac, since its Hebrew install base keeps growing all the time? Thanks! Shay
move target from past to future
Reassigned to HDU.
Can neither reproduce on OOO320 (m17) nor on DEV300 (m77) with any of the fonts on my system. Maybe also the OSX update to >=10.5.8 helped. Maybe it is also a remainder of the design choice ATSUI does (issue 98790) on how to deal with mirror-candidate chars. Usually we don't try to override the system behavior especially when the system behavior (such as needing prop-tables) is the result of a conscious design choice by the platform provider. By the way, is there a small bugdoc anywhere for the problem that justifies its reopening? When creating, reopening, reassigning or retargeting an issue there are plenty of opportunities to make sure that a bugdoc which isolates a problem is attached. Reassigning back to testing to reproduce the problem and provide the bugdoc.
sba->shayzu/ayaninger: Since this is about importing certain documetns, please attach a bugdoc, thanks. Best: Original Word format + odf re-saved by NeoOffice after import.
Still waiting for a comment... Set keyword "needmoreinfo". Note that OOo 3.3 is available by now as well as younger Mac OS X versions. Please comment, thx.
Created attachment 76099 [details] Saved as doc
Created attachment 76100 [details] Saved as docx Tested on OOo 3.2.1 on Mac OS X Leopard.
Note that the bug occurs on the file saved as doc, but not on the file saved as docx. Both files were saved from Word 2007.
Version 4.0 for mac and still no resolve. This issue is a real pain for me. I would vote all my 5 on it since it's the only bug I ran into. Thanks Edo
AFAIK glyph mirroring works for fonts that define a glyph substitution for this mirroring in RTL contexts. For - AOO <= 4.0.x which is based on ATSUI the ATS-fonts for RTL locales have it - AOO >= 4.1 which will be based on CoreText all fonts with proper "rtlm" feature support will work A more general solution could check whether the font supports glyph mirroring for specific glyphs or not and fall back to doing it itself, but the point of using a layout engine is in general to let it do the layout work.