Created attachment 63400 [details]
Doc showing problem with RTL table

Regression; this worked in 3.0.0.
Target 3.2, because it is a quite special case of a table.

fix version info. add 3.1.1 target as regression in 3.1

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.

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?

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.

Changing summary slightly The alignment of the table is imported wrongly. Should
be "right" instead of "from left".. 

*** Issue 103499 has been marked as a duplicate of this issue. ***

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.

btw,
changing Table's properties from "From Left" to "Automatically" works around
this issue :-)

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. 

Thanks.

Created attachment 63675 [details]
simple RTL table created on Word 2003 - no indent

Created attachment 63676 [details]
simple RTL table created on Word 2003 - with indent

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, 
though.

--> 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
change:

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

 to 

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?

@ayaninger:

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.

2

Created attachment 63705 [details]
checks properly for default indent, seprate handling for preferred width

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.

@mru - please consider assigning this back to 3.1.1 due to the amount of votes
for this issue.


Thanks.

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

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.

The follow-up is issue 103854.

ready for QA

Verified in CWS hb311fixes03.

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.

Created attachment 64338 [details]
shows the issue on page 3

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.

ok, so a table can't reside in a frame for the present.
thanks a lot for your clarification,

Checked in DEV300m60.