Bug report #7671

SVG symbols not correctly exported to svg and pdf via print composer

Added by Andrea Ghensi over 11 years ago. Updated about 7 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Map Composer/Printing
Affected QGIS version:master Regression?:No
Operating System:Mac OS X Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:16588

Description

I'm using svg symbols taken from https://github.com/mapbox/maki in my maps.
When I try to export layers from print composer to svg (or pdf) for further editing in Inkscape, the icons are messed up.
Printing to pdf (osx preview) preserves the correct style.
Print composer also displays icons in the right way.
Attached are one of the SVG symbols I used, the svg and pdf export of print composer and the "printed" pdf

symbol.svg - original symbol (2.39 KB) Andrea Ghensi, 2013-04-22 01:59 AM

exported.svg - svg export (9.48 KB) Andrea Ghensi, 2013-04-22 01:59 AM

exported.pdf - exported pdf (2.62 KB) Andrea Ghensi, 2013-04-22 01:59 AM

printed.pdf - printed pdf (9.73 KB) Andrea Ghensi, 2013-04-22 01:59 AM

fabbrica.svg - cleaned svg icon (573 Bytes) Andrea Ghensi, 2013-04-27 06:42 AM

exported.svg - exported svg (14.8 KB) Andrea Ghensi, 2013-04-27 06:42 AM

Schermata_2013-05-27_a_11.25.50.png (1010 KB) Andrea Ghensi, 2013-05-27 03:22 AM

analysis.png (8.44 KB) Daan Goedkoop, 2016-03-11 03:02 AM

History

#1 Updated by Andrea Ghensi over 11 years ago

I forgot, Qgis 1.8 from kyngchaos...

#2 Updated by Larry Shaffer over 11 years ago

Hi Andrea,

Please test this with the nightly build of pre-2.0 available here

When running that version, all of your settings and plugins will be 'missing' or reset as it uses a new settings and plugins directory structure. This should not affect your 1.8 setup. Of note, however, is that your version of the Kyngchaos frameworks may be outdated for use by the nightly, so just launch the nightly to find out. The Snow Leopard nightly does not yet use the very latest frameworks, so it should not hurt anything by upgrading your frameworks.

#3 Updated by Andrea Ghensi over 11 years ago

just tried, nothing changed.
the output is the same as I posted before.

#4 Updated by Andrea Ghensi over 11 years ago

I tried to clean up the icons with http://launchpad.net/svg-cleaner
now the rectangular border doesn't show up (because is not there anymore).
I found that the source svg have 2 objects/paths, but the icon on the exported svg is composed of 4 groups, one of wich is the undesired black border.
You can see it in the attachments using inkscape xml editor.
It happens in both 1.8.0 and 1.9.0 (QGIS_2.0-dev_SnoLeo 1.9.0-Master (6d046fc))

#5 Updated by Andrea Ghensi over 11 years ago

Now I'm using 1.9.0 93faa76, still the same.
In the attached image there's an exported pdf on the left and the composer window on the right. The pdf exporter adds borders.
If I print to PDF file, the hillshade raster results very grainy (low dpi?)
I also tried to add an inkscape svg into the composer to overlay some arrows and schemes (in order to avoid svg or pdf export), but composer doesn't display line/arrow heads.
I'm a bit in a hurry, so for now I'm going to try TileMill, but I really would like to see this bug resolved soon!

#6 Updated by Jürgen Fischer over 10 years ago

  • Category changed from 33 to Map Composer/Printing

#7 Updated by Jonathan Gutschi over 10 years ago

Hi guys,

I'm experiencing the same issue on Ubuntu 14.04 LTS using QGIS 2.0.1.

Confirming that running the Mapbox Maki icons through SVG-Cleaner as suggested by Andrea does fix the problem as a workaround.

Exporting through the system print dialog does however not work on Ubuntu. The icons are still drawn with a rectangle border in the same way as when using the export to PDF or SVG option.

Was any progress made so far in figuring out why the icons are rendered correctly on screen and in the preview but not when exporting?

@Andrea: Thanks for reporting this, certainly saved me a lot of time!

#8 Updated by Daan Goedkoop almost 9 years ago

Still a problem in version 2.14.

Apparently, when an svg image is exported, through the print composer, to pdf or svg, not only the border and the filling is rendered, but also another border, using the fill color (or with neither pen nor fill style set if the object has no fill). The width of this second border, and therefore the impact of this bug, seems to be dependent on the coordinates in the source svg. With an svg with coordinates in the range 0-1000 the width of the wrongly added second border is very small; with an svg with coordinates in the range 0.00-1.00 this border gets huge.

The attachment shows a dissection of the export of two svg files. They had the same contents, just different orders of magnitude for the coordinates. For each file the left column shows the border (as intended), the middle column the fill (as intended) and the right column the wrongly created second border.

#9 Updated by Giovanni Manghi over 7 years ago

  • Regression? set to No
  • Easy fix? set to No

#10 Updated by Nyall Dawson about 7 years ago

  • Status changed from Open to Closed
  • Description updated (diff)
  • Resolution set to fixed/implemented

Fixed in the qt5 based builds

Also available in: Atom PDF