Issue 95668 - RTF: parenthesis in RTL mode imported as LTR character
Summary: RTF: parenthesis in RTL mode imported as LTR character
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: OOO300m9
Hardware: Unknown All
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2008-10-30 19:18 UTC by alan
Modified: 2017-05-20 11:15 UTC (History)
5 users (show)

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

bugdoc (302.39 KB, text/rtf)
2008-10-30 19:21 UTC, alan
no flags Details
How it looks in MS Word (126.76 KB, image/jpeg)
2008-10-30 19:21 UTC, alan
no flags Details
How it looks in Writer (110.76 KB, text/rtf)
2008-10-30 19:23 UTC, alan
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description alan 2008-10-30 19:18:06 UTC
When the attached Hebrew RTF document is imported, the trailing parenthesis is
misplaced. See screenshots. Note in the top line how the ending parenthesis has
moved from the left edge to the right edge.

Note also that the image on the top left was lost on import, and that the gray
color in the logo on the top lines has become black.
Comment 1 alan 2008-10-30 19:21:16 UTC
Created attachment 57587 [details]
Comment 2 alan 2008-10-30 19:21:57 UTC
Created attachment 57588 [details]
How it looks in MS Word
Comment 3 alan 2008-10-30 19:23:01 UTC
Created attachment 57589 [details]
How it looks in Writer
Comment 4 alan 2008-10-30 19:27:23 UTC
One solution may be using the method described in issue 18024, namely adding an
RLM after trailing weak chars. I used such a method when fixing a similar
PowerPoint export bug for Issue 39516.
Comment 5 michael.ruess 2008-11-04 10:52:20 UTC
MRU->HBRINKM: see attached document, in the header at the beginning of the
document, Writer imports one of the parenthesis as an LTR character, Formatting
this manually to RTL will show this correctly at the end of the paragraph.
Comment 6 hennerdrewes 2008-11-04 14:35:22 UTC
Although there is the difference in the import results, examining the bugdoc
reveals that the problematic paragraph has LTR direction. 

So this is definitely not an RTF import issue. 
The difference is that word displays the trailing parentheses "correctly" even
when the paragraph direction is "wrong".  

The way the parentheses are displayed is the expected behavior for LTR
paragraphs according to writer's existing functionality. 
Comment 7 alan 2008-11-06 11:08:46 UTC
hennerdrewes is correct. On the one hand, we want the document to like like it
does in Word. On the other, do we want to imitate Word's bizarre features? If
the next version of Word fixes their quirk, then we'll have to remember to fix
it back here, too.
Comment 8 hennerdrewes 2008-11-06 11:41:46 UTC
@ayaniger: We really should look at this problem in a broader scope, as
different similar issues came up in the past. 

Because of the additional directional information that MS uses, similar problems
may occur, if there are weak characters on the boundary of RTL and LTR runs, and
the paragraph direction of OOo flips them to the opposite direction. So
theoretically speaking, there are really a lot of cases where this matters. 

On the other hand in practice, cases like the one in the current bugdoc with
trailing weak characters are probably the most common.

To be most precise, the import (and this is probably necessary for all MS format
imports, rtf, doc, docx etc, and even copy/pasting text) should evaluate the
extra directional information and compare it to our bidi behavior. In simple
cases like the current one, the best fix would be to import the paragraph as
RTL, because this is what is logically intended. (It is just badly formatted.)
If possible, this should be preferred to cluttering the text with RLMs. 

In more exotic cases with changes between LTR and RTL runs, it might be
inevitable to insert RLMs or LRMs.

To sum up, probably there will be need to clarify this translation process
generally, before it could be implemented into different filters. But this could
dramatically improve the import performance of OOo.
Comment 9 Marcus 2017-05-20 11:15:27 UTC
Reset assigne to the default "".