Pattern fill incomplete with PDF export and printing

[Esther]

I created an object with a white fill and black stroke. I duplicated it and added a fill to the top object. The saved SVG file retains the fill properly. After exporting the drawing to a PDF, the object's fill is partially missing. Printing the SVG document gives the same result with the object's fill partially missing.

Inkscape version: 0.91
OS: Xubuntu 14.04
Printer HP Officejet 6700
PDF viewer: Document Viewer

=====
Related reports:
Bug #1597955: pattern fill not saved to pdf correctly
Bug #1488129: Pattern not exported to pdf or printed (cairo >= 1.12)
Bug #1462589: When saving to pdf at certain page size, a pattern disappears.
Bug #1441753: Patterns not exporting correctly to PDF
Bug #1437726: Pattern fill incomplete with PDF export and printing
Bug #1390569: SVG fill pattern lost on PDF export

[Esther (melanes)]

The original SVG file.

[Esther (melanes)]

Forgot to add the PNG export shows the fill as it should be.

[Tavmjong Bah (tavmjong-free)]

It seems that objects whose x and y origin are large are not being included in the pattern as exhibited by the attached simplified SVG file.

Dumping the pattern as a PNG in CairoRenderContext::_createPatternPainter() (cairo_render_context.cpp) shows the proper pattern but examining the content of a PostScript file (PostScript is closely related to PDF but is easier to work with) shows that only part of the pattern contents is present.

Note: The pattern is not rasterized by Cairo. It remains as vector content inside the PostScript or PDF file.

[Tavmjong Bah (tavmjong-free)]

Bug 1390569 suggests that this could be a Cairo bug introduced between 1.10 and 1.12. The bug doesn't appear in rsvg-convert. However, Inkscape is scaling the pattern up by a factor of 100 in order to better render patterns with non-integer pixel widths or heights. (Cairo requires patterns to have integer width and height.) If I change the scale factor from 100 to 1 (SUBPIX_SCALE in cairo-render-context.cpp) the test pattern renders as expected.

I believe this is a Cairo bug.

[Shai Efrati (shaief)]

Just for the record: i introduced a workaround that will help users in the mean time:

Use a filter on objects with patterns. This way Inkscape will rasterize them when saving as a PDF.

http://graphicdesign.stackexchange.com/a/60859/6920

[Hans Milos Toquica Cáceres (hmtoquicac)]

Is this bug fixed already? I wouldn't like to use the workaround of applying the filter.

I tried to export it as an eps and convert it to pdf by means of using LaTeX. No good luck either.

[Hans Milos Toquica Cáceres (hmtoquicac)]

The solution posted by https://launchpad.net/~suv-lp does not entirely works, as for objects created and rotated including a fill patter, the filter won't be applied correctly, this is a couple of reported bugs: Bug #1414214 and Bug #806028.

However a valid solution is making the image really big (hit Ctrl+D and set a custom size), the size that worked for me was 40 times horizontally bigger and 40 times vertically bigger. After saving the file as a pdf, you can use a cropping tool to resize it.

It is advisable to use 'pdfcrop' from the package 'texlive-extra-utils', just enter the command 'pdfcrop file.pdf' and it will provide a file 'file-crop.pdf'. This is in case you want to resize the file to the content (no margins), in case you want margins, please read the help on this package (enter 'pdfcrop --help' in the terminal).

This was confirmed by using Kubuntu 16.04.

[Hans Milos Toquica Cáceres (hmtoquicac)]

This is the result which is satisfying. For some reason, the Okular reader fails to show the render completely fine, however the other pdf reader show the render in the proper way.

[Blake Hannaford (blake-hannaford)]

This bug is still present in Inkscape 0.92.3

[Albert (sapristi)]

To reiterate that this bug is still present in Inkscape 0.92