Bug 127071 - FILEOPEN DOCX: Image moves as Below Line is read as From bottom to Line of text (comment 7)
Summary: FILEOPEN DOCX: Image moves as Below Line is read as From bottom to Line of te...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: Anchor-and-Text-Wrap DOCX-Images
  Show dependency treegraph
 
Reported: 2019-08-21 08:05 UTC by seven
Modified: 2023-01-12 20:27 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Sample (17.81 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-08-21 08:05 UTC, seven
Details
comparison MSO 2010 and LibreOffice 6.4 Master (51.06 KB, image/png)
2019-08-21 11:22 UTC, Xisco Faulí
Details
Minimized example file (23.29 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-08-10 13:02 UTC, NISZ LibreOffice Team
Details
The simplified example file in Word and Writer (140.45 KB, image/png)
2021-08-10 13:08 UTC, NISZ LibreOffice Team
Details
position to "line of text" in doc import (223.00 KB, application/msword)
2022-05-24 11:57 UTC, Regina Henschel
Details
position to "line of text" in docx import (55.37 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-05-24 11:59 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description seven 2019-08-21 08:05:09 UTC
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:
Comment 1 seven 2019-08-21 08:05:48 UTC
Created attachment 153547 [details]
Sample

Document for testing
Comment 2 Dieter 2019-08-21 08:29:51 UTC
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.
Comment 3 Xisco Faulí 2019-08-21 11:22:04 UTC
Created attachment 153551 [details]
comparison MSO 2010 and LibreOffice 6.4 Master
Comment 4 Xisco Faulí 2019-08-21 11:24:43 UTC
yep, it's not a footer
Comment 5 Xisco Faulí 2019-08-21 11:25:58 UTC
Also reproduced in

Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Comment 6 seven 2019-08-27 11:10:18 UTC
(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
Comment 7 NISZ LibreOffice Team 2021-08-10 13:02:24 UTC
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.
Comment 8 NISZ LibreOffice Team 2021-08-10 13:08:04 UTC
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.
Comment 9 Timur 2022-02-07 12:59:25 UTC
Original attachment 153547 [details] is LO created DOCX so not relevant.
Comment 10 Regina Henschel 2022-05-24 11:57:11 UTC
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.
Comment 11 Regina Henschel 2022-05-24 11:59:39 UTC
Created attachment 180333 [details]
position to "line of text" in docx import

Same document in docx format.
Comment 12 Regina Henschel 2022-06-18 19:33:44 UTC
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?
Comment 13 Michael Stahl (allotropia) 2022-06-22 10:51:35 UTC
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();