Unable to allocate enough memory when printing

Bug #896664 reported by RitaL.
14
This bug affects 2 people
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**:gmem.c:36: Failed to allocate 31002428 bytes. The second and third messages were Application requested runtime to terminate in an unusual way, and Inkscape has encountered an internal problem and will now close. 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, and up until today I was able to print from svg files on my system. I've uploaded the file.

Revision history for this message
RitaL. (ritalouise2) wrote :
Revision history for this message
su_v (suv-lp) wrote :

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

tags: added: printing win32
Revision history for this message
su_v (suv-lp) wrote :

Please test printing the attached version of your SVG file, which uses a smaller size of the original image (482x480 px) and solid fill&stroke colors of the rounded rectangle at 100% opacity.

The content of the document was split onto three layers to ease working on the separate parts (background, tiled bitmaps and vector overlay).

Please try also saving a copy as PDF and printing the PDF with a PDF viewer like Adobe Reader (instead of directly printing from Inkscape). In my tests, the PDF file keeps all vector objects as vector, as well as the transparency of the bitmap in the tiled clones.

jazzynico (jazzynico)
tags: added: crash performance
Changed in inkscape:
importance: Undecided → Medium
summary: - crashes when trying to print
+ Crashes when trying to print (Glib-ERROR)
Revision history for this message
Kris (kris-degussem) wrote : Re: Crashes when trying to print (Glib-ERROR)

File loads quickly (only some 6 seconds on my PC), so I would not say there is a performance hit. Also the memory consumption is with roughly 840 MB still reasonable with Inkscape trunk r12169.
My vista64 system indeed crashes due to limited amount of memory. Although this also seems reasonable to me given the size of the original file. (with reasonable I mean, it might take up to the same amount of memory to send the page content to the printer, but I do not have such an 840 MB of free memory in excess)

PS: the following (Dutch) message popped up on the command line:
_create_dc_and_bitmap: Onvoldoende opslagruimte beschikbaar om deze opdracht te verwerken.

tags: removed: performance
Changed in inkscape:
status: New → Confirmed
jazzynico (jazzynico)
summary: - Crashes when trying to print (Glib-ERROR)
+ Unable to allocate enough memory when printing
Revision history for this message
Tamir Bahar (tmr232) wrote :

Closing because bug does not reproduce on Inkscape 1.0alpha (331007d, 2019-04-11)

Closed by: https://gitlab.com/tmr232

Changed in inkscape:
status: Confirmed → Fix Released
tags: added: bug-migration
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.