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.
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.
Created attachment 63571 [details] Comment 1 case 1: Bernd's .odt sample file saved as .doc file, resolution of bitmap seems better
Created attachment 63572 [details] Comment 1 case 2: .odt file with SVG graphics which seems (!) to get saved as vector graphics to .doc/.docx
Created attachment 63574 [details] Comment 1 case 3: .odt file with SVG graphics which becomes bitmap in .doc/.docx
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 ...
Changing Component to "Printing and PDF export", as appropriate
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.
can you test if that problem still happens on 4.0, which has a different SVG implementation?
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.
Might this bug be a duplicate of bug #68927? Then this one might already be fixed.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
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.
(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
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
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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro 7.1+. Usable in doc/docx, but definitely significantly degraded compared to ODT.
*** Bug 56691 has been marked as a duplicate of this bug. ***
*** Bug 135746 has been marked as a duplicate of this bug. ***
*** Bug 127234 has been marked as a duplicate of this bug. ***
*** Bug 121831 has been marked as a duplicate of this bug. ***
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).
*** Bug 140664 has been marked as a duplicate of this bug. ***
*** Bug 141751 has been marked as a duplicate of this bug. ***
*** Bug 147331 has been marked as a duplicate of this bug. ***
*** Bug 150078 has been marked as a duplicate of this bug. ***
*** Bug 151663 has been marked as a duplicate of this bug. ***
I'm increasing importance a little.. * Usage of QR codes is becoming more common * Multiple duplicates
repro 7.6+
*** Bug 138653 has been marked as a duplicate of this bug. ***
For export to docx I would expect, that the SVG image is exported as SVG, because modern MS Office are able to render SVG.
(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.
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.
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.
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.
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.
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.
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.
*** Bug 158046 has been marked as a duplicate of this bug. ***
tdf#126084 should fix this for OOXML and recent MSO versions
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.
Created attachment 191570 [details] Example of TexMaths equation (odt file)
Created attachment 191571 [details] Example of TexMaths equation (docx file)
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?
(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.
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.
(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.
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!
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.
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.
(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.
Created attachment 192496 [details] Flag of Afghanistan This file is also OK.
Created attachment 192498 [details] Flag of Saint Pierre and Miquelon Also OK.
(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.