3.1 | ability for user to select 'print as image' as option (rather than default)

[cooch17]

3.1 dispenses with the ability of the user to tweak SumatraPDF-settings to turn on/off printing a PDF as an 'image'. I understand that printing as an image increases the chances of output that is WYSIWYG/

But, it also (i) increases the file size sent to the printer many-fold (try printing a 30 page book chapter that has gone from 30 Mb sent to the printer using 3.0, to >2.5 Gb sent to the printer using 3.1), and (ii) often results in printed output that is not as 'crisp' or 'sharp' as it is when not printed as an image (a sample of my students were able to pick ut 3.1 printed documents every time -- because they didn't 'look as sharp').

I appreciate that 'print as image' has its virtues, but only for files that don't print nicely. Most do, and standard printers. So, rather than make print as image the defaul, make it a selectable option for people who only need it occasionally?

Thanks!

[kjk]

That's exactly how it worked before and causing many bug reports.

[cooch17]

Thats because the 'wrong default' (for some) was specified in .0. The user had to dig into advanced options to flip a switch for 'print as image'.

So, why not either

(i) add a toggle to the standard options to let the user pick (best option)

(ii) change the defaults -- make the default 'print as image', but allow the user to over-ride this using 'advanced options'.

Seems as if you've reduced flexibility with th 3.0 to 3.1 change: at least in .0, user had a choice. Now, in 3.1, no choice at all. Wrong direction for things (unless you're Apple, and reducing choice is the 'business model' ;-)

On 10/26/2015 4:10 PM, Krzysztof Kowalczyk wrote:

That's exactly how it worked before and causing many bug reports.

— Reply to this email directly or view it on GitHub https://github.com/sumatrapdfreader/sumatrapdf/issues/329#issuecomment-151268780.

[SumatraPeter]

Agree with whatever @cooch17 said - this should definitely be an option. If some people can't be bothered to edit the advanced options file to adjust behavior to what they prefer then too bad, but removing the option completely seems like an over-reaction to me. I'd be perfectly satisfied with "print as image" being the default as long as I can change it.

[mikeri]

Another "me too" comment. Print as Image in any PDF application (including Adobe Reader/Acrobat) is a general workaround when experiencing unexpected output. Leaving it on as default can be a rather heavy solution, as data transmission and processing can generate huge amounts of data, and removing the option completely with it set to on due to uninformed users is a potential deal breaker.

I really appreciate SumatraPDF, but can unfortunately not use versions newer then 3.0 for my workflow.

[yokosuna]

me too !

[chomee011]

992

"Print as image" is a serious problem, can you please add an option to disable it.

[benryanau]

Amen.

[naturmensch]

Just created an account to tell you that i feel the same :D i hope that it will be changed in the future, because i really like Sumatra and it is the only well-working opensource-reader there is for me.

[carculator]

Four years later, I´m pretty sure that this won´t change anymore. :-(

[rawtaz]

Just to be clear; Is there currently (at this point in time) no way to configure this for Sumatra? Not even in the settings file or even with a registry variable? It's one thing if there isn't a GUI for it, but it would be great it it could be changed more "manually".

[cooch17]

This is why I've given up on Sumatra (and why the IT staff at my university has now 'banned' Sumatra from any of the systems they maintain). Print as image without and option to change it, is overly Draconian.

Too bad, really. Sumatra used to be a wonderful application.

[rawtaz]

What other open source PDF reader alternatives are there? I haven't found any that seemed viable.

[cooch17]

Sure - xpdfreader. It is now my go-to option. Doesn't have all the features, but (shock!) it doesn't print everything as an image.

https://www.xpdfreader.com/

[rawtaz]

Too bad that XpdfReader isn't entirely open source, it's just part of it that is. Does anyone else know any (fully) open source Windows compatible PDF readers other than SumatraPDF?

[tgd-git]

why is this issue closed? this default setting, without the option to change, is a big pain when you work remote and need to print anything on a local printer.

[GitHubRulesOK]

@tgd-git It is closed as there is no "default" as such to alter. The most reliable windows print method is either to write your own interface to multiple printers e.g. PS/PDL etc. as Team Adobe / GhostScript (Team Artifex) and many older softwares did (but many now don't) OR use the baseline windows system for image and screen printing GDI-PAI which is what SumatraPDF did and does. Bit confused by remote and print local reference but presume you mean the large transmission of a file built remotely needing to be sent to a served printer?. Where the alternatives are to either create print file at the client (remote) and transmit to printer server OR send print instructions from "remote" to Print Server to build its output locally. Both have their merits depending on input / output. However SumatraPDF has in the main been built on MuPDF (Artifex) where the premise it is an image/screen viewer/reader and served printing is better performed by its print dedicated sister application AKA GhostScript (Artifex).

Served printing has many issues compounded by networking, and having recently tested both choices using GhostScript (without SumatraPDF) I have my in my own humble opinion decided it is much safer (less corruption) for the client/remote to generate a PDF locally then transmit that file to the printers host to then "print locally".

Clearly the PDF for "printing only" can be an image based one, which SumatraPDF can generate but the PDF size for transmission depends on the source machines drivers.

Try a comparison print from a file printed from SumatraPDF using MS PDF driver = 3.7 MB GS PS driver = 1.6 MB MS XPS driver = 0.9 MB Win2PDF driver =0.7 MB GS PDF driver = 447 KB

I thus suggest you use GS Printer as the most efficient in terms of memory, but as I stated above avoid using for Print Serving I.E. use it on the remote to create the PDF either by printing from SumatraPDF OR Standalone.

[tgd-git]

Thank you for the detailed answer and explanation. It seems i have misunderstood that there was an option. I followed a link to this issue here from an other discussion about sumatra producing very big files in the printer spool compared to other pdf readers.

Regarding remote/local i might have a bit quirky? setup running. i am on a vpn connection and working via remote desktop on a server in that remote lan. the server has my shared local printer installed (which it can find via the vpn) so the software i am working with (running on that server) can pick it up easily as it was locally there. (using the rdp printer sharing is not an option for me)

Anyway just comparing a print of a pdf opened in google chrome vs sumatra, chrome produces like 69 kb of spool data but sumatra makes it several MB that need to go through the network. I was in believe that is related to this discussion and could be changed. Also "print file at the client" option in printer settings does not change anything in my case.

[GitHubRulesOK]

@tgd-git Free OpenSource SumatraPDF is suggested as a GoTo app in place of using a Licensed GhostScript especially since it has a reasonable set of CLI printing options. Then users complain a screen biased application is not "fit for my purpose" That old HACK(need) "You get what you pay for" springs to mind. SumatraPDF is excellent for handling Gigantic Images quickly, vector printing is not its forte.

[tgd-git]

I guess as an avarage user you are not aware of certain things/limitations until you run into them. In fact I was using sumatra at the remote location as viewer only most of the time and rarely printed anything. Please dont take offense from my comment, i have installed sumatra because its a great, fast software with no bloat and it always served me well. Cheers

[cooch17]

Sorry, but that still misses the point, I think. My original query concerned why reduce the number of printing options from 2 -> 1? With the 'update' from 3.0 to 3.1 (and newer), the user has no options but to print as image. Which, makes it exceedingly difficult to do the two things I use Sumatra for - viewing, and printing (if all I wanted was a viewer, I'd simply use muPDF). A test file that spooled at 4.5Mb using 3.0 was >1.5 Gb (!) when printed as an image using 3.1 (back when I did the test). So, I rolled back to 3.0.

As per my original suggestion:

i) add a toggle to the standard options to let the user pick (best option)

(ii) change the defaults -- make the default 'print as image', but allow the user to over-ride this using 'advanced options' (basically, edit a configuration file).

At any rate...

[m4heshd]

Agreeing with @cooch17 here. An option is always better than being forced to a specific usage, regardless of the outcome. Flexibility in APIs is what makes them great. Sumatra is awesome but we just need to have these kinds of options mostly since they're actually available but unexposed.