Open paths with aligned endpoints are closed in cairo-based exports (PDF/PS/EPS)

Reproduced with Inkscape 0.48.1 and 0.48+devel r10179 on OS X 10.5.8 i386 (both cairo 1.10.2)
Not reproduced with Inkscape 0.47 (cairo 1.8.8), 0.48.0 (cairo 1.8.10) and 0.48+devel r10166 (cairo 1.8.10)

As far as I can tell, the vertical edges of open rectangles get closed only if Inkscape uses cairo ≥ 1.10 (upstream bug in cairo?).

See also a related thread in 'inkscape-user' describing IMHO the same problem:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.user/13632>

Reproducible with librsvg (confirming upstream cairo bug, outside of Inkscape):
- librsvg 2.26.2 & cairo 1.8.10 converts to PDF ok
- librsvg 2.32.1 & cairo 1.10.2 converts to PDF with same error

Command used with rsvg:
$ rsvg-convert -o Sample-dendrogram.pdf -f pdf Sample-dendrogram.svg

Both versions of librsvg render the SVG file on-screen like Inkscape does on-canvas (rsvg-view Sample-dendrogram.svg). The one linked to the newer version of cairo produces the same errors when converting to PDF as Inkscape.

Thanks a lot for looking into this, ~suv.

Reduced testcase

cairo 1.8.10 / Inkscape r10179

cairo 1.10.2 / Inkscape r10179

cairo 1.11.2 / Inkscape r10179

Was this issue reported upstream? If so, can someone share a link to the Cairo bug report please.

Is there any method of working around this issue in Inkscape? On the user side I'm simply making sure the endpoints are not vertically aligned or the last segment of the path is not horizontal.

Maybe Inkscape could shorten the last segment by a tiny amount if broken version of Cairo is detected? (yes, that's ugly but giving someone a pdf with overlooked rendering error like this is ugly too)

> Was this issue reported upstream?

I had searched the bug tracker of cairo before - without success (I'm not familiar with coding in C++ myself, nor with the cairo internals called by Inkscape's export routines, and possibly didn't use matching keywords for my searches).

> If so, can someone share a link to the Cairo bug report please.

If known to the bug team, it would have been added as upstream link to this report already.

> Is there any method of working around this issue in Inkscape?

The only thing that comes to mind is creating a slight imprecision for the coordinates of the end nodes so that they don't share the same x- or y- coordinate.

> Maybe Inkscape could shorten the last segment by
> a tiny amount if broken version of Cairo is detected?

It seems that none of the developers was affected by this problem yet - consider asking on the developers' mailing list about ideas for workarounds for cairo 1.10/1.11 (whether Inkscape should implement hard-coded workarounds, or lend a hand to report and fix the upstream issue).

I also couldn't find any report so I've added one:

Bug 39551 - An open path becomes closed if endpoints are aligned vertically
https://bugs.freedesktop.org/show_bug.cgi?id=39551

Unless this bug can be fixed in a Cairo 1.10.x series (preferably 1.10.3) I'd like to have a workaround for it in Inkscape. Actually, it would be good to have such workaround regardless of the progress in this bug - there will be plenty of affected Cairo libraries in the field, which means many Inkscape users who can't upgrade system libs will have broken pdf export for years to come.

Could someone with sufficient skills try to build Cairo with a patch mentioned in: https://bugs.freedesktop.org/show_bug.cgi?id=39551 ?

> try to build Cairo with a patch mentioned in:
> https://bugs.freedesktop.org/show_bug.cgi?id=39551 ?

Forwarded to the 'inkscape-devel' mailing list:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/37008>

Fix in upstream cairo-git (master) confirmed with
Inkscape 0.48.2 and 0.48+devel r10649 on Mac OS X 10.5.8 (i386)

[1] cairo-git (master) cloned today, installed and used with Inkscape following the instructions in
<https://bugs.launchpad.net/inkscape/+bug/375323/comments/47>

Upstream fix also confirmed with cairo 1.10.2 + patch from [1],
Inkscape 0.48.2 and 0.48+devel r10869 on OS X 10.7.2 Lion

[1] <http://cgit.freedesktop.org/cairo/commit/?h=1.10&id=36e0cad71aa7b9a84fb31fba333175cbf445ab4e>

I see this problem in still present in trunk (I'm on Windows XP).
The two squares in the attached file are rendered differently into a PDF because the top one has the upper left corner slightly offset to the right (the wrong one is the lower, rendered closed while it's not).
Does this only need a Cairo update for Windows?

The PDF I get.

> Does this only need a Cairo update for Windows?

Yes.

PDF export with Inkscape 0.48+devel r11132 and cairo 1.12.0

Setting bug status to 'Triaged' - can be closed as 'Invalid' for Inkscape once Inkscape provides official packages for Windows and OS X with cairo 1.12 and current linux distros have upgraded as well.

(Note: cairo 1.12 was released only a few days ago:
<http://cairographics.org/news/cairo-1.12.0/>)

I still see this on inkscape 0.48.2, cairo 1.10.2, on Fedora 17.

https://bugzilla.redhat.com/show_bug.cgi?id=846613

Yup, updating cairo fixes the problem.

Can confirm
Bug present: inkscape 0.48.3.1, cairo 1.10.2, on Gentoo Linux
Bug *not* present: inkscape 0.48.3.1, cairo 1.12.2, on Gentoo Linux

Reproduced on Windows XP, Inkscape 0.48.3.1 and trunk revision 11859 (cairo 1.11.2).
Not reproduced with 11871 and cairo 1.12.8 (local test).

I attach a files with minimal working examples. Thats contains figure created with beazier curves (wrong exported to pdf), almost that same figure created with chopping two squares (good) and three straight line (good).

Fixed for win32, devlibs revision 46.

JazzyNico (jazzynico) wrote on 2013-04-12: #25

Fixed for win32, devlibs revision 46.
Changed in inkscape-devlibs:
status: In Progress → Fix Released

Dear JazzNico how did you fixed for windows? could you elaborated the way?

Because I have a trouble to save as .pdf and .eps. I have a poster presentation two weeks later I plot some figure with the inscape but I cannot get output.

1) I load textext extension for some equations.
2) I have some figures below the equations and thats all but I cannot get output.

I have read the forum but there is only clear solution for ubuntu not for windows 7,8

Any help appreciated.

best

Due to regressions (including noticeable slowness), I'm reverting cairo to the previous version (1.11.2).

Another example of this. I did cure it by moving 1 end of a line.

My other bug report was closed as a duplicate of this one (which I did not find even though I did search) At any rate, yes, mine looks exactly like this and today I downloaded the latest version (Inkscape 0.48.5 r10040) and confirmed that the bug is still there. I also have an extremely simple SVG available that reproduces the problem. Basically, it is just the single statement:

  <path
     d="m 180,245 -136,0 0,-200 136,0"
     style="font-size:11px;fill:none;stroke:#424242;stroke-linecap:butt;stroke-linejoin:round" />

Basically, this should:

1) Start at 180,245
2) Go left 136 units
3) Go down 200 units
4) Go right 136 units

and NOT close because there is no "z" command on the path.

Displays fine in Inkscape. Displays fine in Internet Explorer, but renders incorrectly as a PDF.

See attached ZIP file with both the SVG and the resulting PDF.

Thanks,

David Hetherington

Can this be fixed for Ubuntu 12.04?

cousteau> Can this be fixed for Ubuntu 12.04?

Unfortunately no. 12.04 uses libcairo2-1.10.2, and the bug is fixed in the 1.12 branch.
But upgrading Ubuntu to 14.04 should fix the issue (it uses libcairo2-1.13.0).

Cairo (1.14.6) and Pixman (0.34.0) updated in the official win32 devlibs rev. 61.

Hi.

Seems to be fixed in Inkscape 0.92pre2 15127 (32 bit Windows version).

But I have only tried with one sample file (not completely clean). This is the result:

Inkscape 0.91 r13725 - Exported PDF file contains closed path (fail).
Inkscape 0.92pre2 15127 - Exported PDF file appear correctly with open path - success.

Also I have to admit (bad, yes I know) using an old XP computer, so I haven't tested on Windows 7 yet.

Confirmed, this is fixed on 0.92pre2 on Fedora as well.

I tested with my sample "schematic.svg" from bug #1580042
<https://bugs.launchpad.net/inkscape/+bug/1580042/+attachment/4659639/+files/schematic.svg>
The PDF result does not show mangled line between D1 and D2 anymore
(the bug seems to be fixed).

PDF export settings used:
- Restrict to PDF version: PDF 1.4
- Text output options: Embed fonts
- Rasterize filter effects: Yes
- Resolution for rasterization (dpi): 96
- Output page size: Use document's page size
- Bleed/margin (mm): 0.0
- Limit export to the object with ID:

Result is in the attached file `1580042schematic.inkscape0.92pre2.pdf`.
A run on Windows XP SP3 and Windows 7 produces binary-identical PDF file.

Side note: This version of Inkscape got a problem of ridiculous text line
spacing at the bottom of diagram instead (0.91 worked fine in this aspect).
I'll try to see if I could report this as a different bug.

Inkscape: 0.92pre2 r15127 (binary 7-Zip release)
System: Microsoft Windows XP SP3
System: Microsoft Windows 7 Professional 32-bit

The line spacing issue mentioned in comment #35 is now reported separately
as bug #1642133. Latest development version 0.92pre3 r15195 is also affected.