Bug 49832 - PRINTING: Writer rasterizes SVG for output to a printer or into PDF, which leads to poor quality laser printing.
Summary: PRINTING: Writer rasterizes SVG for output to a printer or into PDF, which le...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
(earliest affected)
3.5.0 release
Hardware: x86 (IA32) All
: high major
Assignee: Not Assigned
URL: http://en.libreofficeforum.org/node/293
Whiteboard: BSA
Keywords: regression
Depends on: 42092
  Show dependency treegraph
Reported: 2012-05-12 05:20 UTC by Paramonov Valeriy
Modified: 2017-04-17 14:07 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:

good ODT, made with LO 3.4 (87.02 KB, application/vnd.oasis.opendocument.text)
2012-05-12 05:21 UTC, Paramonov Valeriy
bad ODT, made with LO 3.5 (219.78 KB, application/vnd.oasis.opendocument.text)
2012-05-12 05:22 UTC, Paramonov Valeriy
good PDF, made with LO 3.5 from file of LO 3.4 (101.03 KB, application/pdf)
2012-05-12 05:24 UTC, Paramonov Valeriy
bad PDF, made with LO 3.5 from file of LO 3.5 (86.21 KB, application/pdf)
2012-05-12 05:26 UTC, Paramonov Valeriy

Note You need to log in before you can comment on or make changes to this bug.
Description Paramonov Valeriy 2012-05-12 05:20:01 UTC
Problem description: 

There are two files ODT. Old made ​​in version 3.4, new in 3.5. In both files inserted SVG drawing. Both files look the same when you zoom in and see the insert in the vector. But! When you export to PDF or printed file made in version 3.5, SVG rasterized and looks awful. And when you export a file from version 3.5, made in version 3.4 - prints and exports correctly.

I began to understand what was happening. Renamed both files in the zip and unpacked. File from version 3.4 stores the image in the SVM. But the file from version 3.5 stores as it is - in SVG. I think that this leads to a problem with exporting and printing.

I attach two files: odt_v34.odt (svm) and odt_v35.odt (svg). The results of exports in PDF: odt_v34.pdf and odt_v35.pdf respectively.

Steps to reproduce:
1. Insert a simple SVG image into a new text document.
2. Export the document to PDF or prints them.
3. Look at result with different zoom levels.

Current behavior:

Expected behavior:

Platform (if different from the browser): 
Browser: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Comment 1 Paramonov Valeriy 2012-05-12 05:21:50 UTC
Created attachment 61480 [details]
good ODT, made with LO 3.4
Comment 2 Paramonov Valeriy 2012-05-12 05:22:56 UTC
Created attachment 61481 [details]
bad ODT, made with LO 3.5
Comment 3 Paramonov Valeriy 2012-05-12 05:24:51 UTC
Created attachment 61482 [details]
good PDF, made with LO 3.5 from file of LO 3.4
Comment 4 Paramonov Valeriy 2012-05-12 05:26:11 UTC
Created attachment 61483 [details]
bad PDF, made with LO 3.5 from file of LO 3.5
Comment 5 ChrisWe 2012-05-14 05:51:26 UTC
Can confirm this on LibO Win7x32 3.5.3 Writer document with imported SVG saved to PDF. 
See also this thread for a protocol of SVG support (rendering, exporting) of LibO with interesting test files: 

It would be very useful using LibO with vector graphics (SVG) in a profesional way (best PDF output possible).
Comment 6 Paramonov Valeriy 2012-05-16 00:10:32 UTC
Hi. Yes. Forgot to write :) I used a simple SVG. And we have the little printing plant that uses LO for production too.
Comment 7 mahfiaz 2012-05-25 04:29:43 UTC
The same happens when using EPS files. That used to work fine in about 2.3 or so.
Comment 8 gobnat 2012-05-27 16:13:21 UTC
I have the same problem opensuse 11.3 x86_64, LO 3.5.0rc3
Comment 9 Roman Eisele 2012-06-28 09:38:45 UTC
Could this be somewhat related to Bug 51510 - "FILESAVE: Exporting Documents with embedded SVG to doc or docx converts the images to low-resolution pixel graphics"? Just an idea ...
Comment 10 Roman Eisele 2012-07-08 02:06:16 UTC
REPRODUCIBLE with reporter's sample files and LibreOffice (Build-ID: 165a79a-7059095-e13bb37-fef39a4-9503d18), German langpack installed, on MacOS X 10.6.8 German UI.

Just as the original reporter wrote: When viewing with LibreOffice, both .odt files look exactly the same. But on exporting to PDF, "odt_v34.odt" (created with LibO 3.4, confirmed by the file's metadata) exports the page header correctly as vector graphics, but "odt_v35.odt" (created with LibO 3.5, confirmed by the file's metadata) exports the page header as a bitmap image -- and additionally, as a bitmap image of far too low resolution (it's just a preview).
Comment 11 Roman Eisele 2012-07-08 02:07:21 UTC
Changing Component to "Printing and PDF export", as appropriate.
Comment 12 Kevin Ernst 2012-07-14 21:36:37 UTC
Still applies to (RC1). Updating version accordingly.
Comment 13 Roman Eisele 2012-07-15 08:40:22 UTC
(In reply to comment #12)
> Still applies to (RC1). Updating version accordingly.

Thank you for testing with the newest version!

However, please do not change the Version field: the Version field should always contain the FIRST version in which a bug is known to exist, and NOT the last one. The first one is (according to comment #8) 3.5.0 RC 3 = 3.5.0 release.
Comment 14 Xavier Robin 2012-08-20 09:22:14 UTC
It should be noted that the images are not rasterized when exporting to PDF/A-1a (in v. I'm currently using this as a work-around.
Comment 15 bugs 2012-08-27 16:27:04 UTC
(In reply to comment #14)
> It should be noted that the images are not rasterized when exporting to
> PDF/A-1a (in v. I'm currently using this as a work-around.

in v. PDF/A-1a embeded SVGs are still rasterize but in better qualitiy. you can check it by zooming in (approx. 1200%). probably the same in
Comment 16 Zak McKracken 2012-08-29 22:18:29 UTC
If an SVG is using features that cannot be directly translated into postscript, it must be rasterized before printing, and I think that is also the reason why it is rasterized in PDF form. The same happens with EPS, if they somehow contain transparency, or even with Hires PNG files if they have an alpha channel (even if that channel is empty) -- they will be re-rastered.

My workflow for preventing that from happenign with EPS images is: print to file (make sure to use postscript printer!) and convert with ps2pdf, since LO (I'm still stuck with 3.4.4) will always raster EPS otherwise.

The only things that are being preserved regardless are EMF and WMF images (which don't always work for different reasons) and Draw objects, as long as they don't use transparency. This also means that for PDF conversion, converting the SVG to draw first (i.e. having an editable SVG) will solve the problem, although it will not solve the problem of trying convert SVG to ODG, which is not possible without losses, except in simple cases.

I think transparency as well as SVG filter effects (blur for example) are not easily solvable, at least for PDF export.

My current solution for SVGs is to export them as EPS from Inkscape, then use the workflow above. This means I can only use SVG fatures that will survive EPS conversion, but more's not possible if you need a PDF.

My favourite solution for the future is to have LO embed SVGs and EPSs, preserve whatever is possible as vector graphics during PDF export and rasterize the rest at a user-specified resolution. For direct printing, it should be technically possible to render an SVG at the printer's native resolution at printing time, although I don't know how the printer will handle such an amount of data, and how this would have to be implemented in LO.
Comment 17 Zak McKracken 2012-08-29 22:29:52 UTC
Inkscape comes much closer to the ideal behaviour.
It will rasterize effects like blur but will keep vector properties even for shapes overlapping (i.e.: in front of) with the blurred part.
I'm not sure if the libraries that Inkscape uses (Cairo, I suppose?) can also be used to treat SVG objects within Writer documents, but that would be a huge improvement!
Comment 18 Xavi Ivars 2012-09-15 11:37:49 UTC
I've tried to print a file exporting it first to PDF/A-1a and it also worked for me. The image was clear.

Both printing it directly or through a normal export to PDF the render of the image was very blurred
Comment 19 Darko Veberic 2012-09-22 10:33:55 UTC
can confirm this bug on ubuntu 12.04 with LibreOffice Build ID: 350m1(Build:2)...

svg rendered with low resolution in printing and pdf export...
Comment 20 Grasyop 2012-09-24 04:13:25 UTC
I confirm. Same version as Darko Veberic. Exporting first as PDF/A-1a is a workaround.
Comment 21 stfhell 2012-11-24 11:22:14 UTC
LibreOffice 3.4 converted the SVG image to its metafile format (SVM) when it was imported. LibreOffice 3.5 leaves it as SVG, which in principle is a good solution as SVG is a powerful and common file format. The handling of SVG will be improved with the code merged from AOO - see the test files I attached for Bug 42092 (Attachment 70492 [details]). A bit of a problem is that the SVG rendering is still not 100% correct at the moment and will probably take some time to mature.

In the meantime you could use the workaround from Bug 42092 Comment 20: Import SVG to Draw, and copy it via clipboard to Writer. This will convert the SVG to SVM, however.

I think the "regression" should be removed from "keywords": The change from SVM to SVG for vector graphics was done with a good reason; SVG is just not fully supported in current LO versions.
Comment 22 Vitaliy 2012-12-06 05:36:31 UTC - the same problem. It's important.
Comment 23 stfhell 2012-12-06 19:32:41 UTC
(In reply to comment #22)
See Bug 42092 for an explanation of current LO behaviour, especially Bug 42092 Comment 20. LO developers intentionally switched from SVM to SVG as internal storage format with LO 3.5, which causes some problems until LO fully supports SVG. As Michael Meeks explains: It is intentional and won't be fixed in 3.5/3.6 releases.
Comment 24 Michael Stahl (allotropia) 2013-02-01 13:14:44 UTC
can you test if that problem still happens on 4.0, which has
a different SVG implementation?
Comment 25 Maarten 2013-02-04 22:22:25 UTC
Ok big improvement. Images are not rasterized anymore. Saved a file with svg image and exported as PDF. Then opened PDF file in inkscape. Ungrouping works on the images. Explodes into nice vector parts. Redering is also ok on my files. No fill or overlap issues that I have seen. Looks good.
Comment 26 Michael Stahl (allotropia) 2013-02-08 18:35:39 UTC
resolving as per comment #25
Comment 27 a07cd040897db54e103c 2013-09-27 06:12:31 UTC
Added reference to report 68927 (https://bugs.freedesktop.org/show_bug.cgi?id=68927). Seems as if this bug has partly been reintroduced in a version between v3.4.5 and v4.1.1.2.

In v4.1.1.2 SVGs inside the text area are rendered (and exported to PDF) correctly. If the SVG is placed as a background image it seems to be rendered like a bitmap. Exported PDF files then also show bitmap like background.

The behaviour of background SVGs works fine in v3.4.5.
Comment 28 Terrence Enger 2013-10-03 20:04:48 UTC
Setting back to previous status.  Let us use bug 68927 to collect current information.