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

Bug #759154 reported by Jose Enrique on 2011-04-12
This bug affects 33 people
Affects Status Importance Assigned to Milestone
Inkscape Devlibs
inkscape (Debian)
Fix Released

Bug Description

System: MacOS 10.5.8 (PowerBook G4)
X11 version 2.5.0 (but problem observed also when running X11 v. 2.6.1)
Inkscape versions 0.48 and 0.48+devel. Bug NOT observed previously with v. 0.47.

Description of problem: dendrogram "leaves" display fine on screen but extra lines appear on printouts, and also on file conversions to .pdf opened with Acrobat Reader or Preview. Older files created with Inskacape 0.47 are also affected when opened with v. 0.48+. Bitmap exports are not affected (see below). The dendrograms were created as pdf files with R, and imported into Inkscape.

Attached: .zip archive of directory with the files below:
1 Sample-dendrogram.svg. Initial Inkscape .svg file with imported dendrogram.
2. Correct-dendrogram.png : correct apperance in this bitmap export of the above file.
3. Incorrect-dendrogram.tiff : screenshot of .pdf conversion file generated with Inkscape v. 0.48+ and opened with Preview. Please notice the incorrect dendrogram "leaves".
4. Dendro_mitosis41.pdf. The original dendrogram file imported into Inkscape.

Jose Enrique (jmejia) wrote :
su_v (suv-lp) on 2011-04-17
tags: added: cairo exporting pdf
su_v (suv-lp) wrote :

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:

Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed
su_v (suv-lp) wrote :

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.

Jose Enrique (jmejia) wrote :

Thanks a lot for looking into this, ~suv.

su_v (suv-lp) wrote :

Reduced testcase

su_v (suv-lp) wrote :

cairo 1.8.10 / Inkscape r10179

su_v (suv-lp) wrote :

cairo 1.10.2 / Inkscape r10179

su_v (suv-lp) wrote :

cairo 1.11.2 / Inkscape r10179

Andrzej (ndrwrdck) wrote :

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)

su_v (suv-lp) wrote :

> 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).

Andrzej (ndrwrdck) wrote :

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

Bug 39551 - An open path becomes closed if endpoints are aligned vertically

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.

Andrzej (ndrwrdck) wrote :

Could someone with sufficient skills try to build Cairo with a patch mentioned in: ?

su_v (suv-lp) wrote :

> try to build Cairo with a patch mentioned in:
> ?

Forwarded to the 'inkscape-devel' mailing list:

su_v (suv-lp) wrote :

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

summary: - Incorrect printing/pdf conversion
+ Open paths with aligned endpoints are closed in cairo-based exports
su_v (suv-lp) wrote :

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] <>

LucaDC (dicappello) wrote :

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?

LucaDC (dicappello) wrote :

The PDF I get.

su_v (suv-lp) wrote :

> Does this only need a Cairo update for Windows?


su_v (suv-lp) wrote :

PDF export with Inkscape 0.48+devel r11132 and cairo 1.12.0

su_v (suv-lp) wrote :

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:

Changed in inkscape:
status: Confirmed → Triaged
Changed in inkscape (Debian):
status: Unknown → Confirmed
tags: added: easy-fix
Gwyn Ciesla (limburgher) wrote :

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

JohnLM (johnlm) wrote :

Yup, updating cairo fixes the problem.

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

jazzynico (jazzynico) wrote :

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

Changed in inkscape-devlibs:
assignee: nobody → JazzyNico (jazzynico)
importance: Undecided → Medium
status: New → In Progress

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).

tags: removed: easy-fix
jazzynico (jazzynico) wrote :

Fixed for win32, devlibs revision 46.

Changed in inkscape-devlibs:
status: In Progress → Fix Released
thabes (thabescity) wrote :

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.


jazzynico (jazzynico) wrote :

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

Changed in inkscape-devlibs:
assignee: JazzyNico (jazzynico) → nobody
status: Fix Released → Triaged
John Bradley (flypie) wrote :

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

David Hetherington (djhreg) wrote :

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:

     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.


David Hetherington

Can this be fixed for Ubuntu 12.04?

jazzynico (jazzynico) wrote :

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).

jazzynico (jazzynico) wrote :

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

Changed in inkscape-devlibs:
assignee: nobody → jazzynico (jazzynico)
status: Triaged → Fix Released
Changed in inkscape:
assignee: nobody → jazzynico (jazzynico)
milestone: none → 0.91.1
status: Triaged → Fix Committed
status: Fix Committed → Triaged
assignee: jazzynico (jazzynico) → nobody
milestone: 0.91.1 → none
pRototype (regeir) wrote :


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.

Gwyn Ciesla (limburgher) wrote :

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

jazzynico (jazzynico) on 2016-11-08
Changed in inkscape:
milestone: none → 0.92
status: Triaged → Fix Committed

I tested with my sample "schematic.svg" from bug #1580042
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.

Bryce Harrington (bryce) on 2017-01-10
Changed in inkscape:
status: Fix Committed → Fix Released
Changed in inkscape (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.