If i open in google docs it show good, but in libreoffice have problem
Steps to Reproduce:
1. Open document
2. Compare in libreoffice and Google docs (or may be other)
Footer image in second page
Footer image on first page
User Profile Reset: No
Created attachment 153547 [details]
Document for testing
I confirm that in LO image is on page 2 and not on page 1 (I compared with MS Word 2016)
Version: 220.127.116.11.alpha0+ (x64)
Build ID: 3e64065612acec2eb29aa21e2b515953422256d7
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win;
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-08-15_22:57:26
Locale: de-DE (de_DE); UI-Language: en-US
But are you sure, that the image is part of the footer? I don't think so.
Created attachment 153551 [details]
comparison MSO 2010 and LibreOffice 6.4 Master
yep, it's not a footer
Also reproduced in
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
(In reply to Dieter Praas from comment #2)
> But are you sure, that the image is part of the footer? I don't think so.
You right. It is image not part of footer, it part of body document and must be in bottom, like are footer.
I think need rename subject. And thanks for confirmation
Created attachment 174180 [details]
Minimized example file
This shows better what's happening here, without the font replacement differences.
The FOOTER image is positioned at an absolute position of 1.48 cm below the Line of text in Word.
Created attachment 174181 [details]
The simplified example file in Word and Writer
The setting is imported as 1.48 cm From bottom to Line of text.
However this is incorrect since Writer measures things differently.
Changing it manually to -1.48 cm puts it into the correct place. That would be similar to the change
tdf#139915 DOCX import: fix anchored obj position with to-char and TEXT_LINE
Somehow that affected only drawing shapes and not images, but the same thing would be needed here too.
Original attachment 153547 [details] is LO created DOCX so not relevant.
Created attachment 180332 [details]
position to "line of text" in doc import
The rendering with the same offset is correct for import from binary doc.
The attached document has in the upper part images with position 0px, 50px, -50px relative to line (from left to right). Below is a screenshot of how it looks in Word.
An additional problem with positioning "from bottom by ... to Line of Text" is, that this positioning cannot be expressed in ODF, see bug 149234.
Created attachment 180333 [details]
position to "line of text" in docx import
Same document in docx format.
The binary import in
has these lines:
2432 // Below line in word is a positive value, while in writer its
2433 // negative
2434 tools::Long nYPos = rFSPA.nYaTop;
2435 // #i22673#
2436 if ((eVertRel == text::RelOrientation::TEXT_LINE) && (eVertOri == text::VertOrientation::NONE))
2437 nYPos = -nYPos;
Similar exist for export.
That has been introduced with the patches from
So one way could be to introduces similar toggle of the sign for import/export from docx. But it has to consider image rotation in addition. The import from doc has a bug for rotated images that it imports the image unrotated but scaled into the bounding box of the rotated images.
Only toggling the sign like
if (m_pImpl->nVertRelation == 9 && m_pImpl->nVertOrient == 0)
m_pImpl->nTopPosition = -m_pImpl->nTopPosition;
does not work. The image moves in correct direction, but has a wrong position. I have tried it.
But an addition problem is, that such toggled sign is written to ODF too. That results in the fact, that an image with "from top by 1cm" in file markup moves upwards in LO rendering, in contrast to a shape, which move correctly down with the same file markup.
So my suggestion is, to not fix this by introducing some position manipulating in OOXML import/export. Instead the wrong handling of the vertical position of images in Writer should be fixed.
But I have no idea, where this happens. Any code pointer?
this should be in SwToContentAnchoredObjectPosition::CalcPosition()
apparently there's a "switch ( aVert.GetVertOrient() )" in line 274
that handles most cases except the case
"if ( aVert.GetVertOrient() == text::VertOrientation::NONE )"
is handled separately at line 484.
probably this line?
nRelPosY = nVertOffsetToFrameAnchorPos - aVert.GetPos();