Created attachment 52616 [details]
EXPORT PDF with SVG becomes BITMAP Examples and Screenshots

When initially submitting this attachment we received the following Bugzilla Error:

Bugzilla has suffered an internal error. Please save this page and send it to sitewranglers@lists.freedesktop.org with details of what you were doing at the time this message appeared.
URL: https://bugs.freedesktop.org/post_bug.cgi
Traceback:
at Bugzilla/Mailer.pm line 186 Bugzilla::Mailer::MessageToMTA(...) called at Bugzilla/BugMail.pm line 591 Bugzilla::BugMail::sendMail(...) called at Bugzilla/BugMail.pm line 431 Bugzilla::BugMail::Send(...) called at /srv/bugs.freedesktop.org/www/post_bug.cgi line 252

I see the difference between the export results in "PDF_lossless.pdf" and "PDF_A-1a.pdf" with ARX, but not as drastic as shown in "PDF_lossless_becomes_BITMAP.png" and "PDF_A-1a_becomes_Scalable.png". For me  "PDF_A-1a.pdf" only seems to have a finer resolution (smaller pixels)


@rk601@yahoo.com
Please do not post problems what have nothing to do with the bug report 
(Comment 1).

How did you indicate whether the export contains a raster or a vector graphic?

Really only a master problem?

Can you please explain for what use the lots of files in your test kit are? My WIN IrfanView and WIN PhotoViewer can not open the .png files in "\__MACOSX\SVG_is_Bitmap_as_PDF"

Because I do not know any other way I opened both "PDF_lossless.pdf" and
"PDF_A-1a.pdf" as OOo Drawing, saved as .odp, renamed to .zip, unpacked with IZArc and checked contents of subfolders "Pictures": both contained a .png showing the chemistry set.

comparing size shows png in "PDF_A-1a.odg" with 420 kB comparing to 106 kB in "PDF_lossless.odg", and comparing both png in a picture viewer shows that the png in "PDF_A-1a.odg" has a much better resolution. 

That funds my suspect that none of the exported PDF documents contains a vector graphic.

IMHO this report is only concerning WRITER PDF export. Opening "organick_Chemistry_set.svg" with DRAW, saving, renaming to .zip and unzipping does not show a .png in the Pictures subfolder, and the exported lossless.PDF shows a real vector graphic with out any pixels.

All tests with "LibreOffice 3.4.3  - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]" 

@rk601@yahoo.com:
Can you confirm my latest results?

(In reply to comment #2)
> I see the difference between the export results in "PDF_lossless.pdf" and
> "PDF_A-1a.pdf" with ARX, but not as drastic as shown in
> "PDF_lossless_becomes_BITMAP.png" and "PDF_A-1a_becomes_Scalable.png". For me 
> "PDF_A-1a.pdf" only seems to have a finer resolution (smaller pixels)
> 
> 
> @rk601@yahoo.com
> Please do not post problems what have nothing to do with the bug report 
> (Comment 1).
> 
> How did you indicate whether the export contains a raster or a vector graphic?
> 
> Really only a master problem?
> 
> Can you please explain for what use the lots of files in your test kit are? My
> WIN IrfanView and WIN PhotoViewer can not open the .png files in
> "\__MACOSX\SVG_is_Bitmap_as_PDF"

Many files on the MAC have two parts: a data fork, and a resource fork. For certain files (like some font files), these resource forks are necessary and must be left intact. The MAC OS includes built-in ZIP-compression functionality (which is quickly accessed through contextual menus). We typically compress files and folders with it. The built-in ZIP-compression automatically stores the MAC's hidden metadata in the resource fork and folder __MACOSX. So the hidden __MACOSX folder is automatically created when a MAC creates an archive (also called a zip file). When the zip file is sent to another MAC user, the folder will not appear – because it is a hidden folder, but all of the files and folders will show correctly on a MAC because of the metadata within the hidden folder and files. 

Sometimes these extra metafolder and files will cause confusion. For example, when a MAC user sends the zip file to a PC user then the hidden files are shown on the PC. PC users are often confused by these (seemingly superfluous) files and folders. 

The problem: When we submit examples for LibreOffice we typically use the built-in ZIP-compression which automatically stores the MAC's hidden metadata in the resource fork and folder __MACOSX; the resulting .ZIP file includes a folder called __MACOSX, along with several files that begin with a dot. These “hidden” folders and files do not appear on another MAC, but they do appear on other systems and may cause confusion.

The solution: We will look into techniques to remove these hidden folders and files from the compressed files that we submit to LibreOffice bug tracker - bugzilla – Freedesktop.

On 2011-10-22 00:11:55 PDT in "RESOLVED INVALID/CLONE" BUG #42091 Rainer Bielefeld wrote:

"OOo#118455 - SVG image are exported as bitmap in pdf might be concerning the
same problem."

We reincluded it here for testing and consistency.

On 2011-10-22 00:00:09 PDT Rainer Bielefeld asked:

"How did you indicate whether the export contains a raster or a vector graphic?"

We did a hexdump of the generated files. On review of both "PDF_lossless.pdf" and
"PDF_A-1a.pdf", the SVG pictures both appear to be bitmapped. Apparently, the SVG is not preserved. We believe that SVG should always be used (preserved) unless explicitly changed.

(In reply to comment #4)
> Many files on the MAC have two parts: a data fork, and a resource fork. 

Thx for explication. May be you can leave a short extract here:
<http://wiki.documentfoundation.org/QA-FAQ#Zipped_attachments_of_Mac_users>, If oyu find an easy to use solution to eliminate not needed contents from the .zip it should be published here:
<http://wiki.documentfoundation.org/BugReport>

> We did a hexdump of the generated files. On review of both "PDF_lossless.pdf"
> and "PDF_A-1a.pdf", the SVG pictures both appear to be bitmapped. Apparently, > the  SVG is not preserved.

Thank you for further investigation. I believe the root for the bitmapped PDF graphics is that the imported picture.svg is (more or less) handled as a bitmap, I already saw a bug concerning this problem, but I can't find it. 

The problem might be related to the fact that WRITER handles inserted SVG pictures as .svm; I am pretty sure that we have a report for this, but I can't find it (or at least it has been discussed).

Please note that this "bug" might be related to Bug 41995.

I've just notice this issue in LibO 3.5. In my document, I had already imported SVG graphics while using a version of LibO previous to 3.5, and, when I export them to PDF, they render properly in my PDF viewer. However, when I replaced the SVG graphics I had already imported with different SVG graphics while using LibO 3.5, they export as raster graphics, or at least they appear as such in my PDF viewer since they don't scale properly. I can reproduce this every time, even if I create a new document using LibO 3.5.

<http://wiki.documentfoundation.org/BugReport_Details#Version>

I too can confirm that exporting to PDF renders SVG images as horrible bitmaps in v3.5.

The caveat is any SVG files I imported to the document when using Writer v3.3 and I think 3.4 are preserved as scalable graphics in the PDF.

Any new or updated SVG files that are imported into Writer render as bitmaps.

I tried printing using CutePDF and the same thing occurs, old SVG imports are OK, new ones are bitmaps.  This leads me to think the importing of SVG into 3.5 is different to 3.3 by way of changing the way the SVG handled and represented internally.  Obviously 3.5 can render SVG to PDF just fine (by way of older impoerted files) - just importing does something different to the state of newly imported files.  Maybe a flag is set incorrectly?

(In reply to comment #11)
> I too can confirm that exporting to PDF renders SVG images as horrible bitmaps
> in v3.5.

I have rolled back to v3.4.5 (Build 502) and now all the SVG is exported as nice scalable graphics though there seem to be some minor errors.

All the testing I have done has been on the Windows version.

Confirm that the bug is still there in 3.5.2 RC1.
  SVG images are pixelated when exported in PDF
Need to go back to 3.4.5 for a good quality in PDF.

The bug can easily be fixed by removing the directory:
  C:\Documents and Settings\<USER>\Application Data\LibreOffice

There should be a way to clean it, especially when uninstalling, or installing a new version of LibreOffice.

Problem persists in 3.5.1.2. Solution from Comment 14 does not work for me

Problem persists in 3.5.2 final release.

Regarding the different bitmap resolution seen for PDF/A output versus normal PDF output, perhaps the following sheds some light:

When exporting to PDF/A I get a warning dialog "Problems during PDF export" which reports:
"Some objects were converted to an image in order to remove transparencies, because the target PDF format does not support transparencies. Possibly better results can be achieved if you remove the transparent objects before exporting."

This suggests that the rasterization of the image is performed by a different code path for PDF/A output to cater for the format's prohibition of transparency.

In case it's of some help in identifying the cause of this issue:

On Mac OS 10.7.3, with LibreOffice 3.5.2.2, having deleted the ~/Library/Application Support/LibreOffice directory as suggested in Comment 14, I started a new Writer document and inserted an SVG diagram using Insert->Picture->From File..., then produced PDFs in three ways:

A. Via File->Export as PDF..., with "PDF/A-1a" not ticked

B. Via File->Export as PDF..., with "PDF/A-1a" ticked

C. Via File->Print, and using the "Save as PDF" option in OS X's print dialog

In each case, the SVG diagram ends up as an image. Extracting these using the pdfimages tool reveals that in case A it's actually two separate 96dpi images: one for colour and one for transparency. In cases B and C, it's a single 720dpi image with a white background.

(The rendering and antialiasing of the bitmaps in B and C is identical. The files don't match exactly, though, because the the colour handling is different, and for some reason the case C bitmap is vertically flipped.)

Hence this confirms Luke's findings in Comment 16, and shows that the printing routines use the same process for rasterising SVGs as the PDF/A-1a ones. Obviously it would be preferable if none of these cases did any rasterising.

Crap Crap, I have the exact same problem. And pdf a1 is not an option, as the file is growing too much! Is there anyone who has a quickfix without degrading Libreoffice?

Unfotunately this problem persists in LibreOffice 3.5.3 final release.

This bug keeps me from using LibreOffice 3.5 since my letterhead should have an optimal quality.

What a pity! Hope, this bug is put on the agenda soon.

If you import the picture into draw; you will get a vector graphic. Then just cut/paste that into a writer document and it should stay as a vector.

Fixing this is outside the scope of the 3.5 or 3.6 releases - we plan to merge a better solution for 3.7;

On that basis, this makes no sense as a MAB for 3.5 IMHO.

SVG Import to Draw, copy/paste to Writer, and subsequent export to PDF works well (as expected) in 3.5.3. This workaround is acceptable and makes me look forward to Version 3.7.

The workaround is no good for me as I am creating the ODT separately, and using LibreOffice purely for conversion to PDF.

Until this can be fixed properly, could we increase the DPI at which the SVG is rasterized so that it is suitable for printing?  This can already be achieved by selecting PDF/A output, but that has other side-effects too such as font embedding.  It would be very helpful if all PDF output used a suitable DPI for rasterization of SVG.

*** Bug 50698 has been marked as a duplicate of this bug. ***

Michael Meeks: Since this seems to be a regression introduced in 3.5, isn't there a way to simply restore the behavior from 3.4, waiting for a better fix in 3.7?

Added "regression" keyword according to comment #11, comment #12, comment #13, comment #24.

re-titling; Milan - reverting in 3.5 or 3.6 seems unlikely, 3.7 should fix this comprehensively I think; am working to enable that but it's a longer term task.

de-tag this as a regression - it is arguably such, but it's working as expected.

Confirming that this is still broken in 3.6 final.

(using Linux Deb install on Xubuntu--but I think this bug has already been confirmed to exist on all platforms)

Is this still planned for 3.7? Just so that I know if I can insert SVGs in my documents for future use or not... ;-)

The work-around to a specific type of PDF really does work in the meantime, whether or not it's fixed by 3.7

The work-around to a specific type of PDF really does work in the meantime, whether or not it's fixed by 3.7

Exporting vector graphics to PDF with Writer probably never worked well. I tried it 2 years ago with EPS files in OpenOffice. LibreOffice (Writer, Draw, Impress) handles vector images very well internally and stores them correctly in ODF. But the "Export to PDF" function generates bitmaps - often in high resolution, so that it's not easy to recognize as a bitmap. The only workaround I found at the time was printing the document to a Postscript file and converting that to PDF. Which means: OOo used EPS vector graphics in the printing code (with the "generic postscript" driver, for example), but not in the PDF export code. (Printing the EPS was fairly easy, because it was just embedded in the Postscript; OOo couldn't handle SVG the same way, however.) This workaround won't work any longer as LO has switched to PDF for print job output.

LibreOffice still renders SVG and EPS vector graphics as bitmaps in PDF exports. Apache OpenOffice 3.4.1 has added improved SVG support: SVG is exported as vector graphics now (while EPS graphics are dropped completely).

I am attaching a test kit.

Changed the summary line because the bug report only mentions SVG _export_ (not import).

Created attachment 70492 [details]
Test kit EPS/SVG PDF export with LO and OO

Test kit with Writer, Draw and Impress files containing EPS and SVG vector images, plus various PDF exports by Libreoffice 3.5.4.2, Apache OpenOffice 3.4.1 and OpenOffice.org 3.1.1. Files named "[pdf]export" were created via "Export as PDF" ("lossless" option), files named "psprinter" via printing to file (using generic PS driver) with CUPS.

I converted file vector_writer_ooo_3.1.1_psprinter.ps to PDF (with ghostscript): EPS is in vector format; SVG is rasterized.

Compare the PDF exports of LO 3.5.4.2 and AOO 3.4.1 - OpenOffice now renders SVG as vector image, the difference in quality is easy to see if you increase the zoom factor.

The files were created under Ubuntu 12.04 (Ubuntu 9.10 for OOo 3.1.1).

Omitted EPS from summary. EPS would be a different issue than SVG. The Apache SVG code which will be merged will only solve the correct handling of SVG graphics in PDF output, I think.

The bug title said "import" rather than export because the actual bug seems to happen when importing SVGs, even if the result is only visible when exporting. See comment 7 and comment 11: ODT files created with LO 3.4 still work with 3.6.

EPS are a different problem, AFAIK they are not handled the same way.

Glad to know AOO have improvements to handle SVGs. Could you paste pointers to these changes here? Thanks.

(In reply to comment #34)
> The bug title said "import" rather than export because the actual bug seems
> to happen when importing SVGs, even if the result is only visible when
> exporting. See comment 7 and comment 11: ODT files created with LO 3.4 still
> work with 3.6.

No, SVG was never imported as bitmap, as far as I can see. Versions up to 3.4 converted it to the StarView metafile format (SVM). Newer versions don't convert SVG but include it as-is in the ODF because LO has switched from SVM to SVG. The actual "bug" is just that SVG handling for output is still not very advanced in LO.

The workaround from Comment 20 doesn't work for me even if I use Draw 3.5 to explicitly save the SVG as SVM and import the SVM into Writer. The image is always included in the ODF as SVG and rendered as bitmap in PDF exports - just a very high resolution bitmap if you enable "lossless".

> EPS are a different problem, AFAIK they are not handled the same way.

They have always been converted to bitmaps in exported PDFs. But if you printed the document to a *.ps file, they were embedded as EPS.

> Glad to know AOO have improvements to handle SVGs. Could you paste pointers
> to these changes here? Thanks.

The developers are merging the AOO SVG code into LO (see Comment 20), or already have. The SVG replacement is documented in Apache-Bug 118466 and the Apache dev mailing list. Armin Le Grand, the author of the code, characterized the SVG handling on 2012-10-08 like that: "We already have the good import (which creates an imported graphic containing the SVG) and a medium-quality export." That's why I would like to be able to use EPS until SVG export is mature.

Bug is still there in 3.6.4 RC3

This is really weird.

If I insert the svg image in draw, and export to pdf, the svg appears to remain high quality in the pdf.

If I insert the svg image in write, and export to pdf, the svg becomes crap in the pdf.

Which makes me guess that the pdf export filter does not share the svg export code between writer and draw.

...and, please, before moving to the AOO code to manage the svg, consider that it does not work well at all.

1) When you insert an svg file in draw, if the svg file is complicated, the operation takes ages.  With libreoffice now it is a snap.

To see how this goes, take a BW bitmap (e.g. the logo of a university). Let inkscape trace it to svg. Try to use it. LO can manage it. But current AOO gets horribly slow.

I may be wrong, but I think that this is because LO stores the svg, asks a library to render a bitmap at an adequate resolution, caches it and uses that for display. AOO converts the svg to its internal graphical object format, which slows everything down a lot if the SVG is complicated.

In my opinion what LO does now is right. What AOO does is wrong. Indeed, there should be the 'option' to convert svg to the internal object format for editing, but that should not be done by default.

Most often you do not want to edit the svg. You want it just because it prints well and scales well.

And using vectorized bitmaps so that they can be scaled is a *real* usage case. IMHO it should not be broken.


2) When you insert an svg file in draw, if the svg file must be rendered at a size that is smaller than the original one, with AOO it looks orribly. With current LO it looks fine.

Basically this means that if you want to make presentations, that both display and print fine, LO is currently an option, AOO is not.

If you have a presentation with an svg image, with LO the presentation looks good and exports to PDF fine. With AOO it exports to PDF fine, but it looks horrible in presentation.

Created attachment 70999 [details]
svg file as rendered by AOO

Created attachment 71000 [details]
same svg file as rendered by current LO

By confronting the two snapshots, the difference in quality between AOO and LO in managing svg files is stunning.

Please don't ruin the current excellent svg rendering. The AOO one is really bad (in addition to the fact that any operation on that svg image in AOO is way slowlier than in LO).

(In reply to comment #36, comment #37, comment #38, comment #39)

I really think you are being too harsh towards the new code. It is new and was released very early in AOO because the existing SVG code could not be used under the more permissive Apache license. But consider that Apache is working on a complete rewrite of the drawing layer of the suite (to be released next year) - I'm sure this will be a pretty exciting thing.

Current support for SVG is not at all good in LO. It uses a mature external library to render it, which is why SVG renders fairly well as bitmap now. But LO does not _really_ support SVG as vector. Try to open a non-trivial SVG (like one of the Wikimedia maps) via File/Open. You get an unusable, crippled version in LO Draw, and a correct and editable version in AOO 3.4.1. AOO opens SVG as a set of vector drawing elements and gives you access to them. LO opens the SVG more as a complete whole; you need to use a different program to edit it, Draw won't do. That is why LO is a bit faster on import of SVG, it just renders it en bloc as a bitmap. (I'm saying "a bit" because on my system AOO import does not perform too badly; maybe you shouldn't base your experiments on a vectorized bitmap.)

So I think it is high time to add true SVG support to LO/AOO. SVG is a much too important file format to support it half-heartedly. A vector drawing program that doesn't allow editing a standard vector graphic format is unthinkable in the long run. The current AOO code still has rendering bugs, but it will mature, and until it is mature, EPS could provide an acceptable workaround for complex vector graphics output. (I noticed that export to postscript is still possible under Linux, you can configure it in the printer properties.)

Maybe LO developers will not activate the new code until it renders better. But you shouldn't consider the current behaviour of LO 3.5/3.6 as a classical bug. Conversion of SVG to SVM (the older method) is not a satisfactory solution - it provided vector output, but SVM is an old, proprietary StarDivision file format. And rasterizing SVG (the current method) is not a good solution as well - but it is a transitory step to proper SVG support, and an acceptable one because it allows embedding of real SVG instead of SVM into ODF, which means  future software versions will be able to handle the same files better.

I believe that the new SVG code is planned for the LO 4.0 release, but I'm not sure. If it proves not good enough for you right from the start, stay with LO 3.6 a bit longer or use EPS or high-res bitmaps for a while. It's true, Draw writes SVG as higher resolution bitmaps to PDF than Writer unless you paste it from Draw or choose "PDF/A-1a". But these are usable workarounds - if bitmaps are a usable workaround for you. I wish some of the features I'm really missing were in the LO/AOO pipeline like SVG...

Created attachment 71094 [details]
lo_4.0.0.0alpha_svg_rendering.pdf: SVG test with LO 4.0.0alpha

I have just made some tests with an alpha build of LO 4.0.0. The vector SVG handling code is active in the new release. The code merge must have happened quite early, it seems the current AOO has already some additional fixes in it (at least, I could open the SVG on p. 3 with AOO, and it was "near correct"). The Wikimedia map actually renders quite well, but complex SVGs (with gradients...) still are a problem. I read on the Apache dev mailing list that the new drawing code still needs about half a year of work, so this may be the time frame until proper SVG support is ready, I suppose.

Thanks for the tests. But does that mean regressions will be introduced in 4.0? IMHO it would be better to wait for the new SVG support to be completely ready. The current SVG support has the huge drawback of converting vectors to bitmaps, but at least it renders pictures correctly.

> But does that mean regressions will be introduced in 4.0 ?

In this area we will exchange pixelated SVG in various areas for vector SVG in PDF export - so this bug will be closed. That is the right choice IMHO for a number of code re-use, ease of compiling, licensing, system-compatibility, smaller-download and other reasons: there are a lot of interlocking benefits here of dropping our custom glib.

Improving our SVG rendering is something anyone can jump into working on, and it'd be great to have help improving that.

Thanks for the report.

I'm not discussing the interest of the change: of course, having vectorized SVGs instead of the current situation will be great. I'm just concerned about the timing: if indeed the imported SVGs are currently so different from what we would expect, 4.0 will introduce a regression, while waiting a little longer will ensure when the new code lands, it is at least as good as the previous one in all cases.

But maybe the information you have and I haven't allows you to be confident on the quality of the new SVG code by the time it is released. ;-)

I just tested this in LibreOffice 4.0.0.0 beta1, and the difference is stunning, compare to the over-pixelated bitmaps that 3.6 used to generate. In my documents, pdfs are exported now with perfect image quality.

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.

Let us use bug 68927 to collect current information.