Created attachment 12393 [details]
screen shot- note the word art falling off the page

Created attachment 12394 [details]
original word file

DL->: Could you please handle this?

reassign to MRU, because of a word doc import problem

MRU->MM: The positiong of the object lower on the page (it cannot be seen in
Word initially, due to the vertical justification of the page layout) has been
improved a bit by CWS swdrawpositioning. 
But it should be imported with horizontal positin "-1,76 cm to right page border".

adding dina as cc

Please add keywords: ms_interoperability

mmaher,

I'm Alan Yaniger of Tk Open Systems. I'd like to start working on this bug, if
it's not already fixed.  Could you tell me if you've made some progress on
fixing it?  

added ayaniger as cc

mmaher->ayaniger: No I have done no work on this bug. If you find a fix for this
bug you can attach a patch to this issue and Iw ill help you with integration
(reassign it back to me). I will assign this bug to you for now.

Created attachment 20639 [details]
proposed patch for fix (diffed with m65)

Martin,

In our work with import of graphic objects from MS Word, we found a couple of
places where object positioning data from the Word document  gets modified by
the OOo code. This has caused problems when importing drawing objects, as
described in issue 24255, and other cases as well.

We found that by changing the code, most of the problems went away.

1)

In ww8graf.cxx, in the function ProcessEscherAlign, the following code:

       if (                                                                    
                                                                  
              ((pRecord->nXRelTo == 2) && (pFSPA->nbx != pRecord->nXRelTo))    
                                                                     
              && ((pRecord->nYRelTo == 2) && (pFSPA->nby != pRecord->nYRelTo)) 
                                                                     
              )                                                                
                                                                     
          {                                                                    
                                                                     
              pRecord->nXRelTo = pFSPA->nbx;                                   
                                                                     
              pRecord->nYRelTo = pFSPA->nby;
          }                                                                    
                                                                     
 
is prefaced with a comment:
        Strangely in this case the FSPA value seems to be considered before
        the newer escher nXRelTo record.

This code has caused us problems in import of the document attached to this
issue. We commented out the code. 

2)
        //#111875#
        if ((eHoriRel == REL_PG_FRAME) && (eHoriOri == HORI_RIGHT))
        {
            eHoriRel = REL_FRM_RIGHT;
            eHoriOri = HORI_NONE;
            pFSPA->nXaRight -= pFSPA->nXaLeft;
            pFSPA->nXaLeft = 0;
        }

        //#109311# Miserable miserable hack.
        if (!bDrawingHacks)
        {
            //#109311# Miserable miserable hack.
            long nWidth = (pFSPA->nXaRight - pFSPA->nXaLeft);
            if (MiserableRTLGraphicsHack(pFSPA->nXaLeft, nWidth, eHoriOri,
                eHoriRel))
            {
                pFSPA->nXaRight = pFSPA->nXaLeft + nWidth;
            }
        }

We removed this code as well, and added some code of our own.

You can see the changes in the attached diff (from m65).

3)There are changes made in 

sw/source/core/objectpositioning/anchoredobjectposition.cxx

that you can see in the attached diff with m65.

It's not clear to us which problems the code we removed were meant to address in
the first place. We did testing, though, on all alignments, for both RTL and
LTR, and found that for the most part there were no problems with our changes.
However, we still have a problem with RTL character-anchored objects with
absolute alignment. Also, objects aligned to Inside/margin are still not
imported properly. Any help you can offer with these two problems would be
appreciated. In general, though, we found that this code causes significant
improvement in the location of imported graphics objects.

Re-assigned to mmaher

ayaniger-->mmaher Have you been able to look at and/or test this patch?

mmaher: Reviewing...

Two weeks ago MMAHER asked me to review the patch. Because I'm currently very
busy with fixing issues for OOo 2.0, I haven't got the time for this review. I'm
planning to do it in the next days. Thx for being patient.

OD->ayaniger:
I've got a first look at your patch. 
When loading the given document in SRC680m71 the considtion in the code you
mentioned above as 1) isn't true. Thus, no adjustment is made to <pRecord>. So
why does this code causes problems in importing this document?
Do you checked, if the defects 15718 and 19008, for whose this code is
introduced, are still fixed?

The first part of the code you mentioned above as 2) - it has the comment:
111875 - is needed and already refined by the fix for issue 36649, because
Microsoft Word horizontal position <left to page> respectively <right to page>
doesn't correspond to the Writer horizontal position <left to page> and <right
to page>. Thus, the horizontal position is converted.

The second part of the code you mentioned above as 2) is for converting R2L
horizontal positions - as I know. This code seems to be incomplete and doesn't
fulfill completely the requirements. As I can see, this code is only performed
for objects, which will be imported as Writer fly frames. It isn't performed for
drawing objects -a s the object in the given document. This somehow this is what
this issue is about. This code have to be adjusted I think. Your introduced code
should be this adjustment. Am I right?

I didn't have got a deep look at your changes to the file
<anchoredobjectposition.cxx>. But, I tested the horizontal position <center to
character> and <right to character> in a R2L Writer document and everything is
fine. Thus, why do you want to adjust this code?
This code is about the positioning of anchored objects. If this code isn't
correct or works as excepted, it would do for all documents (not even Microsoft
Word documents). I can't see that this code doesn't work as excepted.

Summary:
In the current situation I can't give my approval to the code change of file
<anchoredobjectposition.cxx>. The removing of the code snips from method
<SwWW8ImplReader::ProcessEscherAlign(..)> isn't clear to me. Your new code in
this method needs further investigations - I think, as mentioned above, it seems
to be a correct step to the conversion of horizontal positions in R2L Microsoft
Word documents, which are still calculated L2R, to R2L Writer positions.
Please give your comments.

ayaniger -> od
Thanks for your helpful comments. I revised the patch accordingly, after
building a more up-to-date environment. The fix I'm attaching is quite simple.
The sample document for this issue has objects with absolute positioning aligned
to column in MS Word. On import to OOo, I set the alignment to "Left Paragraph
Border". Nothing else is changed. There is no change to
anchoredobjectposition.cxx, and no code is removed from ww8graf.cxx.

This only takes care of drawing objects with absolute positioning aligned to
column. Other positioning possibilites must be dealt with as well. I will
continue by working on them. 

I'm attaching a patch with my proposed fix. I'd appreciate your comments.

Created attachment 21849 [details]
Fix for absolute alignment, relative to column

ayaniger -> od
I'm submitting another patch, which also fixes import of RTL objects with
absolute position aligned to margin.

Created attachment 22078 [details]
Patch with fix for alignment to column and to margin

OD->ayaniger:
Your new patch works - thanks.
But it work by change and it works only for drawing objects, not for Microsoft
Word textboxes. That's not your fault.
The position of Microsoft Word textboxes in documents in right-to-left layout
are already correct.
By reviewing your patch I've detected a more general defect:
Because we corrected the representation of drawing object positions in the file
format (OpenDocument file format, extension <odt>), I've implemented some
conversion stuff for reading correctly documents in the former format file
format (OpenOffice.org file format, extension <sxw>). Thus, at the first
positioning of a drawing object, it's position attributes are corrected - see
method <SwAnchoredDrawObject::MakeObjPos()> and its call of method
<_SetPositioningAttr()>. This code is also performed for drawing objects in
import Microsoft Word documents. This isn't intended.

I'll have a closer look at this defect and the solution will also solved this
defect. Stay tuned.

I've got the solution.
Change target to 'OOo 2.0' and raise priority to P3

fix in progress in cws swqbugfixes15

fixed in cws swqbugfixes15 - changed file:
/sw/source/filter/ww8graf.cxx, 1.124.64.1

The credits for this fix goes to ayaniger, who work on this issue and provided
patches, by which the general defect cause is detected. Thanks a lot.

OD->MRU: Checked in internal installation set of cws swqbugfixes15 - please verify.

re-open issue and try to reassign to mru@openoffice.org

try to reassign to mru@openoffice.org

try to reset resolution to FIXED

Fix verified in CWS swqbugfixes15.

Checked integration in 680m86.

Opening the sample file in OOo 2.0.4 causes OOo to crash. 

OD->ayaniger:
I couldn't reproduce a crash.
I opened document "25838345.doc" with OOD680m5 (OOo 2.0.4) on Windows and Linux,
with OOC680m7 (OOo 2.0.3) on Windows and with OOE680m2 (codeline for OOo 2.1) on
Linux. No crash occurred.
Do you have anything special in your installation?

MRU->ayaninger: I also cannot reproduce a cras with mentioned builds. If you
still experience a crash, a new issue should be filed (though it is the same
document like here, it is a new problem).
We must then find out why it crashes on your system. Sending a crash report
could also be helpul. hanks for your patience.

Closed, original problem is solved, a new issue should be filed if crash is
reproducable on certain systems.

Re: the crash
Just to make sure that nothing was corrupted, I redownloaded and reinstalled OOo
2.0.4 on my Win XP Pro machine, and I got the same crash. I submitted a crash
report, and I'll file a seperate issue.

Re: the fix
On my Win XP Home machine, and on my Hebrew build of 2.0.4 on the Win XP Pro
machine, there was fortunately no crash. But unfortunately there still seems to
be a problem with the alignment of the imported Word Art. In Word, the WordArt
object is centered whereas in OOo it is aligned to the left. See screenshots.

Created attachment 40460 [details]
The way it looks in Word

Created attachment 40461 [details]
The way it looks in Writer

This is a different problem. I have filed issue 71381 for it so that this issue
here does not get too overloaded..

Cosed.