Issue 95259 - Misplacement of Separation characters in BiDi text
Summary: Misplacement of Separation characters in BiDi text
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 3.0
Hardware: Mac Mac OS X, all
: P3 Trivial with 4 votes (vote)
Target Milestone: OOo 3.x
Assignee: AOO issues mailing list
QA Contact:
Keywords: needmoreinfo
Depends on:
Reported: 2008-10-21 12:40 UTC by shayzu
Modified: 2013-11-04 16:25 UTC (History)
8 users (show)

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

Saved as doc (25.50 KB, application/msword)
2011-03-14 18:59 UTC, alan
no flags Details
Saved as docx (9.79 KB, application/msword)
2011-03-14 19:01 UTC, alan
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description shayzu 2008-10-21 12:40:24 UTC

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?


Shay Zukerman.
Comment 1 michael.ruess 2008-10-21 13:09:25 UTC
Reassigned to SBA.
Comment 2 micha_silver 2008-11-05 16:55:36 UTC
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.
Comment 3 alan 2008-11-06 08:50:19 UTC
I can confirm the Writer bug running OOo version 3.0.0 on Debian Etch.
Comment 4 stefan.baltzer 2008-11-13 19:39:33 UTC

*** This issue has been marked as a duplicate of 93695 ***
Comment 5 stefan.baltzer 2008-11-13 19:48:39 UTC
Ooops. Not that one. Reopened.
SBA->HDU: Known issue?
Comment 6 shayzu 2008-11-13 20:27:09 UTC

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?


Comment 7 stefan.baltzer 2008-11-13 21:12:35 UTC
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

SBA->HDU: A connection to issue 93695?
Please proceed.
Comment 8 alan 2008-12-23 08:52:35 UTC
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.
Comment 9 micha_silver 2008-12-23 09:13:59 UTC
I can verify that the issue on WinXP is solved by disabling Hardware Acceleration
Comment 10 2008-12-23 12:14:03 UTC
@thb: why would the directx canvas behave differently?
Comment 11 shayzu 2008-12-23 13:19:01 UTC

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?


Comment 12 alan 2008-12-23 13:24:25 UTC
I haven't seen the problem on Linux, only on MAC OS X. On my Debian Linux OS,
it's fine.
Comment 13 thb 2008-12-27 22:47:17 UTC
@hdu: sure this is the right issue? Otherwise, no idea really, also using vcl,
but with a VDev-from-HDC :/
Comment 14 2009-02-02 13:21:43 UTC
Comment 15 2009-02-03 13:00:34 UTC
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.
Comment 16 2009-02-05 16:05:38 UTC
@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).
Comment 17 stefan.baltzer 2009-02-10 09:48:22 UTC
Verified in CWS ooo31gsl1
Comment 18 vladimir_hitekschool 2009-03-30 22:13:05 UTC
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.
Comment 19 shayzu 2009-09-07 19:47:06 UTC

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?


Comment 20 Martin Hollmichel 2010-03-05 14:46:35 UTC
move target from past to future
Comment 21 stefan.baltzer 2010-03-12 14:38:41 UTC
Reassigned to HDU.
Comment 22 2010-05-10 13:48:56 UTC
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.
Comment 23 stefan.baltzer 2010-09-27 10:29:54 UTC
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.
Comment 24 stefan.baltzer 2011-03-14 15:52:49 UTC
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.
Comment 25 alan 2011-03-14 18:59:42 UTC
Created attachment 76099 [details]
Saved as doc
Comment 26 alan 2011-03-14 19:01:37 UTC
Created attachment 76100 [details]
Saved as docx

Tested on OOo 3.2.1 on Mac OS X Leopard.
Comment 27 alan 2011-03-14 19:03:27 UTC
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.
Comment 28 Edo 2013-11-02 20:01:27 UTC
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.


Comment 29 2013-11-04 16:25:53 UTC
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.