Description: LO Writer automatically replaces SVGs embedded in (F)ODT files with an embedded low-resolution PNGs and drops the SVGs from the documents. This bug is consistently present in various documents and always reproducible. The "replacement PNGs" are of very low quality / resolution, which can apparently not be adjusted - rendering certain types of documents unusable. Steps to Reproduce: (See attached documents.) Let's say there is an "original", previously known to work text document: demo_01_svg-plus-png_png-shown.fodt It has an SVG in a frame in the top right corner of the page. Looking at the plain XML, one can see an SVG and a PNG inside the frame ("stacked"). Open the document. Change it (a single space is enough) and save it once. Keep it open or re-open it, edit it AGAIN for a second time (yet another space for instance) and save again. Before, in-between and after, export to PDF and check the results. Actual Results: If the original document, demo_01_svg-plus-png_png-shown.fodt, is opened with LO Writer 6.1, only the PNG is shown and used for PDF export. Because this was really annoying (and I needed the document to work), I looked into the XML and removed the PNG, leaving ONLY the SVG. An example is given in demo_02_svg-only_svg-shown.fodt. If opened with LO Writer 6.1, the SVG is shown properly and the PDF export also uses the SVG. If the new document is saved ONCE, the PNG is added "underneath" the SVG like before, restoring (more or less) the "original" state of the document, see demo_03_saved-once_svg-and-png_png-shown.fodt. If re-opened, only the PNG is shown. If the new document is saved TWICE (or more) - even without any actual edits - the SVG is DROPPED from the document, leaving ONLY the PNG inside, see demo_04_saved-twice_svg-dropped_png-shown.fodt. Expected Results: LO Writer shoud (a) display the SVG and (b) use it when exporting the document to PDF. LO Writer should NOT alter the SVG or replace it when (unrelated) edits are made to the document. Reproducible: Always User Profile Reset: Yes Additional Info: Linux: openSUSE Leap 42.3 x86_64, unmodified official distribution packages Last LO version likely not affected: 6.0 LO version bug was likely introduced with: 6.1
Created attachment 149206 [details] demo 01 "original" document
Created attachment 149207 [details] demo 02 "edited" FODT ("workaround")
Created attachment 149208 [details] demo 03 saved once (SVG and PNG, PNG shown)
Created attachment 149209 [details] demo 04 saved twice (SVG dropped, PNG shown)
As described: A file with only svg image saved results in file with svg image and png image. That file saved results in a file with only png image. I see the error in Version: 6.3.0.0.alpha0+ (x64) Build ID: 7c304fa6a99d1c30cf1bc6774612d96b382041d8 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; Locale: de-DE (en_US); UI-Language: en-US Calc: threaded and in Version: 6.1.4.2 (x64) Build ID: 9d0f32d1f0b509096fd65e0d4bec26ddd1938fd3 CPU threads: 8; OS: Windows 10.0; UI render: default; Locale: de-DE (en_US); Calc: CL I do not see the error in Version: 5.4.7.2 (x64) Build ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU threads: 8; OS: Windows 6.19; UI render: default; Locale: de-DE (en_US); Calc: CL That versions has always only the svg image, if I start with a file with only a svg image.
(In reply to Regina Henschel from comment #5) > I do not see the error in Version: 5.4.7.2 (x64) => possibleRegression?
Some research into this error. Lets assume we have an embedded svg <draw:image draw:mime-type="image/svg+xml"> <office:binary-data> Some svg binary data </office:binary-data> </draw:image> After saving Writer adds png data like <draw:image draw:mime-type="image/svg+xml"> <office:binary-data> Some svg binary data </office:binary-data> </draw:image> <draw:image draw:mime-type="image/png"> <office:binary-data> Some binary data </office:binary-data> </draw:image> After opening the file we get exactly png data, not svg. If we delete png data the file will open correctly. Funny enough if I change the order (first png, then svg) the file will once again open correctly.
See also bug 51510 comment 22 discussing the low-resolution problem.
(In reply to Mike Kaganski from comment #8) > See also bug 51510 comment 22 discussing the low-resolution problem. I don't think it is the same bug (although everything in our world is interconnected). Your link points to exactly svg to docx bug. With emf everything works correctly. But this bug concerns any vector format saved in fodt (native format).
(In reply to Nikolaj from comment #9) > this bug concerns any vector format saved in fodt (native format). No. This one is not about "any vector format", it's explicitly filed about SVG; and my link points to the discussion of the reason why the substitute raster is of low resolution. Of course, I never claimed "it is the same bug" - "see also" is somewhat different from "this is a duplicate", right? ;)
Repro 7.3+ Steps to reproduce (for people like me who don't notice any quality problems) 1. Download Demo 02. Notice that the image is crisp and dark black. 2. Round trip it. Notice the letters are a lighter grey. I'm not sure how a 2.5 year old bug can have gone by without a bisect, but it easily points to 6.1 commit 27008aa028cde8d270e898c5743a9fe5c7701dab Author: Tomaž Vajngerl on Mon Mar 5 20:44:08 2018 +0900 xmloff: convert XMLTextParagraphExport to get rid of "GraphicURL" CC'd Tomaž
(In reply to Mike Kaganski from comment #10) > (In reply to Nikolaj from comment #9) > > this bug concerns any vector format saved in fodt (native format). > > No. This one is not about "any vector format", it's explicitly filed about > SVG; and my link points to the discussion of the reason why the substitute > raster is of low resolution. Of course, I never claimed "it is the same bug" > - "see also" is somewhat different from "this is a duplicate", right? ;) I was not clear. Meant the bug, you've pointed to, is solved by using emf. This one isn't) And, found a runaround to the current bug, if you link image instead of embedding it, everything works fine.
The issue is quite serious since the data inserted is modified without the user being informed. This is totally counterproductive and unacceptable. I experienced it recently: more than a hundred icons in SVG format forcibly converted to PNG format when saving. There is no way to revert the modifications automatically or manually. Worse, these PNG icons were truncated as they did not respect their initial size. Luckily I had a recent unaffected copy, but what happens to those who don't have one? Just a messed-up document. I have since learned that an option has been added to the expert configuration (bug #115898) and I suggest that it should be made more accessible. But the workaround does not lessen the priority of this issue.