Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#3295 closed bug (fixed)

SVG images rasterized when printing/exporting

Reported by: Alister Owned by: mhugent
Priority: major: does not work as expected Milestone: Version 1.7.0
Component: Printing Version: Trunk
Keywords: Cc:
Must Fix for Release: No Platform: Windows
Platform Version: 7 64bit, XP 32bit Awaiting user input: no

Description

SVG images added to a layout in the print composer are rasterised when printing or exporting to SVG. Surely this should not be?

Attachments (2)

composer_pixelisation.jpg (117.4 KB ) - added by JD 13 years ago.
patch_for_bug_3295.txt (83.0 KB ) - added by JD 13 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 by wildintellect, 13 years ago

I can confirm this on OSGeo4w 1.5 install, Windows7. Also effects PDF export.

QGIS 1.5+ install on Ubuntu does not have this issue, at least not with the pdf output, I need to double check the svg export.

comment:2 by JD, 13 years ago

This also happens on rev 14936, Kubuntu 10.04, Qt 4.6.2

It appears to happen in the composer rather than the export per se. The attached screenshot shows a highly zoomed area with an arrow drawn with the arrow tool on the left, and the north arrow SVG: north-arrow_1_simple_half_arrow.svg on the right. The north arrow SVG is definitely a purely vector image, but the SVG exported from composer contains a base64 encoded PNG.

by JD, 13 years ago

Attachment: composer_pixelisation.jpg added

comment:3 by JD, 13 years ago

Attaching a patch to fix this bug/feature.

The QgsComposerPicture was rendering the SVG into a QImage cache and then drawing that image. As QgsComposerPicture is a scene item, it meant that it was never treated as a vector by Qt.

QgsComposerPicture now has a QSvgRenderer member variable as well as the QImage that is used for bitmaps. It now performs no caching of the SVG, instead relying on Qt to draw it in the most efficient way. Indeed, the refresh rate for a native SVG _seems_ much quicker than the cached QImage version, but no timing tests have been done.

As a knock-on effect PDF and SVG export now treat SVGs as vectors rather than rasters.

An arguably more efficient approach would be to use a QPicture to render either a vector or a raster into. This has the advantage that the only time a distinction is made between the two is on loading, thereby simplifying the code and removing a redundant member variable.

-JD

by JD, 13 years ago

Attachment: patch_for_bug_3295.txt added

comment:4 by lutra, 13 years ago

Owner: changed from nobody to mhugent
Type: bugpatch

comment:5 by mhugent, 13 years ago

Resolution: fixed
Status: newclosed

Applied in r14972. Thanks!

Marco

comment:6 by wildintellect, 13 years ago

Platform Version: 7 64bit
Priority: minor: annoyancemajor: does not work as expected

This does not appear to be fixed on Windows7 (64bit), QGIS 1.5,1.6 and Trunk r15130 and effectively ruins any chance of cartographic workflow involving Inkscape. Ubuntu 10.04 does not appear have the bug using 1.6 ubuntugis repo.

Export of PDF results in groups of Images, pixelation if you look at sample (uploading now). SVG export appears to be lines but is pretty much unusable in Inkscape, there are lots of random lines streaking across.

I'm not saying the patch didn't fix the rendering in the composer, that may be true.

comment:7 by wildintellect, 13 years ago

Resolution: fixed
Status: closedreopened

comment:8 by Alister, 13 years ago

Platform Version: 7 64bit7 64bit, XP 32bit
Type: patchbug

Export of PDF results in groups of Images, pixelation if you look at sample (uploading now)

I can confirm that, although it is different to the original bug. With current trunk on Windows XP an svg is not rasterised in the composer or when exported to svg or printed (whether to a real printer or a virtual PDF printer) but is rasterised when exported to PDF.

SVG export appears to be lines but is pretty much unusable in Inkscape, there are lots of random lines streaking across.

I can't confirm this (it is OK on XP) and I think you should file a separate bug for it.

comment:9 by Alister, 13 years ago

Also see #3480 and #3250, although I think they are all different bugs.

comment:10 by wildintellect, 13 years ago

On further testing SVG export appears to be working but pdf does not as noted in #3250

I have not been able to repeat the line streak issue and will open a separate (I think there is one already) about clipping shapes to the output box.

We can probably close this ticket.

comment:11 by Alister, 13 years ago

Resolution: fixed
Status: reopenedclosed

yes:

SVG export works now Printing works now (but subject to conditions described in comments in #3295) Printing of vector map layers (rather than SVG images, as described in original bug report) works now (but subject to conditions described in comments in #3295)

comment:12 by Alister, 13 years ago

Sorry, lets get those on separate lines:

SVG export works now

Printing works now (but subject to conditions described in comments in #3295)

Printing of vector map layers (rather than SVG images, as described in original bug report) works now (but subject to conditions described in comments in #3295)

comment:13 by Alister, 13 years ago

Sorry again - not #3295 - #3250.

SVG export works now

Printing works now (but subject to conditions described in comments in #3250)

Printing of vector map layers (rather than SVG images, as described in original bug report) works now (but subject to conditions described in comments in #3250)

Note: See TracTickets for help on using tickets.