Bug 138374 - docx import/export: Problems with a poly-poly
Summary: docx import/export: Problems with a poly-poly
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Dave Gilbert
URL:
Whiteboard: target:7.2.0
Keywords: filter:docx
Depends on:
Blocks:
 
Reported: 2020-11-20 14:43 UTC by Dave Gilbert
Modified: 2020-11-29 18:48 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
odt showing the problem (172.56 KB, application/vnd.oasis.opendocument.text-flat-xml)
2020-11-20 14:43 UTC, Dave Gilbert
Details
ODT vs DOCX in LibreOffice 7.1 vs MSO 2010 (110.90 KB, image/png)
2020-11-27 09:21 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Gilbert 2020-11-20 14:43:07 UTC
Created attachment 167420 [details]
odt showing the problem

This is a break out of part of bug 93675; the orange arrows on the right side.

Open the fodt, save as docx, reload.

1) On current released LO writing a DOCX we don't see the arrows; with https://gerrit.libreoffice.org/c/core/+/106212  we get something _vaguely_ right.

2) Loading the produced docx in both MSO (thanks vmiklos for checking) has the arrows at the top of the page and vertically too large to fit on the page.  The text is correct albeit offset.

3) Loading the same docx in LO has the arrows in about the right place but still way too large.  The text is horizontal rather than rotated.

4) Note LO is writing VML here rather than DrawingML
Comment 1 Dave Gilbert 2020-11-20 21:40:27 UTC
(4) is from 3c0a7cf4f67720f2cca2c4eb543f838d5b644e7f / fdo#75254 that explicitly disabled DML for polypoly.
Comment 2 Dave Gilbert 2020-11-22 16:47:27 UTC
On 10e0a9441609 the size of the arrows in (3) is fixed.

onedrive is a bit upset with the current output; it's little preview thumbnail correctly shows the orange arrows; but opening it fully shows the text and some red crosses instead of the orange arrows.

I'd be interested if someone could try it on a local copy of MSO.
Comment 3 Xisco Faulí 2020-11-23 15:01:53 UTC
Hello Dave,
Thanks for fixing this issue. Unittest added in https://gerrit.libreoffice.org/c/core/+/106424
Comment 4 Commit Notification 2020-11-23 21:09:53 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/da2206c29f0d11914e68332691ab7699b1fd9b45

tdf#138374: sw_ooxmlexport15: Add unittest

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Timur 2020-11-27 07:08:56 UTC
If this bug is fixed, it should be marked Resolved. 
Xisco, please make comparison of ODT and DOCX both in LO and MSO. (I can't).
Comment 6 Timur 2020-11-27 07:14:07 UTC
Also, for any filesave DOCX bug, filesave DOC should be tested (to be sure it's OK, a duplicate, a new bug, if not resolved in the same one).
Comment 7 Xisco Faulí 2020-11-27 09:21:29 UTC
Created attachment 167613 [details]
ODT vs DOCX in LibreOffice 7.1 vs MSO 2010

How it looks after the fix. Keep in mind this ticket is about the orange arrows
Comment 8 Xisco Faulí 2020-11-27 09:22:07 UTC
We have a unittest for it. Closing as VERIFIED FIXED
@Dave, thanks for fixing this issue!
Comment 9 Dave Gilbert 2020-11-29 00:45:10 UTC
Thanks Xisco!
FIrst thanks for the test, also thanks for the test with MS Word.
Interestingly before my 2nd patch, vmiklos had done a MS Word test and had seen the text; but for me on OneDrive it was very very confused by it.

So it suggests that the text is very broken, so it's not just a problem with the odt loading of the text.

I was going to keep this bug open until I fixed the text as well; but I'll fight it separately;  suggestions welcome.
Comment 10 Dave Gilbert 2020-11-29 18:48:01 UTC
Observation:
  Currently the rotated text ends up as:
    mc:Alternate->mc:Choice wps->w:drawing->wp:anchor->
     a:graphic (drawingml/2006/main)->a:graphicData (word/2010/wordprocessingShape) ->
       wps:wsp->wps:spPr->a:xfrm
                wps:txbx
                  w:txbxContent->w:p->w:r->w:t

but I notice oox/source/drawingml/shapecontext.cxx has an entry for XML_txXfrm
for rotation; perhaps something would prefer that?