SVGs inserted in documents also have PNGs created as fallback for the readers that do not support SVG. It is suggested that we may drop the fallback already (bug 114532 comment 35). I suggest that we drop it now in a next version, as it takes space, and also as a testbed for the suggested introduction of WebP+fallback (to see the complications that following removal of the fallback may bring).
UX first. My take is an option for fallback, that should be turned off by default.
+1, but in parallel really do need better fidelity of LO's SVG rendering to canvas, evidenced in bug 88278.
(In reply to V Stuart Foote from comment #2) > +1, but in parallel really do need better fidelity of LO's SVG rendering to > canvas, evidenced in bug 88278. I think this is orthogonal to the PNG fallback as PNG is rendered in LO from the SVG :)
Not sure how much of help UX can be here. I wonder if (expert) users want an option to keep this. With all the discussion around WebP and the upcoming formats that also violate our backward compatibility policy it might be desired by some to keep the document working. Not much of an issue in case of SVG but we should have a consistent solution. Option a1) Tools > Options > Load/Save > General: "[ ] Store fallback graphics in documents" (on/off toggles this for SVG, WebP, JPEG XL, AVIF...) Option a2) Tools > Options > Writer > Compatibility... and the same as above (and the equivalent tabs on other modules) Option a3) Use expert options to control the fallback Option b) Tools > Options > Load/Save > Images: "Store fallback PNG images in the document for [ ] SVG, [ ] WebP..." Option c) Use File > Properties to control the fallback images per document similar to "Save preview image with the document" Option d) Just deprecate the fallback and drop in the next version Option e) Keep fallback and remove manually (kind of Compress or Clean command) My take: d) + a3) for SVG and c) + a1) for the default for content with backward compatibility issues.
I can see the benefit of having a PNG version of an SVG image so that the reader can be simpler. But based on this logic, the ODT should store the PNG version of many other things too: - the used fonts (preparing for a reader that cannot render fonts) - shapes imported from Draw (preparing for a reader than cannot render a Draw object) - even the final look of the page. Therefore, I believe storing everything should not be the default. I could imagine a set of checkboxes at the bottom of the File -> Save As dialog, however. There are already some checkboxes, like: [x] Automatic file name extension [x] Save with password [x] Encrypt with GPG key There is space for more, like: [x] embed SVG images as PNG [x] embed WebP images as PNG [x] embed each page as PNG By default, they all would be off but I can see the use cases for them when the user wants to populate the ODT with rasterized versions.
I think the best default is: A new document will default to no fallback for SVG, but only if using the ODF 1.3 extended (or greater, so in the future 1.4 or greater). Keep the PNG fallback for all existing SVG images, but if new one i added don't. I wonder what control the user can have over this with expert config. Currently the user can disable the fallback images already, so if they are disabled, don't write the fallback. I don't know if any additional setting is needed, but I maybe someone needs additional (per document) settings?
ESC decided to keep fallback compatibility for "a while". If users cannot control a feature or in this case rather fine-tune whether fallback PNG should be saved or not, see also bug 114532 comment 35, we should abstain from any information. No particular decision was taken for SVG and I'd leave this for Tomaz to decide when to do.