Description: I have verified this with multiple versions of LibreOffice v7.x and when I downgraded to LibreOffice v6.4.7.2 and the issue is not present. Basically images (at least externally linked SVG images anyway) are placed as thumbnail size in the converted document in the versions of 7.x that I have tested (7.2.2 and 7.1.7). This does not occur in version 6.4.7.2 (and 6.4.6.2 or 6.4.7.1 - can't recall for sure which one I had installed before I upgraded to 7.x). Steps to Reproduce: 1.Open a .odt file with externally linked, locally stored SVG images in it 2.Save the file as a Word 2007-365 .docx file 3.Open the .docx file in MS Word 365 Actual Results: Locate any of the SVG images inside the Word document and they will appear thumbnail sized, instead of their original size in the .odt document Expected Results: Images should appear the same size as they were in the .odt document. This is indeed what occurs with v6.x versions of LibreOffice. Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.4.7.2 (x64) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded This is the info. from the version I currently have installed that works. I do not wish to uninstall this version and then reinstall the v7.x as I need to get many files converted asap. The issue is 100% reproducible in v7.x.
Thanks for the report. Please attached a sample file (so a zip with external SVG & ODT linking to it). Making testing easier for volunteers
Created attachment 176129 [details] An ODT file with SVGs linked in it
Effekt is REPRODUCIBLE with reporter's test file Installation of Version:7.2.1.2 (x64); Build ID: 87b77fad49947c1441b67c559c339af8f3517e22; CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win; Locale: de-DE (de_DE); UI: de-DE; Calc: threaded But not with an own small sample document containing an own .svg @reporter: Howcan we know that it's a problem with saving you document from LibO and not a problem with opening the .docx?
Because if you try it with version 6.x, there is no issue. It works fine.
(In reply to theoriginalpaladin from comment #4) > Because if you try it with version 6.x As I told in comment 3 I tested your and my own sample document with 7.2.1.2. But you wrote in your report that you tested with 6.4.7.2, but you set the version picker to 7.0.0.3 release. Which of both tells the truth? BTW my result with Server Installation of Version7.3.0.0.alpha1+ (x64) | Build ID b8d17d754830ab57099dcdfa72a96bfad404ab1a | CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win | Locale: de-DE (de_DE); UI: de-DE | Calc: CL | Special devUserProfile: Effect also is reproducible for reporter's sample document, but not with my own ones.
I have tested with version 7.1.7.2 and 7.2.2.2 as I mentioned in my initial report. I have also tested with 6.4.7.2 and a prior version of 6.x (either 6.4.6.2 or 6.4.7.1, I don't recall which and no longer have it installed or on my computer unfortunately). The problem did not occur with either version of 6.x, but did occur with both versions of 7.x. So I made an assumption that it might be a regression error introduced in 7.x, and because of that and since I could not choose 7.1.7.2 in the bug report, I chose 7.0.0.3, since that was the first release version of 7.x. I hope that all makes sense.
https://git.libreoffice.org/core/commit/a9ec5c6e7b542e3c7788cdfe0aff4512e36491c6
Bibisected with Linux 7.0 repo to https://git.libreoffice.org/core/commit/a9ec5c6e7b542e3c7788cdfe0aff4512e36491c6 tdf#138953: use original (cropped, but unrotated) object size in spPr Áron noted that the original commit was backported to 7.0 and the original is: https://git.libreoffice.org/core/commit/3dc2e629b247873bfbd3190c11152d8d2bab1a03 The first image is on page 12.
Created attachment 190265 [details] A minimal reproducer This is the minimal file. Interesting is, that re-saving as ODF both this, and the original bugdoc in current versions would produce files, that export fine to DOCX (after reload). The difference is the size of the image - in this file, it's stated as 2 cm by 1 cm, but scaled to whole width; the small size gets exported to DOCX. But re-saving would produce 17 x 8.5 cm in the new file, and that would get exported then. I don't know at the moment, how to properly export it to DOCX, preserving the fix for tdf#138953. Obviously, I miss some relations between different transformations written into DOCX, and how our sizes map to them.
The attached document has the rendered size in LayoutSize property. The Size, Width and Height properties are different from LayoutSize. After the document is resaved to odt and load again, Size, Width and Height properties have the same values as LayoutSize property. I don't know why they are initially different. The problem is not related to SVG. I cannot reproduce the size problem with a new document. @Mike: How do you have created your document?
(In reply to Regina Henschel from comment #10) > @Mike: How do you have created your document? I tried to create a minimal reproducer from attachment 176129 [details] (comment 2). I saved it first in a current version, and discovered that the re-saved file works OK. So I tried 7.0, and the resaved file was still problematic. Hence, LO used to generate such problematic files in the past. Then I created a FODT from the ODT, using 7.0; and striped down the file in a text editor, until I got a single image. Then I dropped the SVG from the image, and only kept the PNG fallback - so I ruled out the SVG specific problem. The minimized file still showed the problem with the conversion, so even though we don't produce such files anymore, there's still a problem of handling them. I also replaced the PNG there, to avoid any dependency on specific image properties. Then I re-saved the minimal FODT using a current version, to see the difference, and that was the values of the frame's svg:width / svg:height. In essence: it's still basically that old attachment, stripped down to the bare minimum.
So you worked on the file directly. I have now a way to create the problem from scratch: First step create an HTML-document: 1. Start with a new Writer document. 2. Write one word and insert a small image. 3. Set the image width to 50% relative to Paragraph area. 4. Save the file as HTML. That produces an <img>-element in the HTML file similar to <img src="embedGraphicRelWidth_html_af12dd0b44708d6e.png" name="Image1" align="left" width="50%" height="46"> Second step: 1. Start with a new Writer document. 2. Menu Insert > Text from file... 3. Select the HTML-file you have created in the first step. Breaking the link or not makes no difference. When you now inspect the image, you will find, that LayoutSize property has the stretched width and Size property has the intrinsic size of the image. When you now create the docx-file immediately, the image will not be stretched. LO 7.0 has written the un-stretched size to the svg:width and svg:height attributes when saving as odt, LO 7.6 writes the stretched size. So LO7.6 corrects the inconsistency when saving. I think we have two problems here: (A) Import of a HTML portion does not adapt the Size property. (B) The output to docx when calling e.g. startDMLAnchorInline() in docxattributeoutput.cxx uses a dirty Size property.
(In reply to Regina Henschel from comment #12) > (B) The output to docx when calling e.g. startDMLAnchorInline() in > docxattributeoutput.cxx uses a dirty Size property. I changed to use Size (from previous use of LayoutSize) in 3dc2e629b247873bfbd3190c11152d8d2bab1a03, because Size is unrotated. Likely, that change needed a different approach, but as said, I can't figure which transformations would be needed where then.
*** Bug 146986 has been marked as a duplicate of this bug. ***