V 0.48.2.1 - Blank printing with large design

[Christian]

On Windows XP 32 bits
Whereas I didn't have any print problem with Inkscape 0.48.1.2, the 0.48.2.1 version and the nightly builds between those 2 versions don't allow to print large designs (several Mo).
It spools something to the printer but it is probably empty.
The same happens when I try to print on PDFCreator which returns an empty blank PDF.
If I validate the printer bitmap option instead of the vectorial one it prints correctly (an ugly bitmap of the SVG file).
However, printing lightweight files operates normally.

[su_v (suv-lp)]

> the 0.48.2.1 version and the nightly builds between those 2 versions

There are no nightly builds of the 0.48.x branch for Windows available. Could you please tell which revisions of the development branch (those packages which had been available on inkscape.modevia.com) you used to test printing with (see Inkscape menu 'Help > About Inkscape')? And confirm that the same issue occurs indeed with the latest stable release 0.48.2?

> The same happens when I try to print on PDFCreator

What happens when saving a copy as PDF (vie 'File > Save a copy') instead of printing to a PDF printer?

> don't allow to print large designs (several Mo)

Could you please attach a sample file which doesn't print allow testing on other systems? Does it depend on whether there's heavy use of filter effects (including blur) or reduced opacity of objects or groups, reduced transparency of fill or stroke, or patterns with clipped objects (e.g. due to having imported PDF or EPS files), etc. …?

Possibly related to the fix (in the development builds only) for bug #494115, to the upgrade of cairo in general (0.48.1: 1.8.8, 0.48.2 1.10.2, 0.48+devel: 1.11.2), or - if confirmed for the nightlies only, to the merge of the new cairo-renderer.

[su_v (suv-lp)]

@Alvin, @JazzyNico: could one of you test on Windows with latest stable (cairo 1.10.2) and a development build with cairo 1.11.2?
Can one of you confirm that printing on Windows is based on PostScript output to whatever printer is selected (and not PDF itself, even to a PDF printer, or GDI)?

1) Open questions:
(necessary to determine the cairo version bundled with the Windows package used to report this issue):
- which revisions of the development branch did you test (downloaded from inkscape.modevia.com)?
- please verify: does the error indeed also occur with stable Inkscape 0.48.2 (cairo 1.10.2)?
- does saving a copy as PS work with all tested builds, or fail with the same ones which print an empty page?

2) Tests done on Mac OS X 10.5.8 (i386):

a) Inkscape 0.48.2, 0.48+devel r10627, cairo 1.10.2, pixman 0.22.2
- Saving a copy as PDF/PS/EPS works correctly
- Printing to file via print dialog (PDF, PS) works correctly

b) Inkscape 0.48+devel r10627, cairo 1.11.2, pixman 0.22.2
- hangs when saving a copy as PS or EPS
- hangs when printing to PS file via print dialog

c) all tested builds:
Saving a copy as PDF or printing to PDF file via print dialog works correctly.

The issue (at least on OS X) seems likely upstream with the most recent cairo snapshot (1.11.2 - which also ships with the Windows development builds) or pixman 0.22.2 when exporting to PS/EPS (but not PDF) - with large files making use of reduced opacity (layer, objects) as well as partial transparency of fill and/or stroke.

Attaching two backtraces after interrupting the save/print process in gdb (since Inkscape appeared to hang with steadily increasing memory consumption) with the GTK+/Quartz build of current trunk using cairo 1.11.2.

[su_v (suv-lp)]

This modified version of the file exports without problems to PS with both cairo versions (stable and trunk) - without any rasterization (all content in the PS file is vector-based and scales without pixelation). Changes:
- all hidden layers deleted
- defs vacuumed
- all layers set to 100% opacity
- semi-transparent objects flattened as far as possible _without_ diving into details (splitting partial overlaps with shapes below into separate objects with solid fill)

I was not able to create a reduced test case [1] for the apparent failure to export the original file to PostScript.

<off-topic>
I'm impressed by the precision and quality of your drawing! An excellent demonstration of Inkscape's capabilities despite the known limitations with regard to technical drawing :)
</off-topic>

[1] with few partially transparent objects, or reduced opacity

[Alvin Penner (apenner)]

running Windows 7, Inkscape 0.48.2, I get:
- printing to PDFCreator, I get an empty file, file size = 3K.
- using SaveACopy and choosing pdf, I get the attached, which looks quite reasonable.

[Alvin Penner (apenner)]

essentially the same behaviour on Windows XP, recent Inkscape build. This looks like a problem in PDFCreator.

[Alvin Penner (apenner)]

> Can one of you confirm that printing on Windows is based on PostScript output to whatever printer is selected

this is a bit outside my area of comfort, but as far as I know Windows does not ever use either postscript or pdf format unless it is specifically told to do so by choosing a postscript driver.

for example, in my case I do not actually have a printer attached, but I have a HP Deskjet printer driver, and when I print to file using it then the output is in PCL3 as far as I can tell.

[su_v (suv-lp)]

Alvin Penner wrote:
> running Windows 7, Inkscape 0.48.2, I get:
> (…)

Could you please test with trunk too (devlibs have cairo 1.11.2 on WIndows ,too), whether you can confirm my results?

[su_v (suv-lp)]

> (…) whether you can confirm my results?

referring to saving a copy as PS/EPS with stable (cairo 1.10.2) and trunk (cairo 1.11.2).

[su_v (suv-lp)]

> but as far as I know Windows does not ever use either
> postscript or pdf format unless it is specifically told to
> do so by choosing a postscript driver.

Nevermind - AFAIU it is handled by cairo internally (cairo has a win32 printing surface, and a suitable cairo context for printing should be created by GTK+ itself).

[jazzynico (jazzynico)]

Tested on Windows XP.
- With 0.48.2, PDFcreator outputs a blank file.
- With r10614, the file is as expected (see attachment).

[su_v (suv-lp)]

No one willing to test saving a copy as PS or EPS with a build using cairo 1.11.2?

[LucaDC (lucadc)]

I don't know how to verify my version of Cairo. I've used rev. 10627 under Windows XP SP3.
I could save a copy in both EPS and PS format but only with the "Export area is drawing" option set (I also tried with and without "Rasterize filter effetcs" and with PostScript level 2 and 3 and with and without "Export area is page" and 90 or 300 dpi but they did not count).
Otherwise I get a "File blablabla.bla could not be saved." message and a 0 byte file.

[Alvin Penner (apenner)]

interesting...
running Windows XP, Inkscape rev 10627, Cairo 1.11.2
- when I try to save as .ps and choose Export as Page then it fails
- when I try to save as .ps and choose Export as Drawing then it works, with the attached result.

[su_v (suv-lp)]

Alvin Penner wrote:
> - when I try to save as .ps and choose Export as Page then it fails

I was interested in testing PS/EPS export because AFAIU at least parts of PDFCreator are simply a native GUI for redmon+ghostscript [1] (PDF files are created by PDFCreator with ps2pdf from Ghostscript, but it's unclear to me if the PDF printer requests PostScript output from the application or if the PostScript is generated internally by either the OS or the driver itself).

[1] Document → Virtual Postscript Printer → RedMon → Ghostscript → GS pdfwrite device → PDF file
    <http://www.stat.tamu.edu/~henrik/GSWriter/GSWriter.html>

[Alvin Penner (apenner)]

also, in the case of pdf, there are the same two options, save page and save drawing. Both options work equally well for pdf, the only difference between them being the border, or lack of it.

[jazzynico (jazzynico)]

Related to bug #709927 "Inkscape turns from printing document to printing blank page".

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape 0.48.2, printing to PDFCreator. Using a resolution of 300 or higher produces a blank page. Works correctly with 15Odpi or lower.
Not reproduced with trunk revision 10948. Prints correctly whatever the resolution.