In imported PDF, some objects not rendered / partially rendered

[Scott Norris]

Inkscape 0.47
Ubuntu 10.04

As Free Software becomes increasingly popular among academics in the sciences, an increasingly common workflow is to render plots using matplotlib, then clean them up using Inkscape. Most of the time it works very well. But sometimes the .pdf files produced by matplotlib do not render correctly in Inkscape.

In the attached file, the data are initially not visible when I open Inkscape. If I zoom in and out using 'CTL+mouse wheel', a horizontal strip of the data about 1" tall on my monitor becomes visible. Interestingly, no matter how far in or out I zoom, only 1" is ever visible on-screen -- zooming out reveals more of the data, while zooming in hides more. If I try to export the image to .eps, the data are not visible at all in the resulting file.

[su_v (suv-lp)]

> If I try to export the image to .eps, the data are not visible at all in the resulting file.

The issue with incomplete or empty exports is possibly similar to bug #534679 “Cairo-based export not exporting all elements”: "corrupt" data (e.g. objects with "impossible" geometry/path data/transforms) can cause the rendering to be stopped ("rendering up to, but not including, the first element which has an error") in cairo-based exports.

> sometimes the .pdf files produced by matplotlib do not render correctly in Inkscape
Importing the attached PDF file produces tons of these console messages (which also occur when reopening it in Inkscape after saving as Inkscape SVG):

File display/nr-arena-item.cpp line 323 (?): Assertion item->state & NR_ARENA_ITEM_STATE_BBOX failed

[su_v (suv-lp)]

reproduced with Inkscape 0.48 and 0.48+devel r9772 on OS X 10.5.8

[su_v (suv-lp)]

Duplicate of or related to bug #168014 “Redraw fails with clipped object patterns”. There are many pattern definitions with clip-paths in the SVG file saved after opening the PDF file, for example:

     <clipPath
       clipPathUnits="userSpaceOnUse"
       id="clipPath4813"><path
         d="M 0,0 L 576,0 L 576,432 L 0,432 L 0,0 z"
         id="path4815" />
     </clipPath>
     <pattern
       patternUnits="userSpaceOnUse"
       x="0"
       y="0"
       width="576"
       height="432"
       id="pattern4817">

[su_v (suv-lp)]

sorry - incomplete pattern definition in previous example...

<clipPath clipPathUnits="userSpaceOnUse" id="clipPath4813">
  <path d="M 0,0 L 576,0 L 576,432 L 0,432 L 0,0 z" id="path4815" />
</clipPath>
<pattern patternUnits="userSpaceOnUse" x="0" y="0" width="576" height="432" id="pattern4817">
  <g id="g4819" />
  <g id="g4821">
    <g clip-path="url(#clipPath4813)" id="g4823">
      <g id="g4825">
        <path d="M 150.633,76.016 C 151.43,76.016 152.191,76.332 152.754,76.895 C 153.316,77.457 153.633,78.223 153.633,79.016 C 153.633,79.812 153.316,80.574 152.754,81.137 C 152.191,81.699 151.43,82.016 150.633,82.016 C 149.84,82.016 149.074,81.699 148.512,81.137 C 147.949,80.574 147.633,79.812 147.633,79.016 C 147.633,78.223 147.949,77.457 148.512,76.895 C 149.074,76.332 149.84,76.016 150.633,76.016 z" style="fill:#008000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-opacity:1;stroke-width:0.5;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none" id="path4827" />
      </g>
    </g>
  </g>
</pattern>

[su_v (suv-lp)]

The SVG file (saved in Inkscape from the PDF) renders fine in Squiggle (Batik 1.7), only some of the dots appear slightly distorted (disappears when zooming in).

[Scott Norris (scottie-z)]

The SVG file (saved in Inkscape from the PDF) also renders fine in evince. But if you then open the SVG file again in inkscape, you still cannot see the indicated elements. So saving / reopening in SVG does not clean up the file.

[su_v (suv-lp)]

> So saving / reopening in SVG does not clean up the file.

No, it doesn't - Inkscape fails to render patterns with clip-paths inside their definitions correctly (bug #168014). When saving as SVG Inkscape doesn't rewrite or "clean" the SVG code which is created by the PDF import routine (poppler?).

[su_v (suv-lp)]

The reference to bug #534679 in comment #3 is not relevant: the error when exporting to EPS can be reproduced with a simple test file (clipped object as pattern), but does not seem to affect the other cairo-based exports (PDF, Cairo PNG).

[Darko Veberic (darko-veberic-kit)]

The same happens in ubuntu 10.10 with inkscape 0.48.0 r9654. With the attached pdf file inkscape almost hangs and does not update the main window for ages. Running with "inkscape 0.pdf >/dev/null 2>&1" solves the slowness problem, but the text and the caption of the bottom figure are not in correct font and the bottom figure is missing a large shaded surface in blue.

[ScislaC (scislac)]

The original issue that was reported has been fixed, although the performance when opening the PDF is definitely not desirable. A separate bug report needs to be filed for that since the reported issue has been fixed. Darko, please file your issue separately as it can still be reproduced with trunk (note: the import preview shows what you describe and what I can see in evince, it's just not shown on canvas). Closing this as fixed (in trunk), if you feel this was incorrectly closed please re-open and explain why.

[su_v (suv-lp)]

> The original issue that was reported has been fixed

Apparently the first merge of the rendering cache branch (r10451) partially broke this again: the import with r10454 and later revisions is of very "poor" quality: a lot of elements in the diagram ('60-drift-estimate.pdf' attached in comment #1) are imported as (page-sized) bitmap-patterns at a very low resolution (pixellated appearance e.g. of all data points even at zoom level 1:1), whereas with r10450 and earlier revisions they import as (nested, clipped) vector-based patterns (i.e. the data points are clipped circles or squares).

[su_v (suv-lp)]

> (…) are imported as (page-sized) bitmap-patterns at a very
> low resolution (pixellated appearance e.g. of all data points
> even at zoom level 1:1)

My bad - this analysis was wrong to: actually it is a bug in the new renderer (reproduced with 10454 and various later revisions up to current 10627) which pixellizes the clipped patterns (nested in several levels): see attached screenshot with one data point "un-patterned" multiple times to get to the final vector object.

The performance of importing such PDF files is so poor that it is cumbersome to open and investigate the issue with several different revisions to narrow down when the regression started.