Inkscape fails to completely render to PDF and EPS

[Terry]

I have several SVG files that fail to completely render to PDF and EPS on the printer. When I select save as and choose PDF only part of the image is visible in a PDF reader. It also fails to print completely to a postscript printer. Export to PNG seems to work fine. The file is not very complex and I ran it through the wikipedia SVG checker and it said the file was fine.

Inkscape version: Inkscape 0.91 r13725

Hardware Overview:

  Model Name: iMac
  Model Identifier: iMac8,1
  Processor Name: Intel Core 2 Duo
  Processor Speed: 2.8 GHz
  Number of Processors: 1
  Total Number of Cores: 2
  L2 Cache: 6 MB
  Memory: 4 GB
  Bus Speed: 1.07 GHz
  Boot ROM Version: IM81.00C1.B00
  SMC Version (system): 1.30f1
  Serial Number (system): QP8330KCZE4
  Hardware UUID: 4A8D9D8E-D002-5605-BD19-A27AABE05895

System Software Overview:

  System Version: OS X 10.9.5 (13F1077)
  Kernel Version: Darwin 13.4.0

I also have a Mint Linux machine that exhibits the same issue.

Thanks.

[su_v (suv-lp)]

AFAICT the underlying issue is that cairo >= 1.12.4 omits paths and
shapes with very small (thin) stroke-widths (apparently regardless of
whether or not they also have a fill defined): the figure exports just
ok to PDF after removing all strokes from the paths inside the main
group with id "g4562".

Different output depending on cairo version:
Attached are two PDFs exported with Inkscape 0.91+devel r14224 on OS X
10.7.5 (via CLI, default export settings), one using older cairo 1.12.2
(not affected), one with latest cairo 1.14.2 (affected).

AFAICT whether or not the commercial font 'FrizQuadrata BT Bold Italic'
is installed on the local system does not matter.

See also a related report recently posted on the mailing list:
http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/46275/focus=46276

Proposing to link as duplicate to
* Bug #1174909 “inkscape fails to print thin lines to PDF”
  https://bugs.launchpad.net/inkscape/+bug/1174909

[Terry (terrydoherty)]

Thanks for the information.

I agree the font does not matter.

So the work around is to downgrade Cairo? Are there instructions for how to accomplish that with Inkscape? Or should I just go back to Inkscape 0.48.1 or .2 that still had the old Cairo?

Thanks for the help.

[su_v (suv-lp)]

On 2015-07-03 18:09 (+0200), Terry wrote:
> So the work around is to downgrade Cairo?

As user? No.

It cannot be done with the Inkscape application bundle on OS X anyways; and I would never recommend to an Inkscape user to touch (downgrade) a system library on Linux. The examples I attached earlier had been possible to produce because I have 2 different, completely independent build environments set up which I use for testing local Inkscape trunk builds.

> Or should I just go back to Inkscape 0.48.1 or .2 that still had the
> old Cairo?

Not really either (I would not recommend it - apart from likely encountering earlier bugs from old cairo versions, you also might come across other Inkscape bugs fixed in later releases).

OS X packages:
- Inkscape 0.48.2: bundles cairo 1.10.2 (doesn't run on Yosemite!)
- Inkscape 0.48.5: bundles cairo 1.12.16 (affected)
- Inkscape 0.91 (32bit, 64bit): bundles cairo 1.14.0 (affected)

Windows packages:
- 32bit installer (0.48.5, 0.91): bundles cairo 1.11.2
- 64bit installer (0.91): bundles cairo 1.14.2 (affected)

My recommendation to users experiencing this cairo bug:
Consider changing the structure of problematic drawings (as long as you don't need to produce output files for laser cutters or plotters): strokes can be outlined (converted to path), fills kept as separate paths; some of the strokes are so thin that they make no visual difference at 100% zoom level and can be removed entirely; etc.

[su_v (suv-lp)]

Linking as duplicate to bug #1174909 as proposed in comment 2.

[Terry (terrydoherty)]

Thanks for the information.

I've tried converting the stroke to a path, but then the fill disappears.

I've tried converting the object to a path, but the render problem still exists afterwards.

Part of the issue is the drawing starts out much larger and then is shrunk to fit in the space allowed. This, of course, reduces the stroke size as well. The drawings are printed at 2400 dpi on glossy paper to give a very crisp image and much of the detail is visible.

I don't think I have much choice, but to switch back to 48.1. I don't want to spend time redrawing a bunch of images.

Any information on when the bug will be fixed. It seems its been around a long, long time.

[su_v (suv-lp)]

On 2015-07-03 21:08 (+0200), Terry wrote:
> I've tried converting the stroke to a path, but then the fill > disappears.

Duplicate the path first - remove the stroke from the original, convert the stroke of the duplicate to path: thus you will have the original filled area, and on top of that the outlined stroke. You could also test other variations:
- Convert stroke to path, break apart, assign stroke color to the bottom path, fill color to the inner path stacked on top.
- Convert stroke to path, break apart, duplicate inner path, select just duplicated path and the outer outline, apply 'Path > Difference'. Fill the outer path with former stroke color, the inner one with the original fill color.

Such details about usage though are beyond the scope of the bug tracker. The reported issue is known - an upstream bug in the cairo graphics library, reported for Inkscape as well as in cairo's own bug tracker.

> Part of the issue is the drawing starts out much larger and then is
> shrunk to fit in the space allowed. This, of course, reduces the stroke
> size as well. The drawings are printed at 2400 dpi on glossy paper to
> give a very crisp image and much of the detail is visible.

I do wonder though why - if the output is intended for a much higher resolution - why the vector drawing is first scaled down from a huge size (roughly 550 x 650 inches!) to a miniscule size (0.5x0.5 inches aka 45x45 px (SVG user units)) and exported to PDF at this size … AFAIU there would be no issue with too small stroke widths in Inkscape's cairo-based PDF and PostScript exports if the original drawing had not been downscaled to and exported at such a tiny size.

> Any information on when the bug will be fixed. It seems its been around
> a long, long time.

When and how this will be addressed in a future cairo release is outside of Inkscape's own sources, and not something to be determined by the Inkscape project itself. Cairo is an independent software project, and Inkscape is merely a client of cairo (for rendering on-canvas and e.g. for export formats like PDF and PostScript).

[Terry (terrydoherty)]

Thanks a lot for all your assistance. I will figure something out.