Description: 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) Actual Results: Footer image in second page Expected Results: Footer image on first page Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 153547 [details] Sample 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: 6.4.0.0.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 Calc: threaded 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 Version: 4.3.0.0.alpha1+ 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 https://cgit.freedesktop.org/libreoffice/core/commit/?id=2f21e4f357ec60450df84ddd858c3cf0a4711b02 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 https://opengrok.libreoffice.org/xref/core/sw/source/filter/ww8/ww8graf.cxx?r=e6de84d4#2432 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 https://bz.apache.org/ooo/show_bug.cgi?id=22673 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; } in https://opengrok.libreoffice.org/xref/core/writerfilter/source/dmapper/GraphicImport.cxx?r=8b4b852a#805 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() in sw/source/core/objectpositioning/tocntntanchoredobjectposition.cxx 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();