Save as EPS or PS incomplete with cairo >= 1.10 and < 1.12

[Sameer Grover]

When saving some svg files in ps or eps formats, the text in the figure doesn't appear in the saved files. I've tried all options like converting text to path. (See sample file)

I'm using 64bit ubuntu 11.04. I've tried both the repository versions (0.48) and hand compiling the latest release (0.48.1) This conversion works fine on Windows.

To reproduce:
1. open test.svg in inkscape
2. File -> Save as: choose eps in the file format
3. Open saved file and notice that there is no text in the eps file.

[Sameer Grover (sameer-grover-1)]

This may be an ubuntu specific bug. I've not encountered this problem on debian with inkscape v0.47

[su_v (suv-lp)]

Not directly related to the platform, but to the cairo version used:

Not reproduced with Inkscape 0.48.1 and 0.48+devel r10325 built with and using cairo 1.8.10
Reproduced with Inkscape 0.48.1, 0.48+devel r10237, r10325 and r10481 builit with cairo 1.10.2
Rperoduced with Inkscape 0.48+devel r10483 built and using cairo 1.11.2
(all tested on Mac OS X 10.4.8 (i386))

Most likely related to or a duplicate of
Bug #645256 in Inkscape: “Incomplete picture when saving in eps”
<https://bugs.launchpad.net/inkscape/+bug/645256>

Missing objects in this example file are clones (<use>) of paths stored in individual <defs> sections (there are no real text objects in the file exported from matplotlib), e.g. the centered 'x' label of the horizontal axis:

<g id="text7">
<defs>
<path id="c_801fe2e877fad46da27c898b407b3b54" d="M54.890625 -54.687500l-19.781250 26.609375l20.796875 28.078125l-10.593750 0.000000l-15.921875 -21.484375l-15.906250 21.484375l-10.609375 0.000000l21.250000 -28.609375l-19.437500 -26.078125l10.593750 0.000000l14.500000 19.484375l14.500000 -19.484375z"/>
</defs>
<g style="fill: #000000; opacity: 1.000000" transform="translate(292.020312,285.280625)scale(0.120000)">
<use xlink:href="#c_801fe2e877fad46da27c898b407b3b54"/>
</g>
</g>
</g>

[su_v (suv-lp)]

Typo:
- (all tested on Mac OS X 10.4.8 (i386))
+ (all tested on Mac OS X 10.5.8 (i386))

[su_v (suv-lp)]

> This conversion works fine on Windows.

Note that the Windows builds (stable 0.48.1) ship with cairo 1.8.8 (thus are not affected by what appears a regression in newer cairo versions).

[Adrian Johnson (ajohnson-redneon)]

I ran a cairo trace on the inkscape using the test.svg test case. The command line was:

cairo-trace inkscape -E test.eps test.svg

I've attached the output. Looking at the trace, inkscape does not output any text. If inkscape were outputting text I would expect to see "show-text" or "show-glyphs" in the trace. Then is no mention of any fonts in the output either. There should be a "set-font-face" or similar font related call in the output when text functions are used.

So the problem appears to be in inkscape.

[su_v (suv-lp)]

Adrian Johnson wrote
> Looking at the trace, inkscape does not output any text.

Inkscape does not output text because there is no actual text to output in the SVG file (matplotlib apparently outlines text when generating SVG output). Please see the SVG code snippet in my earlier comment [1]: the missing objects are clones (<use>) of regular SVG paths (<paths>), not text objects (<text>).

[1] <https://bugs.launchpad.net/inkscape/+bug/813886/comments/3>

[Alvin Penner (apenner)]

just confirmed that this bug exists on Windows XP, bzr rev 10562, Cairo 1.11.2.

OT - can anyone explain to me how come this affects ps output and yet the pdf export is correct. I always thought the two were essentially the same.

[su_v (suv-lp)]

AFAICT the missing labels of the axes (outlined text) appear to get wrongly clipped by the clip-path defined inside the group with the plotted function curve, also referenced as clip-path e.g. for the dashed grid-lines:

<g id="line2d1">
<defs>
  <clipPath id="pd418c698b57440e61e82ddaeb541b327">
<rect x="72.000000" y="171.360000" width="446.400000" height="89.280000"/>
  </clipPath>
</defs><path style="fill: none; stroke: #0000ff; stroke-width: 1.000000; stroke-linejoin: round; stroke-linecap: square; opacity: 1.000000" clip-path="url(#pd418c698b57440e61e82ddaeb541b327)" d="M72.000000 216.000000L76.464000 211.543436L80.928000 207.131401 (…) />
</g>

Tested modification:
a) After changing the size of the rectangular clip-path 'pd418c698b57440e61e82ddaeb541b327' to the page size (W = 720, H = 540, X = 0, Y = 0) the file exports to EPS correctly (no missing parts) - see attached SVG file, externally modified with a plain-text editor.
b) Alternatively, 'Ctrl+click' on one of the labels for the axes in Inkscape, move it with the arrow keys inside the diagram area and save a copy as EPS: as soon as the object is within that area defined by the clip-path, it is visible in the EPS file.

[su_v (suv-lp)]

The previous modifications didn't match the page size as described (neglected viewbox attribute, switched width/height values) but increased the size of the clipped area sufficiently to include all outlined text labels for the axes.

Attaching the corrected version (W = 576, H = 432, X = 0, Y = 0) now.

[Adrian Johnson (ajohnson-redneon)]

Yes it does look like a clipping problem with groups. Are you able simplify the test case? The PDF and PS output is still too large for me to manually verify each operation.

[su_v (suv-lp)]

Does this one help?

Reduced test case:
- the blue rectangle is missing in the EPS file,
- the red rectangle is partially visible (inside the rectangular area of the clip-path (applied to the vertical line))

[Adrian Johnson (ajohnson-redneon)]

Yes the new test case helps. I'll try to figure out why it is failing with 1.10.2.

The original test case fails with git master while the reduced test case works. So unfortunately it doesn't help me fix the problem in git master. As 1.12 is due out soon I'd like to get this fixed in git master as well.

[Adrian Johnson (ajohnson-redneon)]

I've pushed a fix to cairo git master. Here is a patch for 1.10.2.

[su_v (suv-lp)]

I can confirm that with cairo-git (master) [1] cloned today, the original file 'test.svg' as well as the reduced test case save correctly to EPS.
(Tested with Inkscape 0.48.2 and 0.48+devel r10649 on Mac OS X 10.5.8 (i386))

[1] cairo-git installed and used with Inkscape following Adrian's instructions in
<https://bugs.launchpad.net/inkscape/+bug/375323/comments/47>

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "fix clipping in groups" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[su_v (suv-lp)]

Adrian Johnson wrote on 2011-08-29:
> I've pushed a fix to cairo git master. Here is a patch for 1.10.2.

Fixed confirmed with patch applied to cairo 1.10.2 (Mac OS X 10.5.8 (i386), Inkscape 0.48.2).

[su_v (suv-lp)]

Keeping report open for Inkscape until new cairo version/update is released and available on the supported platforms (including Inkscape packages for win32 & osx).

[M8R-98booy (m8r-98booy)]

This bug is still present in Inkscape 0.48.3.1 r9886.

[su_v (suv-lp)]

> This bug is still present in Inkscape 0.48.3.1 r9886.

As explained in duplicate Bug #967902, it is not a bug in Inkscape itself - it depends on which version of cairo Inkscape uses.
The installer of Inkscape 0.48.3.1 for Windows was created _before _ the release of cairo 1.12.0 (it ships with cairo 1.11.2, which also exposes this bug).

[jazzynico (jazzynico)]

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

[rickmastfan67 (rickmastfan67)]

Just had this bug bite me. Was really confused as to what was happening when my some of my EPS files where missing several items, yet a PDF export of the same SVG file had all the items. Good thing I found this before I reported another duplicate.

Still, this bug is really messing me up as I needed to export an EPS file of the SVG file I'm working on right now. Luckily, I had a copy of the 7z archive of inkscape-0.48.1-2 on my HD, exported that to my desktop and started up that old version and was able to get my EPS that I needed right away and then go back to 0.48.4 for other stuff. :)

Hopefully, the newer version of Cairo can make an appearance in 0.48.5 for Windows if that does get released before 0.49.

[jazzynico (jazzynico)]

Fixed for win32, devlibs revision 46.

@rickmastfan67 - Since the 0.48.x branch and 0.49 share the same devlibs, the new Cairo version will be available in 0.48.5.

[jazzynico (jazzynico)]

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

[Ian Ellis (ianmailstuff)]

Ungroup all objects. That workaround works for me. I posted it on the forums as well.

I hope that helps somebody. Enjoy the holidays everybody!

[Dong Siwei (dswayb)]

I am going mad!!!!!! I have done everything as in 15 but still this is no test in exported eps file. I am using Ubuntu 12.04, what is the fuck problem it is????????????

[Dong Siwei (dswayb)]

ungroup all the objects does not work at all

[sam tygier (samtygier)]

Current ubuntu 15.04 has cairo 1.12.2-3, and I can't reproduce, so closing the ubuntu part.

[jazzynico (jazzynico)]

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

[Bryce Harrington (bryce)]

As per comment #18, this was a bug in Cairo that has long since been fixed. The inkscape task was open only to track until the fix was released. Since it now is, going ahead and closing this as resolved.

Closed-by: https://gitlab.com/bryceharrington