Issue 24255 - WW8: Hebrew WordArt falls off the page on import
Summary: WW8: Hebrew WordArt falls off the page on import
Alias: None
Product: Internationalization
Classification: Code
Component: BiDi (show other issues)
Version: OOo 1.1.1a
Hardware: All All
: P3 Trivial with 3 votes (vote)
Target Milestone: ---
Assignee: michael.ruess
QA Contact: issues@l10n
Keywords: ms_interoperability
Depends on:
Blocks: 42783
  Show dependency tree
Reported: 2004-01-09 19:34 UTC by sforbes
Modified: 2013-08-07 15:00 UTC (History)
5 users (show)

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

screen shot- note the word art falling off the page (39.40 KB, image/gif)
2004-01-09 19:37 UTC, sforbes
no flags Details
original word file (20.50 KB, application/msword)
2004-01-09 19:38 UTC, sforbes
no flags Details
proposed patch for fix (diffed with m65) (6.93 KB, patch)
2004-12-19 08:43 UTC, alan
no flags Details | Diff
Fix for absolute alignment, relative to column (1.50 KB, patch)
2005-01-25 06:15 UTC, alan
no flags Details | Diff
Patch with fix for alignment to column and to margin (998 bytes, patch)
2005-02-01 10:02 UTC, alan
no flags Details | Diff
The way it looks in Word (84.63 KB, image/jpeg)
2006-11-09 11:40 UTC, alan
no flags Details
The way it looks in Writer (86.34 KB, image/jpeg)
2006-11-09 11:41 UTC, alan
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description sforbes 2004-01-09 19:34:31 UTC
OOo 1.1.1a on osx:
When importing the attached document, the buttom word art falls off the page.
See attached screen shot
Comment 1 sforbes 2004-01-09 19:37:12 UTC
Created attachment 12393 [details]
screen shot- note the word art falling off the page
Comment 2 sforbes 2004-01-09 19:38:33 UTC
Created attachment 12394 [details]
original word file
Comment 3 Dieter.Loeschky 2004-04-06 12:48:46 UTC
DL->: Could you please handle this?
Comment 4 marc.neumann 2004-04-15 07:59:17 UTC
reassign to MRU, because of a word doc import problem
Comment 5 michael.ruess 2004-06-18 09:27:27 UTC
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".
Comment 6 sforbes 2004-06-21 15:25:46 UTC
adding dina as cc
Comment 7 Unknown 2004-07-21 20:47:58 UTC
Please add keywords: ms_interoperability
Comment 8 alan 2004-09-07 11:10:31 UTC

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?  
Comment 9 alan 2004-09-07 11:11:32 UTC
added ayaniger as cc
Comment 10 martin_maher 2004-09-07 11:17:19 UTC
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.
Comment 11 alan 2004-12-19 08:43:23 UTC
Created attachment 20639 [details]
proposed patch for fix (diffed with m65)
Comment 12 alan 2004-12-19 08:46:51 UTC

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.


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. 

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


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.

Comment 13 alan 2004-12-19 12:51:08 UTC
Re-assigned to mmaher
Comment 14 alan 2004-12-23 10:33:47 UTC
ayaniger-->mmaher Have you been able to look at and/or test this patch?
Comment 15 martin_maher 2005-01-07 14:22:10 UTC
mmaher: Reviewing...
Comment 16 Oliver-Rainer Wittmann 2005-01-20 09:19:30 UTC
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.
Comment 17 Oliver-Rainer Wittmann 2005-01-20 12:54:03 UTC
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.

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.
Comment 18 alan 2005-01-25 06:11:19 UTC
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.
Comment 19 alan 2005-01-25 06:15:18 UTC
Created attachment 21849 [details]
Fix for absolute alignment, relative to column
Comment 20 alan 2005-02-01 09:59:53 UTC
ayaniger -> od
I'm submitting another patch, which also fixes import of RTL objects with
absolute position aligned to margin.
Comment 21 alan 2005-02-01 10:02:12 UTC
Created attachment 22078 [details]
Patch with fix for alignment to column and to margin
Comment 22 Oliver-Rainer Wittmann 2005-02-04 14:09:41 UTC
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 ( 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.
Comment 23 Oliver-Rainer Wittmann 2005-02-07 10:23:46 UTC
I've got the solution.
Change target to 'OOo 2.0' and raise priority to P3
Comment 24 Oliver-Rainer Wittmann 2005-02-07 10:36:58 UTC
fix in progress in cws swqbugfixes15
Comment 25 Oliver-Rainer Wittmann 2005-02-07 11:19:53 UTC
fixed in cws swqbugfixes15 - changed file:

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.
Comment 26 Oliver-Rainer Wittmann 2005-02-17 07:21:55 UTC
OD->MRU: Checked in internal installation set of cws swqbugfixes15 - please verify.

re-open issue and try to reassign to
Comment 27 Oliver-Rainer Wittmann 2005-02-17 07:22:01 UTC
try to reassign to
Comment 28 Oliver-Rainer Wittmann 2005-02-17 07:22:06 UTC
try to reset resolution to FIXED
Comment 29 michael.ruess 2005-02-24 11:09:24 UTC
Fix verified in CWS swqbugfixes15.
Comment 30 michael.ruess 2005-03-17 07:58:57 UTC
Checked integration in 680m86.
Comment 31 alan 2006-11-09 09:21:50 UTC
Opening the sample file in OOo 2.0.4 causes OOo to crash. 
Comment 32 Oliver-Rainer Wittmann 2006-11-09 10:04:51 UTC
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?
Comment 33 michael.ruess 2006-11-09 11:15:02 UTC
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.
Comment 34 michael.ruess 2006-11-09 11:17:32 UTC
Closed, original problem is solved, a new issue should be filed if crash is
reproducable on certain systems.
Comment 35 alan 2006-11-09 11:40:03 UTC
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.

Comment 36 alan 2006-11-09 11:40:59 UTC
Created attachment 40460 [details]
The way it looks in Word
Comment 37 alan 2006-11-09 11:41:35 UTC
Created attachment 40461 [details]
The way it looks in Writer
Comment 38 michael.ruess 2006-11-09 15:06:08 UTC
This is a different problem. I have filed issue 71381 for it so that this issue
here does not get too overloaded..
Comment 39 michael.ruess 2006-11-09 15:06:41 UTC