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
Created attachment 61480 [details] good ODT, made with LO 3.4
Created attachment 61481 [details] bad ODT, made with LO 3.5
Created attachment 61482 [details] good PDF, made with LO 3.5 from file of LO 3.4
Created attachment 61483 [details] bad PDF, made with LO 3.5 from file of LO 3.5
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: http://en.libreofficeforum.org/node/293 It would be very useful using LibO with vector graphics (SVG) in a profesional way (best PDF output possible).
Hi. Yes. Forgot to write :) I used a simple SVG. And we have the little printing plant that uses LO for production too.
The same happens when using EPS files. That used to work fine in about 2.3 or so. http://help.libreoffice.org/Common/Export_as_PDF#Images
I have the same problem opensuse 11.3 x86_64, LO 3.5.0rc3
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 ...
REPRODUCIBLE with reporter's sample files and LibreOffice 3.5.4.2 (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).
Changing Component to "Printing and PDF export", as appropriate.
Still applies to 3.6.0.1 (RC1). Updating version accordingly.
(In reply to comment #12) > Still applies to 3.6.0.1 (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.
It should be noted that the images are not rasterized when exporting to PDF/A-1a (in v. 3.5.4.2). I'm currently using this as a work-around.
(In reply to comment #14) > It should be noted that the images are not rasterized when exporting to > PDF/A-1a (in v. 3.5.4.2). I'm currently using this as a work-around. in v. 3.6.0.4 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 3.5.4.2
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.
addition: 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!
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
can confirm this bug on ubuntu 12.04 with LibreOffice 3.5.4.2 Build ID: 350m1(Build:2)... svg rendered with low resolution in printing and pdf export...
I confirm. Same version as Darko Veberic. Exporting first as PDF/A-1a is a workaround.
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.
3.6.3.2 - the same problem. It's important.
(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.
can you test if that problem still happens on 4.0, which has a different SVG implementation?
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.
resolving as per comment #25
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.
Setting back to previous status. Let us use bug 68927 to collect current information.