mass memory needed for printing any pdf document : simples pdf documents (1 page, black & white, from multiples pdf renderings...). The print is good but very long (+or- 100 Mb/page in spooler).

Unfortunately the way mupdf works, high memory usage during printing is unavoidable so I doubt it'll ever change.

just wanted to say that I noticed the same issue while printing. that's the only thing that i don't like about sumatrapdf so far.

Comment deleted

When I tried to do a quality printout of a 13-page 500k document which is basically a raster scan, SumatraPDF had sent a 1-gigabyte spool file by the time it got to the third page. I had to cancel the print job and kill the processes. I'm surprised to hear you say that this is inevitable given the way mupdf works, since the Artifex people are basically the world's printing wizards and there's never been this kind of trouble with ghostscript/ghostpdf.

I am eager to join the project later on, I like the work that has been done here a lot. Can I learn whats the problem with memory consumption for print? Does printing equal to rendering the page with some huge zoom?

Yes, that's it. We render bitmaps at too high resolution. There's a tradeoff, though: the lower the resolution of the bitmap, the lower quality of the print so the trick is to figure out what is the min resolution at which things still look good and doesn't use lots of memory.

Another thing to try would be to figure out how to send grayscale bitmaps instead of 32-bit as we do now, both when a printer is black-white only and when a PDF page is black&white.

Issue 466 has been merged into this issue.

Issue 463 has been merged into this issue.

Issue 535 has been merged into this issue.

I know that odds are that it would be more work, but could MuPDF be changed to better handle printing instead of Sumatra outright? If it's feasible, it might be worth it because it might benefit other projects that use it too (and those others might be willing to help improve it), unless as dmjensen7 suggested that it is only Sumatra that is having trouble with it.

The main issue is that MuPDF (or rather Fitz) doesn't have a GDI rendering backend (yet) which would allow telling the printer "this text goes here" instead of "dots go there, there, there, etc." which is currently the only option.

I wouldn't expect mupdf to ever get GDI backend. The only option I see here is to try to use the minimal DPI for rendering the bitmap that still gives decent results when printed. Also, if there was a way to detect if a given page uses color or not, we could render in grayscale, using less memory for the bitmap than color bitmap.

Issue 348 has been merged into this issue.

Sure seems like it would be a good option to be able to choose the DPI and the color depth of the generated bitmaps, as that would make this at least manageable.

Issue 830 has been merged into this issue.

I am not a programmer but I do know windows is sluggish at handling any large files. Can we break down the print job into smaller jobs by sending one page at a time rather than one huge job? This way each job out of a 10 page pdf is 100k rather than one huge gig. So the printer is able to work on one page while Sumatra is rendering the next. I guess what I am getting at is an option that basically is an automated way to print by looping through an incremental range: 1-1, 2-2, 3-3 one at a time instead of the entire document at once. This would also have the benefit of not having to render the entire print job if the printer spool craps out. Sumatra already knows the last page it spooled and can pick up from there.

I'm having this problem. I can't print anything without my computer almost crashing. A recent print sent from Adobe Reader was 23kb, and 114mb from Sumatra.

@julian.battye: to help reduce such memory consumption, sometimes (if that's okay with you) you can reduce the printing quality in printer settings. Doing so (with my HP) can considerably ease the process of printing with Sumatra.

/maybe-useful temporary workaround

Issue 915 has been merged into this issue.

r1913 should slightly improve things at least for monochrome documents.

A better option might be to get a Cairo draw-device into MuPDF which would give us a GDI back-end without quite as much effort (Cairo's interface is quite similar to MuPDF's own, cf. http://cairographics.org/ ).

With the recent reorganization of MuPDF it would probably be possible to write GDI backend directly (without going through Cairo). On the other hand, in order to get most
of the benefit it would mean using Win32's font rendering as well (instead of doing fonts as bitmaps via freetype) so I'm not sure if it wouldn't decrease quality.

This problem is pretty serious, because even trying to print moderate size documents can cause the whole computer to hang for ages (20 mins or more) and no warning is provided to the user that SumatraPDF is about to try to send GB of data to your printer beforehand.

Since printing moderate-large documents with Sumatra is not going to be solved any time soon (at least not without a lot of work) I'd like to suggest implementing a simple workaround proposed in this forum thread:

http://forums.fofou.org/sumatrapdf/topic?id=787323

Basically, it provides a link which will open up the document in Adobe Reader with the print dialog activated so that the document can be printed from there, and it's all done via simple command that can be executed on the command line.

Thank you.

I respectfully disagree with the above post - it is in no way a suitable workaround to call Adobe Reader for printing. Sumatra PDF is meant as a lean REPLACEMENT for Adobe Reader, so in no way it should require (or promote) installing Adobe Reader in addition to itself.

I fully agree that the printing problem is a serious and urgent issue, but it should be solved within Sumatra without the need to install an additional PDF reader.

As already said above, the one and final solution is the integration of a GDI based backend in either Sumatra or MuPDF. As an intermediate workaround, it should be possible to explicitly specify a user-defined DPI value for rendering, with Sumatra directly showing the according memory required for printing.

Do not want any link to or launcher for Adobe Reader as a workaround for printing. Not that I think the developers would seriously consider it.

Please understand, I would love a proper solution that will allow me to print directly and efficiently from Sumatra PDF via Sumatra PDF. The "Print from Adobe Reader..." link idea was only intended to be a temporary workaround that's very easy to implement. Given that it has been a couple of years already without any progress on this issue I am assuming that the developers haven't got much time on their hands for major code changes.

threexk1, there is already a link in Sumatra PDF for opening documents in Adobe Reader, so the developers might not mind adding one more practically identical link. It think that it would probably be much more appealing to a time-streched developer than any other solution, especially given the number of threads on the forums about this issue.

"Promoting" using Adobe Reader, or providing an option for printing using it may be unsavoury, but the reality is that I am forced to use the "Open in Adobe Reader..." link regularly because it's the only way I have of printing documents anyway. I then have to select print from there. It's cumbersome and annoying. It almost makes Sumatra unuseable. The workaround I suggested would at least mean that it would only take one click from Sumatra to bring up a print dialog for the document (if Adobe Reader is installed), which is quite an improvement on the current process.

For me, the Sumatra is both the best PDF viewer and worst PDF viewer for my purposes. Best, because it is lightweight, portable and has one feature that I need and which I have not found elsewhere; the ability to auto-update when a document is updated, which prevents the need for opening and closing the viewer each time when used as part of a publication toolchain. Worst, because I can't then use it to print. It is a major shortcoming, so I really hope it can be fixed, or at least made more useable, sometime soon.

If there is an existing link to open Adobe Reader in Sumatra, my preference would be to remove it or have it be available via some sort of Sumatra plug-in or extension. For those of us who won't infect their machines with Adobe Reader, any links are distractions in the UI, extra bytes, and extra CPU cycles.

threexk1. I understand that you dislike Adobe Reader, which is fine. Of course, you're under no obligation from anyone to install it or use it. However, the existing link is hardly a distraction in the UI if you have never even noticed it and it certainly doesn't use extra CPU cycles. Granted, the link might be adding a few bytes to the Sumatra memory footprint, but removing it in favour of developing and adding a plugin\extension manager to Sumatra instead is not going to make it more lightweight and would not help solve the problem at hand, which is printing medium to large documents in Sumatra.

"Open in Adobe Reader" only shows up in the menu if Adobe Reader is already installed. Checking whether Reader is installed takes less than a millisecond; there's no way that the "extra bytes and extra CPU cycles" are any detriment to those who don't use the option.

In recent revisions Zeniko is both trying a "print through Reader" type option for those who have it installed (r1980,r1982) and beginning to work on a GDI backend (r1994,r2002,r2007). I wouldn't anticipate the backend being finished tomorrow or the day after, but I'm very glad to hear it's in progress.

Brilliant! Thanks for the update dmjensen7.

I just checked the code out of svn and compiled it. The "Print with Adobe Reader..." option works perfectly. Thanks!

Satisfied that the "Print with Adobe Reader..." menu item does not appear if you do not have it installed. Thanks for doing it that way. Still, it amuses and slightly troubles me that Adobe Reader manages to slow your system down (however insignificantly) even when not installed! Hopeful we can get rid of this workaround in the future.

I had been wondering why a 310 KB (9 page) PDF file was sending over 655 MB to the printer! This is definitely something that should be fixed!

Issue 909 has been merged into this issue.

With r2081-r2090, printing should finally be reasonably tolerable. You can now choose between SumatraPDF and Adobe Reader for printing (the latter has moved to its own menu item resp. Ctrl+Shift+P until we decide we no longer need it). There are still some rough edges to be worked out, so please file new issues when testing it yourself.

A note for Windows 2000 users: SumatraPDF now depends on the GDI+ library which you might have to download separately from http://go.microsoft.com/fwlink/?LinkID=20993 (this library is already included in Windows XP and later).

With the most recent GDI+ fixes, I consider this issue fixed. Regarding printing issues, please either comment in issue 1035 or open a new issue, describing what's misprinted and linking to the document in question.

BTW: See http://blog.kowalczyk.info/software/sumatrapdf/prerelease.html for a prerelease build containing the mentioned changes.

Issue 1073 has been merged into this issue.