Apache OpenOffice (AOO) Bugzilla – Issue 25448
wrong image position at page 10
Last modified: 2013-08-07 14:38:26 UTC
import: wrong image position at page 10
Created attachment 13092 [details] bug doc
MRU->CMC: using 680m24 there seem to be some more objects on page 10, which are placed wrongly. AFAICS there is not only the object group which is slightly wrong, there are also frames, which should be positioned on different pages.
cmc->od: This seems to go wrong on page 9 where the paragraph underneath the frame on this page has a "above" spacing which is honoured in word, but not in writer, so the final paragraph ends up on the next page in word and not in writer. And the first of the incorrectly positioned drawings is anchored to this paragraph. If it was a frame I think it would have flowed to the next page anyway, as a drawing it doesn't ? Its hard to tell because the dialogs to see the anchoring and wrapping etc are all broken in m24/m25 and cause crashes when activated, or don't active at all :-(
OD: It isn't a problem of the 'non-considered' paragraph spacing - it's the special MS Word object positioning algorithm, which isn't supported by the Writer yet. If you open the document in MS Word 2000 and change the paragraph spacing 'above' of all paragraphs on page 9 from 12pt to 0pt, the paragraph, at which the graphic is anchored at, is still on page 10. We figured out that the following seems to happen in MS Word during formatting: (1) The empty paragraph, at which the graphic is anchored at, is formatted on page 10. (2) The graphic is formatted at its proposed position. Because the graphic overlaps with the bottom page border and its wrapping is 'top and bottom', the graphic is 'captured' (it's moved upwards, thus that its bottom equals the page bottom). (3) The empty paragraph is formatted again. Now, it has to wrap around the graphic and thus it is moved to page 10. (4) Because the empty paragraph changes its page due to the graphic position and the graphic's wrapping mode, the paragraph will stay on this page and the graphic will follow its anchor to this page. (5) The graphic is positioned below the empty paragraph, at which its anchored at, on page 10. We are planning to integrate the above described MS Word floating screen object positioning algorithm in OOo 2.0. Thus, setting target to 'OOo 2.0', changing issue type from 'defect' to 'feature' and accepting the issue
Add dependence to issue #27349
By issue #27349 the new object positioning considering the object's wrapping style influence will be implemented. Thus, the object positioning will correspond to Microsoft Word object positioning. Another problem, which is left, is that the shapes, contained in the image on page 10 aren't correctly imported. This will be handled by issue #27541. Thus, adding dependence to this issue.
I decided to handle this issue as a DEFECT.
forgot to set issue type ;-)
Created attachment 18979 [details] stripped document containing one of the shapes, which are grouped on page 10
OD->MM: In the SRC680m60 the import of custom shapes in Writer are activated - see issue 27541. But still such objects aren't imported as custom shapes - see attached document <Shape.doc>, which contains one of the shapes, which are grouped on page 10 in the document <wrong image position at page 10.DOC>. This is the cause, why the position of the grouped object isn't correct, because the text in the shape doesn't wrap as in Microsoft Word.
AMA->OD: Please care of this issue.
Investigation with SJ reveals the following: The shape is imported as a custom shape, but the Microsoft Word import extracts the text of the custom shape and puts it into a new text shape. This text shape is grouped with the custom shape. Suppressing the text extraction in the Microsoft Word import reveals new problems: (1) The custom shape is rotated by 180 degree, but the text isn't rotated. (2) The text has to be wrapped and has to be captured inside the custom shape Further investigation is needed.
OD->MM: Please take over again.
If this couldn't be fixed until OOo2.0, it should be fixed until OOo2.0.1.
mmaher: reassigning to flr. I am no longer responsible for filters.
Considering the effort, the priority, the risk and our resource planning I've to retarget this issue to OOo Later.
Reset assignee on issues not touched by assignee in more than 1000 days.