Bug 51510 - FILESAVE: Exporting documents with embedded SVG (e.g. QR code) to doc or docx converts the image to low-resolution pixel graphics
Summary: FILESAVE: Exporting documents with embedded SVG (e.g. QR code) to doc or docx...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:24.2.0 inReleaseNotes:24.2
Keywords: filter:doc, filter:docx
: 121831 135746 138653 140664 141751 147331 150078 151663 158046 (view as bug list)
Depends on:
Blocks: DOCX-Images DOC-Images Image-DPI QR-code
  Show dependency treegraph
 
Reported: 2012-06-28 02:09 UTC by Bernd Sieker
Modified: 2024-07-16 08:27 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT and DOC files, saved from the exact same document, showing problems with doc version. (21.99 KB, application/zip)
2012-06-28 02:09 UTC, Bernd Sieker
Details
Comment 1 case 1: Bernd's .odt sample file saved as .doc file, resolution of bitmap seems better (31.50 KB, application/msword)
2012-06-28 09:19 UTC, Roman Eisele
Details
Comment 1 case 2: .odt file with SVG graphics which seems (!) to get saved as vector graphics to .doc/.docx (194.48 KB, application/zip)
2012-06-28 09:29 UTC, Roman Eisele
Details
Comment 1 case 3: .odt file with SVG graphics which becomes bitmap in .doc/.docx (535.52 KB, application/zip)
2012-06-28 09:31 UTC, Roman Eisele
Details
Collection of screenshots (PNG) showing visual output quality. (838.68 KB, application/zip)
2013-06-08 12:30 UTC, Owen Genat (retired)
Details
An ODT with a scaled small SVG (9.13 KB, application/vnd.oasis.opendocument.text)
2021-03-23 06:38 UTC, Mike Kaganski
Details
Example of TexMaths equation (odt file) (18.18 KB, application/vnd.oasis.opendocument.text)
2023-12-22 16:54 UTC, Roland Baudin
Details
Example of TexMaths equation (docx file) (9.82 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2023-12-22 16:55 UTC, Roland Baudin
Details
Flag of Oman (58.75 KB, image/svg+xml)
2024-02-10 17:08 UTC, Piotr Osada
Details
Flag of Poland (272 bytes, image/svg+xml)
2024-02-10 17:20 UTC, Piotr Osada
Details
Flag of Afghanistan (253.17 KB, image/svg+xml)
2024-02-10 17:25 UTC, Piotr Osada
Details
Flag of Saint Pierre and Miquelon (201.32 KB, image/svg+xml)
2024-02-10 17:27 UTC, Piotr Osada
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Sieker 2012-06-28 02:09:48 UTC
Created attachment 63552 [details]
ODT and DOC files, saved from the exact same document, showing problems with doc version.

When creating a document with SVG images in it, and save it as Microsoft Word document (both .doc and .docx), and reload the document, the SVGs are very low resolution pixel images, even worse than a typical on-screen preview.

The resolution is so low, that even unmagnified, individual pixels can be easily seen on the screen; printout looks completely unacceptable.

Saving and reloading OpenDocument formats retains high-quality vector graphics.

See Attachment.
Comment 1 Roman Eisele 2012-06-28 09:17:39 UTC
At least PARTLY REPRODUCIBLE with LibreOffice 3.5.4.2, German UI, on MacOS X 10.6.8 German.

This is a very interesting issue. I have tried to reproduce it, but the results are complicated.

1) I have tried to save your .odt sample file "SVG-Doc-Bug.odt" as .doc file and .docx file myself. I can confirm that the SVG diagram becomes a bitmap image, therefore REPRODUCIBLE (and set Status > NEW). However, the resolution of the bitmap is a bit better than in your sample .doc file. Therefore, there seems to be some circumstances which have influence on the resolution of the bitmap generated. This is (at least) interesting.

2) I have created some simple .odt sample files which contain some SVG graphics. At least in one case, if I save the .odt file as .doc or .docx file, the .doc and .docx file seem to contain the original vector graphics -- at least, I can scale the .doc and .docx files without any visible loss of quality.

3) In some other cases, if I save the .odt file as .doc or .docx file, the .doc and .docx file contain just bitmap images, just like in the original sample file.

So, this seems to be a complicated issue: in some cases, LibreOffice Writer seems to embed the vector graphics in the .doc/.docx files, in the other cases it just exports a bitmap image to .doc/.docx, and even the resolution of this bitmap image seems to differ in quality.

I will attach sample files for all three cases.
Comment 2 Roman Eisele 2012-06-28 09:19:49 UTC
Created attachment 63571 [details]
Comment 1 case 1: Bernd's .odt sample file saved as .doc file, resolution of bitmap seems better
Comment 3 Roman Eisele 2012-06-28 09:29:29 UTC
Created attachment 63572 [details]
Comment 1 case 2: .odt file with SVG graphics which seems (!) to get saved as vector graphics to .doc/.docx
Comment 4 Roman Eisele 2012-06-28 09:31:26 UTC
Created attachment 63574 [details]
Comment 1 case 3: .odt file with SVG graphics which becomes bitmap in .doc/.docx
Comment 5 Roman Eisele 2012-06-28 09:37:58 UTC
Could this be related to Bug 49832 - "PRINTING: Writer rasterizes SVG for output to a printer or into PDF, which leads to poor quality laser printing"? Just an idea ...
Comment 6 Roman Eisele 2012-07-08 02:09:14 UTC
Changing Component to "Printing and PDF export", as appropriate
Comment 7 stfhell 2012-12-06 19:42:18 UTC
LO 3.5/3.6 stores vector graphics as SVG internally, but every output is done via bitmaps. As Roman says, this is related to Bug 42092. (By the way, attachment 42092, "RNE sample 1, B+W floor plan.zip", also contains only a bitmap, but hi-res.) Word cannot handle SVG, so vector graphics have to be converted to EPS or a WMF format. LO doesn't do that, even the current LO 4.0.0 alpha: it still rasterizes SVG for DOCX output.

Changed component and platform. I think this will be the same on every system.
Comment 8 Michael Stahl (allotropia) 2013-02-08 18:38:22 UTC
can you test if that problem still happens on 4.0, which has
a different SVG implementation?
Comment 9 Owen Genat (retired) 2013-06-08 12:30:51 UTC
Created attachment 80523 [details]
Collection of screenshots (PNG) showing visual output quality.

This bug appears to have two distinct parts. The first (a) appears to be the degradation ("low-resolution pixel graphics"), of a SVG embedded in an ODT file, when the file is saved in DOC/DOCX format. The second (b) seems to be the conversion, of a SVG embedded in an ODT file, to a raster format (e.g., PNG) when the file is saved in DOC/DOCX format. Comment #7 (and related comments in bug #42092) would seem to indicate that this second part is probably unavoidable and thus not a valid consideration for this bug. Microsoft would certainly prefer people use Silverlight in preference to SVG.

This leaves (a) which I think can now be RESOLVED as FIXED. I have tested all the attachments to this bug under Crunchbang 11 running TDF/LO v4.0.3.3 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539) and there is marked improvement in the on screen display for the examples and indiscernable graphic output quality to PDF. This would appear in keeping with the remark in bug #42092#c45. There is however a difference in the nature of some of the attached SVGs that needs to be described. I will refer to the initial attachment as "BS_orig" and the other three attachments as "RME_c1_orig", "RME_c2_orig", and "RME_c3_BS_orig". Each SVG was generated by:

BS_orig = graphviz version 2.28.0.
RME_c1_orig = Inkscape.
RME_c2_orig = Adobe Illustrator 13.0.2, SVG Export Plug-In . SVG Version: 6.00 Build 14948.
RME_c3_BS_orig is simply the ODT from BS_orig resaved as a DOC.

Not all SVGs are equal and SVGs exported from Draw can behave differently again to these examples. This is not an issue for this bug but rather a consideration that must be taken into account when testing with these file formats. It is worth noting that the text in the BS_orig SVG appears formatted differently in some of my tests probably because I do not have the Helvetica Type 1 font installed. The difference described in comment #1 (point 2) and comment #3 is due to the original SVG being converted to an EMF in the DOCX (and probably DOC). The reason for this (under v3.5/3.6) is indicated in comment #7 and in several comments in bug #42092 relating to EPS handling. This is no longer the case under LO v4.0. All ODT files from BS_orig, RME_c1_orig, and RME_c2_orig, when resaved as DOCX include only a PNG.

I have attached a collection of images showing the on screen quality for the various examples and how each ODT/SVG appears when re-saved as DOC/DOCX/PNG. All are taken at 100% zoom with anti-aliasing turn on. The file names should be indicative.
Comment 10 a07cd040897db54e103c 2014-12-18 09:11:21 UTC
Might this bug be a duplicate of bug #68927? Then this one might already be fixed.
Comment 11 QA Administrators 2015-12-20 16:06:51 UTC Comment hidden (obsolete)
Comment 12 Adam Smith 2016-10-05 23:05:37 UTC
I can confirm that this bug still exists. I'm using Writer 4.2.8.2 on a Linux-64 machine. Whenever I save a file with vector graphics as a .docx, it rasterizes all my images and makes the document useless. I hope that someone can fix this soon, because it's severely impacting LibreOffice's utility for me.
Comment 13 Buovjaga 2016-11-12 08:36:19 UTC
(In reply to Adam Smith from comment #12)
> I can confirm that this bug still exists. I'm using Writer 4.2.8.2 on a
> Linux-64 machine. Whenever I save a file with vector graphics as a .docx, it
> rasterizes all my images and makes the document useless. I hope that someone
> can fix this soon, because it's severely impacting LibreOffice's utility for
> me.

Would be better to test with a fresh 5.3: http://dev-builds.libreoffice.org/daily/master/?C=M;O=A
https://wiki.documentfoundation.org/Installing_in_parallel/Linux
Comment 14 Telesto 2016-11-25 18:42:58 UTC
Confirming with:
Version: 5.3.0.0.beta1
Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 15 Xisco Faulí 2017-09-21 22:15:23 UTC
Still reproducible in

Version: 6.0.0.0.alpha0+
Build ID: 86f256596c8566e80993e1cf6035bc3534b6f816
CPU threads: 4; OS: Linux 4.10; UI render: GL; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 16 QA Administrators 2019-03-01 03:50:07 UTC Comment hidden (obsolete, spam)
Comment 17 Justin L 2020-06-16 11:58:33 UTC
Repro 7.1+. Usable in doc/docx, but definitely significantly degraded compared to ODT.
Comment 18 Cor Nouws 2020-07-03 21:58:40 UTC
*** Bug 56691 has been marked as a duplicate of this bug. ***
Comment 19 Justin L 2020-09-28 18:45:38 UTC
*** Bug 135746 has been marked as a duplicate of this bug. ***
Comment 20 Telesto 2021-03-09 15:26:05 UTC
*** Bug 127234 has been marked as a duplicate of this bug. ***
Comment 21 Telesto 2021-03-09 15:26:39 UTC
*** Bug 121831 has been marked as a duplicate of this bug. ***
Comment 22 Mike Kaganski 2021-03-23 06:38:02 UTC
Created attachment 170646 [details]
An ODT with a scaled small SVG

Trying to export this ODT to DOCX will result in awful result.

The SVG there is very simple:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" viewBox="0 0 20 20" stroke="black">
<path d="M1,1L19,19"/>
</svg>

It is defining a bounding box 21x21 logical units, and draws a diagonal from 1,1 to 19,19.

When exported to PNG, VectorGraphicData::ensureReplacement generates a 21x21 *pixels* bitmap, and then that bitmap is saved to the document (and is shown on page scaled to requested dimensions).
Comment 23 Mike Kaganski 2021-03-23 11:32:51 UTC
*** Bug 140664 has been marked as a duplicate of this bug. ***
Comment 24 Telesto 2021-04-19 17:27:26 UTC
*** Bug 141751 has been marked as a duplicate of this bug. ***
Comment 25 Telesto 2022-02-10 10:09:43 UTC
*** Bug 147331 has been marked as a duplicate of this bug. ***
Comment 26 Mike Kaganski 2022-07-20 17:38:33 UTC
*** Bug 150078 has been marked as a duplicate of this bug. ***
Comment 27 Telesto 2022-10-20 19:02:31 UTC
*** Bug 151663 has been marked as a duplicate of this bug. ***
Comment 28 Telesto 2022-10-20 19:08:46 UTC
I'm increasing importance a little.. 
* Usage of QR codes is becoming more common
* Multiple duplicates
Comment 29 Justin L 2023-05-24 15:58:42 UTC
repro 7.6+
Comment 30 Justin L 2023-06-02 15:05:22 UTC
*** Bug 138653 has been marked as a duplicate of this bug. ***
Comment 31 Regina Henschel 2023-08-22 14:06:51 UTC
For export to docx I would expect, that the SVG image is exported as SVG, because modern MS Office are able to render SVG.
Comment 32 Dev 2023-08-24 03:02:55 UTC
(In reply to Regina Henschel from comment #31)
> For export to docx I would expect, that the SVG image is exported as SVG,
> because modern MS Office are able to render SVG.

Or wmf file at least?  We have no idea for now how to implement it but we're willing to give it a try if anyone would like to give us some hints or advice.
Comment 33 Regina Henschel 2023-08-26 22:12:48 UTC
The export uses ShapeExport::WriteGraphicObjectShapePart() in oox/source/export/shape.cxx.
That calls DrawingML::WriteXGraphicBlip() in oox/source/export/drawingml.cxx
That calls DrawingML::WriteImage()
That calls GraphicExport::writeToStorage()
Inside that method is a switch over aLink.GetType(). In case of an SVG-image GetType() returns GfxLinkType::NativeSvg. But the switch has no case for that. Therefore default: is executed.
The default case determines rGraphic.GetType() which is in this case GraphicType::Bitmap. I don't know, why it is that type and could not find the place were it was set.

I'm no expert and have found the above with Visual Studio. Nevertheless it might give you a starting point. My try would be to add a case for SVG.
Comment 34 Commit Notification 2023-10-11 07:32:01 UTC
Darshan-upadhyay1110 committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/60a51b8397154e9685e63cff0a60c1a3da034423

tdf#51510 Blurry QR code after save/reload (docx)

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 35 Commit Notification 2023-10-11 09:39:31 UTC
Darshan-upadhyay1110 committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/f8b547097dc043924f6df89a8c0e8bafd3f9873a

tdf#51510 Blurry QR code after save/reload (docx)

It will be available in 7.5.8.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 36 Commit Notification 2023-10-11 09:39:35 UTC
Darshan-upadhyay1110 committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/a9dbc31fd3db37b2c6c5ca53ab712be76933b9ea

tdf#51510 Blurry QR code after save/reload (docx)

It will be available in 7.6.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 37 Commit Notification 2023-10-11 10:31:44 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/9dc2c25d1b1b732ed1bb1416fcc36558e795a882

Revert "tdf#51510 Blurry QR code after save/reload (docx)"

It will be available in 7.6.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 38 Commit Notification 2023-10-11 10:31:47 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/97e7ea424021239b04924cde50ddc3474e31f8cd

Revert "tdf#51510 Blurry QR code after save/reload (docx)"

It will be available in 7.5.8.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 39 Xisco Faulí 2023-11-02 16:46:05 UTC
*** Bug 158046 has been marked as a duplicate of this bug. ***
Comment 40 Tomaz Vajngerl 2023-12-07 06:42:28 UTC
tdf#126084 should fix this for OOXML and recent MSO versions
Comment 41 Roland Baudin 2023-12-22 16:53:43 UTC
The bug is still there in LO 7.6.4.1.

It affects TexMaths users, see added test files test_equation.odt and test_equation.docx.
Comment 42 Roland Baudin 2023-12-22 16:54:37 UTC
Created attachment 191570 [details]
Example of TexMaths equation (odt file)
Comment 43 Roland Baudin 2023-12-22 16:55:10 UTC
Created attachment 191571 [details]
Example of TexMaths equation (docx file)
Comment 44 Roland Baudin 2023-12-23 19:14:29 UTC
Hi again,

I've seen in comment #34 above that a simple patch has first been applied to solve the issue and then immediately reverted.

I tried the patch (with some adaptation to make it compile) and indeed it fixed the issue.

Here is the patch I applied:

--- a/oox/source/export/drawingml.cxx	2023-12-23 20:06:52.649102333 +0100
+++ b/oox/source/export/drawingml.cxx	2023-12-23 20:06:18.597399308 +0100
@@ -1456,6 +1456,10 @@
             sMediaType = u"image/png"_ustr;
             aExtension = u"png"_ustr;
             break;
+        case GfxLinkType::NativeSvg:
+            sMediaType = u"image/svg"_ustr;
+            aExtension = u"svg"_ustr;
+            break;
         case GfxLinkType::NativeTif:
             sMediaType = u"image/tiff"_ustr;
             aExtension = u"tif"_ustr;


So, I don't understand why the patch has been reverted. Could you explain?
Comment 45 Buovjaga 2023-12-23 19:17:43 UTC
(In reply to Roland Baudin from comment #44)
> So, I don't understand why the patch has been reverted. Could you explain?

If you click the commit hash in the revert commit notification, you can read the reason:

Reason for revert: This can cause compatibility issues with OOXML when they are saved like this because this is not the correct way how SVG should be saved to the OOXML document - it needs to use the OOXML SVG extension so that the image is still shown in old MSO versions. See more 
info in https://gerrit.libreoffice.org/c/core/+/157729.
Comment 46 Roland Baudin 2024-01-08 09:46:31 UTC
OK, I understand there could be some compatibility issues with old versions of MS Office. But for now, there are compatibility issues with current versions of MS Office (at least since MS Office 2016). SVG exported image are blurry.

So I think the benefits of this simple patch should be taken in consideration. Or if you have a better solution, please apply it.
Comment 47 Andras Timar 2024-01-08 14:08:52 UTC
(In reply to Roland Baudin from comment #46)
> OK, I understand there could be some compatibility issues with old versions
> of MS Office. But for now, there are compatibility issues with current
> versions of MS Office (at least since MS Office 2016). SVG exported image
> are blurry.
> 
> So I think the benefits of this simple patch should be taken in
> consideration. Or if you have a better solution, please apply it.

There is a better solution, in comment 40 it was mentioned. The patches have not been backported to LibreOffice 7.6. But LibreOffice 24.2 will be released soon. 
Let's mark this bug as RESOLVED FIXED, too.
Comment 48 Roland Baudin 2024-02-10 14:56:53 UTC
OK, I tested the new LibreOffice 24.2 and the bug is indeed fixed. SVG images are now correctly exported as vector drawings in MS Office docx file format.

That's a very good news. Congratulations to the LibreOffice devs and staff!
Comment 49 Piotr Osada 2024-02-10 17:08:00 UTC
Created attachment 192493 [details]
Flag of Oman

(In reply to Roland Baudin from comment #48)
> OK, I tested the new LibreOffice 24.2 and the bug is indeed fixed. SVG

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 4; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: pl-PL (pl_PL); UI: en-US
Calc: threaded

Yes, it works now. It's a great milestone in DOCX: LO <--> MSO interoperability.  For me, it enables producing more professional documents with vector graphics instead of the so far solution with PNG.

Thank you very much for this work, and I wish you the best. Shalom!

(In reply to Buovjaga from comment #45)
> Reason for revert: This can cause compatibility issues with OOXML

Confirm that: in .DOC files, SVG graphics are not saved by LO.

For some reason/in some cases, LO superior to MSO. For example, the attached country flag (of Oman) is rendered by LibreOffice (in .odt and .docx) while by Microsoft Word not.

Firefox doesn't render this file, and Chrome shows an error:

"""This page contains the following errors:
error on line 3 at column 94: Namespace prefix sodipodi on namedview is not defined"""

So, maybe it's worth displaying some announcement, potentially displayed onto of the graphic or in the information bar under the toolbar? This would lead to an even higher level of convenience for professional users when using LO software.
Comment 50 Piotr Osada 2024-02-10 17:20:01 UTC
Created attachment 192495 [details]
Flag of Poland

You can find these files in digiKam instalation directory on Windows:

...
C:\Program Files\digiKam\data\flags\flag_pl.svg
...

This file shows no errors in web browsers.
Comment 51 Buovjaga 2024-02-10 17:25:12 UTC
(In reply to Piotr Osada from comment #49)
> (In reply to Buovjaga from comment #45)
> > Reason for revert: This can cause compatibility issues with OOXML
> 
> Confirm that: in .DOC files, SVG graphics are not saved by LO.

That's unrelated. DOCX is OOXML while .DOC is the legacy binary format. 

The implementation was done in bug 126084.
Comment 52 Piotr Osada 2024-02-10 17:25:40 UTC Comment hidden (spam)
Comment 53 Piotr Osada 2024-02-10 17:27:07 UTC Comment hidden (spam)
Comment 54 Buovjaga 2024-02-10 17:27:48 UTC
(In reply to Piotr Osada from comment #53)
> Created attachment 192498 [details]
> Flag of Saint Pierre and Miquelon
> 
> Also OK.

Please, it is not necessary to attach every flag picture present in digiKam.