Bug 123396 - LO Writer automatically replaces SVGs embedded in (F)ODT files with an embedded low-resolution PNGs and drops the SVGs from the documents
Summary: LO Writer automatically replaces SVGs embedded in (F)ODT files with an embedd...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:svg, regression
Depends on:
Blocks: Writer-Images Regressions-imageHandling
  Show dependency treegraph
 
Reported: 2019-02-12 08:47 UTC by Sebastian Ernst
Modified: 2022-02-10 10:19 UTC (History)
5 users (show)

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


Attachments
demo 01 (127.72 KB, application/vnd.oasis.opendocument.text)
2019-02-12 08:49 UTC, Sebastian Ernst
Details
demo 02 (109.03 KB, application/vnd.oasis.opendocument.text)
2019-02-12 08:50 UTC, Sebastian Ernst
Details
demo 03 (126.97 KB, application/vnd.oasis.opendocument.text)
2019-02-12 08:51 UTC, Sebastian Ernst
Details
demo 04 (107.33 KB, application/vnd.oasis.opendocument.text)
2019-02-12 08:52 UTC, Sebastian Ernst
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Ernst 2019-02-12 08:47:56 UTC
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
Comment 1 Sebastian Ernst 2019-02-12 08:49:27 UTC
Created attachment 149206 [details]
demo 01

"original" document
Comment 2 Sebastian Ernst 2019-02-12 08:50:45 UTC
Created attachment 149207 [details]
demo 02

"edited" FODT ("workaround")
Comment 3 Sebastian Ernst 2019-02-12 08:51:48 UTC
Created attachment 149208 [details]
demo 03

saved once (SVG and PNG, PNG shown)
Comment 4 Sebastian Ernst 2019-02-12 08:52:34 UTC
Created attachment 149209 [details]
demo 04

saved twice (SVG dropped, PNG shown)
Comment 5 Regina Henschel 2019-02-13 00:00:55 UTC
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.
Comment 6 Dieter 2019-06-21 15:03:10 UTC
(In reply to Regina Henschel from comment #5)
> I do not see the error in Version: 5.4.7.2 (x64)

=> possibleRegression?
Comment 7 Nikolaj 2021-09-03 06:52:40 UTC
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.
Comment 8 Mike Kaganski 2021-09-03 07:59:07 UTC
See also bug 51510 comment 22 discussing the low-resolution problem.
Comment 9 Nikolaj 2021-09-10 13:35:31 UTC
(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).
Comment 10 Mike Kaganski 2021-09-10 15:13:05 UTC
(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? ;)
Comment 11 Justin L 2021-10-12 10:00:01 UTC
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ž
Comment 12 Nikolaj 2021-11-17 12:33:50 UTC
(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.
Comment 13 phv 2022-01-23 13:19:03 UTC
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.