Issue 103357 - WW8: Table in RTL context imported with incorrect alignment
Summary: WW8: Table in RTL context imported with incorrect alignment
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: OOo 3.1
Hardware: All All
: P3 Trivial with 25 votes (vote)
Target Milestone: ---
Assignee: michael.ruess
QA Contact: issues@sw
Keywords: regression
: 103499 (view as issue list)
Depends on:
Blocks: 101565
  Show dependency tree
Reported: 2009-07-06 14:32 UTC by michael.ruess
Modified: 2013-08-07 14:43 UTC (History)
9 users (show)

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

Doc showing problem with RTL table (37.50 KB, application/msword)
2009-07-06 14:35 UTC, michael.ruess
no flags Details
simple RTL table created on Word 2003 - no indent (24.50 KB, application/msword)
2009-07-21 19:33 UTC, alan
no flags Details
simple RTL table created on Word 2003 - with indent (24.50 KB, application/msword)
2009-07-21 19:39 UTC, alan
no flags Details
checks properly for default indent, seprate handling for preferred width (1.59 KB, patch)
2009-07-23 17:51 UTC, alan
no flags Details | Diff
shows the issue on page 3 (3.83 MB, application/msword)
2009-08-24 10:55 UTC, alexbodn1
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description michael.ruess 2009-07-06 14:32:23 UTC
Open attached document -> the table is moved out of the right page border.
This problem is not platform/OS specific.
Comment 1 michael.ruess 2009-07-06 14:35:06 UTC
Created attachment 63400 [details]
Doc showing problem with RTL table
Comment 2 michael.ruess 2009-07-06 14:36:09 UTC
Regression; this worked in 3.0.0.
Target 3.2, because it is a quite special case of a table.
Comment 3 rene 2009-07-06 14:41:11 UTC
fix version info. add 3.1.1 target as regression in 3.1
Comment 4 michael.ruess 2009-07-07 08:41:27 UTC
Though it is a regression from 3.0.1 to 3.1
- we do not have enough resources for 3.1.1
- it is a VERY special case of a table
thus back to 3.2.
Comment 5 rene 2009-07-10 12:19:10 UTC
what is special on this table? Just that it's RTL or something else? I don't
believe RTL counts as "special table"

And I don't buy the resources stuff either, why not get some resources off 3.2
and onto this and fix it in the next possible release and not leave RTL people
in the cold?
Comment 6 michael.ruess 2009-07-10 14:06:22 UTC
I do not know exactly where the difference is, but I can tell you that other RTL
tables are imported correctly and it is not a general problem.
It is not only getting resources off from 3.2. The issue has to be fixed in
3.1.1 AND 3.1.1 so it is granting an additional resource.
Comment 7 michael.ruess 2009-07-13 12:53:29 UTC
Changing summary slightly The alignment of the table is imported wrongly. Should
be "right" instead of "from left".. 
Comment 8 michael.ruess 2009-07-13 12:56:11 UTC
*** Issue 103499 has been marked as a duplicate of this issue. ***
Comment 9 kaplanlior 2009-07-19 12:44:53 UTC
I've asked users which are affected by this bug to vote in order to get it fixed
in 3.1.1 instead of waiting to 3.2. This regression have more effect than you
this it has.
Comment 10 nadavkav 2009-07-19 13:20:45 UTC
changing Table's properties from "From Left" to "Automatically" works around
this issue :-)
Comment 11 alan 2009-07-21 19:27:33 UTC
ayaniger -> hbrinkm:

In ww8par2.cxx, at the end of the function WW8TabDesc::CalcDefaults(),
the statement :

 if (nMinLeft && ((!bIsBiDi && text::HoriOrientation::LEFT == eOri) || (bIsBiDi
&& text::HoriOrientation::RIGHT == eOri)))
       eOri = text::HoriOrientation::LEFT_AND_WIDTH; //  absolutely positioned

is causing the table alignment value to be trounced. Remove it, and the file
gets imported properly. 

(BTW, the test for nMinLeft having a non-zero value seems a little suspect to
me, since it's set to SHRT_MAX at the beginning of the function.)

I created 2 simple documents, each containing a table, using MS Word 2003, with
and without indent. The bug appears on both when I import them into OOo. I'm
attaching them to this issue.

This is a very serious problem for RTL users, and we have already been receiving
complaints. These are not special cases of tables. They are as standard as you
can get. 

BTW, on Windows, LTR files looked ok, but on my Linux build, I found that the
problem exists on LTR tables, too.

Before I submit a patch, I need to better understand absolute positioning in
various versions of Word, and how it's dealt with in OOo. However, since you
have more knowledge in this area, perhaps you can use the information I wrote
above, and fix the code yourself. This is quite important for RTL users. 

Comment 12 alan 2009-07-21 19:33:32 UTC
Created attachment 63675 [details]
simple RTL table created on Word 2003 - no indent
Comment 13 alan 2009-07-21 19:39:29 UTC
Created attachment 63676 [details]
simple RTL table created on Word 2003 - with indent
Comment 14 openoffice 2009-07-22 08:42:14 UTC
I got this one on my list for 3.2 as a high P3. There are some P2s on target 3.2 to cope with before, 
Comment 15 alan 2009-07-22 08:49:05 UTC
--> hbrinkm:

For our Hebrew version, we can't wait until November, when 3.2 is scheduled to
be released. I'll have to deal with it myself, so I would like your advice. If I

if (nMinLeft && ((!bIsBiDi && text::HoriOrientation::LEFT == eOri) || (bIsBiDi
&& text::HoriOrientation::RIGHT == eOri)))


if (nMinLeft && ((!bIsBiDi && text::HoriOrientation::LEFT == eOri) ))

what damage could this cause? What type of WW8 tables should I check for, and
from which versions of Word?
Comment 16 openoffice 2009-07-22 09:47:11 UTC

The if-guard was introduced by your patch from issue 28656. I see no apparent damage caused. However, 
the error document from issue 28656 should be tested to import fine.
Comment 17 limor 2009-07-22 11:35:02 UTC
Comment 18 alan 2009-07-23 17:51:06 UTC
Created attachment 63705 [details]
checks properly for default indent, seprate handling for preferred width
Comment 19 alan 2009-07-23 18:01:35 UTC
I've submitted a patch, which does two things:

1) Fixes check for 0 indent. Until now the code thought that a 0 value for
nMinLeft meant 0 indent. If the value was not zero, the table was aligned "From
Left", instead of "Left" or "Right". In fact, for default alignment, the value
is -108, which is the initial value read from the document into the first
element of the nCenter array, which is then assigned to nMinLeft. I did not
change this for LTR tables, since most of my testing was for RTL tables. But I
think this needs to be changed for LTR tables as well.

2) Did separate handling for cases of with and without a "preferred width" value.

RTL users would be pleased if you could check the patch and, if it passes QA,
integrate it in the next release.
Comment 20 kaplanlior 2009-07-24 15:38:31 UTC
@mru - please consider assigning this back to 3.1.1 due to the amount of votes
for this issue.

Comment 21 mdxonefour 2009-07-27 09:21:10 UTC
MD: Thanks to ayaninger for providing a patch. As discussed with Henning, he
will be able to prepare a CWS containing this fix later this week.

Setting target back to 3.1.1
Comment 22 openoffice 2009-07-28 10:19:56 UTC
Patch conflicted with fix for issue 101451. So, I adapted the patch to reflect the changes in issue 101451 and this 
one. After applying the modified patch, the tables are not shifted out of the text area of the document. However 
there remains a slight shift. I consider the show stopper handled and will file a follow-up issue.

Sending        source/filter/ww8/ww8par2.cxx
Committed revision 274390.
Comment 23 openoffice 2009-07-28 10:27:51 UTC
The follow-up is issue 103854.
Comment 24 openoffice 2009-07-31 10:37:50 UTC
ready for QA
Comment 25 michael.ruess 2009-08-03 14:01:05 UTC
Verified in CWS hb311fixes03.
Comment 26 alexbodn1 2009-08-24 10:51:37 UTC
thank you for your activity to fix this issue. however i couldn't test the
following with left to right documents, here's an issue with 2 tables.
in msword, the second is to the right of the first.
look on page 3 of the attached doc.
Comment 27 alexbodn1 2009-08-24 10:55:47 UTC
Created attachment 64338 [details]
shows the issue on page 3
Comment 28 michael.ruess 2009-08-24 12:53:45 UTC
MRU->alexbodn1: this problem is again a problem of the "floating table" feature
which is not supported by Writer. Here, the anchor of the frame os wrong.
Handled in issue 44181.
Comment 29 alexbodn1 2009-08-24 14:18:54 UTC
ok, so a table can't reside in a frame for the present.
thanks a lot for your clarification,
Comment 30 michael.ruess 2009-10-07 12:37:28 UTC
Checked in DEV300m60.