Unable to allocate enough memory when printing
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Fix Released
|
Medium
|
Unassigned |
Bug Description
I have Inkscape 0.48.0, an HP computer with 64 bit and Windows 7 Home Premium edition, and an Epson workforce 323. So far I have been able to print svg files with embedded pings, and spiro art tilings. The latest file print attempt crashed the program. It was a graphic drawing with a png file of a spiroart tiling embedded in it. I received three error messages- the first read
Glib-ERROR*
tags: | added: crash performance |
Changed in inkscape: | |
importance: | Undecided → Medium |
summary: |
- crashes when trying to print + Crashes when trying to print (Glib-ERROR) |
summary: |
- Crashes when trying to print (Glib-ERROR) + Unable to allocate enough memory when printing |
The file takes a long time (and grabs a lot of system resources) to load in Inkscape 0.48.2 and 0.48+devel r10750 on Mac OS X 10.5.8 (i386). This seems due to the fact that the embedded bitmap image is very large and has to be downscaled for rendering 25 times (original tile + 24 clones).
> So far I have been able to print svg files with embedded pings, and
> spiro art tilings.
Did those earlier SVG files have bitmaps of similar original size embedded and scaled down to about 1/35 of the original image size? And did they have a semi-transparent object in the background as well?
In your attached example, the 1:1 image size of the embedded image is 2791x2777 px. Each of the tiled clones gets scaled down to 79.147x78.750 px in the end. However, since Inkscape doesn't edit the bitmap image itself (unlike down-sampling an image in a bitmap editor), each of the 24 clones and as well as the original image are loaded in its original size and then downsampled to about 2.85% of the size. Holding 25 bitmap images of 2791x2777 px in memory for rendering the content of the tiled clones requires a lot of system resources and - on Windows [1] - apparently triggers a crash.
Try to downscale the bitmap image in a bitmap editor like GIMP first, closer to the size required for the original tile in the SVG file - likely this will allow to print the SVG file without crashing due to excessive memory usage.
> I can print the same file if I print from the exported bitmap, but I think
> the print quality comes out better from an svg file
As long as you have a semi-transparent object in the background of the design itself, it won't matter (postscript output for printing will rasterize all vector objects which overlap the semi-transparent object anyway, creating a fallback image: the sample PS output contains a single, large bitmap with w=476 pt, h=720 pt, res=300dpi). If you want to work with vector data as long as possible, try saving a copy as PDF and printing the PDF using e.g. Adobe Reader.
To further reduce the complexity of the output, you might also consider changing the colors of the background object (rounded rectangle) so that it keeps appearance while having opacity = 100%. This can be done easily with the dropper tool (uncheck pick and assign transparency on it's control bar when picking the fill & stroke color of the current object (opacity 40%), and then change the opacity back to 100%).
[1] printing a slightly modified version (image in original size inside scaled group as original tile) to a Postscript file (via print dialog) works without crash e.g. with Inkscape 0.48.2 on Mac OS X 10.5.8 (i386), however it grabs all resources (memory) it can get for several minutes and slows down the complete system (doing other work while Inkscape is outputing the data to the Postscript file in the background is nearly impossible).