Created attachment 149409 [details]
Open the attached ODT, created in Writer, containing a single rotated image.
Save as DOCX and reopen (or open it in Word).
=> The image is too big, and falls off to the right (the position is different in Word and Writer).
There's no issue with a DOCX containing a rotated image, originating from Word, and there's no issue with the sample attachment 140588 [details] from bug 116371.
Observed using LO 188.8.131.52.alpha0+ (e0745a11597e5d57eb8001a295314e86810a6027) / Windows 7.
Needs the DOCX part of bug 116371 fix, b226383a83e41bbced9fc2a02dc09a449401ec97.
Created attachment 149410 [details]
Wrongly exported DOCX
Created attachment 149411 [details]
Similar sample DOCX (created in Word)
Roundtripping this file keeps the image correctly rotated.
I confirm it with
Version: 184.108.40.206.alpha0+ (x64)
Build ID: f42554a1886ebe49170c25096dc3281b2c7bb1f4
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-02-08_22:37:30
Locale: en-US (de_DE); UI-Language: en-US
It seems that the following line uses the size of the original image, not the size of the resized image:
aSize = pGrfNode->GetTwipSize();
What complicates things is that the original rSize parameter in DocxAttributeOutput::FlyFrameGraphic(...) is the frame's layout size, which is the bounding rectangle of the resized+rotated image.
What seems to be needed is the size of the resized image, not sure where that is stored/calculated (in ww8::Frame, maLayoutSize is the aforementioned layout size, and maSize is the original size).