Home / SumatraPDF CLI and “Microsoft Print To PDF”: how-to automate “Save Print Output As” dialog window?

Hi guys,

first of all: thanks to the developer(s) for this amazingly lightweight PDF reader!
It’s my reader of choice since years

Problem:
I’m exploring the possibility to use the SumatraPDF command-line interface (CLI) in a script.

I would like to print some heavily compressed PDF files with “Microsoft Print To PDF” (the virtual PDF printer in Windows 10), which does and excellent job into “uncompressing” them and making them perfect for further conversion to kepub format.

By looking at the docs (https://www.sumatrapdfreader.org/docs/Command-line-arguments.html), I came up with the following command:

.\SumatraPDF.exe "C:\document.pdf" -print-to "Microsoft Print to PDF"

but when I launch it, I get a “Save Print Output As” dialog window that asks me to manually type the output filename.

I would like to programmatically pass the output filename instead.

Is that possible?

I’m using Powershell, if somebody has a Powershell-specific workround to suggest.

Thanks!
NW

Many commercial PDF printers allow saving names programmatically.
It was the reason acrobat distiller could demand high dollar
Microsoft Print to PDF could but won’t replace that very simple acrobat functionality
There are ways to couple print drivers with folder watchers
so that placing a file in the inbox places the output in another folder

At the end of the day you want to convert a pdf using cli to a pdf and there are many more efficient ways to do that e.g. use the MuPDF tools -decompress options direct

However you say

Since kepub is a zipped folder i.e. not a PDF page format why are you going through those decompression hoops anyway?

AFAIK Kobo e-readers support non-DRM PDFs just fine, so why go through the trouble of multi-step conversion?

@GitHubRulesOK
Thank you for reply!
If the current CLI doesn’t support the filename, it’s something I would consider adding.
I read online that many people are researching a way to do this with SumatraPDF and/or “Microsoft Print To PDF” due of its immediate availability in Windows 10.

I didn’t think about MuPDF Tools, but I’ll definitely explore that option asap!

@GitHubRulesOK, @SumatraPeter
Kobo Readers do support PDF and CBZ files natively yes, but for consuming visual content (comics, magazines) aren’t the fastest horses in the race. On a page turning speed perspective and zoom usability perspective, the built-in PDF reader is only usable for text books. While studying, the page turning speed can be slow, but while consuming entertainment content you need speed.

Plus, you don’t really need color or 2560x1920 PNG images to read content on a 6’ or 7.8’ e-ink display. They just strain the limited resources of the device and add lags for no reason.

You can immediately see the difference by downloading a “Raspberry Pi Magazine” issue in PDF format and attempting to read it on a Kobo device. It loads and renders painfully slowly. Then you can convert it thru Kindle Comics Converter to kepub format + b&w + your device size and try again. In this case will be a pleasure to read.

So if you are an advanced user and an avid reader, you do need an (automated) conversion pipeline in place to feed stuff to your e-ink reader

Ok when reading those MagPis on larger tablet I have not needed to convert them but appreciate the potential need on a smaller device

If converting to cbz produces a slower file than identical pdf then I am a byte surprised since in effect the content as 100 image pages should either way be the same workload

I would be looking to Irfanview to directly batch extract and convert all the pages to png especially if reducing colour to greyscales but the default resolution is not that high since at nominal 96 dpi A4 = 794x1123 so avoid degrading below that if possible. MS print to pdf will degrade by expanding pixels per page which is simply making pages larger than more native sizes
(hint mute the speakers when running more than a few pages the beep for 100 pages with wrong settings gets annoying

as a simple test copy the 4 grey pngs below into a folder (you can copy say 25 times from dummy00.png to dummy99.png right click the folder save as compressed dummy.zip then rename to dummy.cbz and when open in SumatraPDF “save as” PDF then compare the behaviour of 2 known equal files in kobo

Yeah, you can use 1001 GUI tools to do tasks like that, but I already have an automated pipeline coded that works for me with the 83% of the PDFs, but I just need an additional intermediate step to decompress the PDF and try again when the output is not right.

But thank you for your time, I’ll look elsewhere

Have a nice day!

@numbworks
On reviewing old posts I see we did not answer your question well. I guess you have found a solution by now, however in answer to your original query.

Microsoft Print to PDF can be set just like any other print driver to place its output in a given folder and filename, this is usually used to trap a physical printers output for analysis without using paper…
The first task is to copy or replicate the print driver so you have one that works “normally” and one that can be directed to a given filename. There is a limitation that you cant normally change the name so need to have a second command to collect the fixed output and rename or copy it elsewhere.

This is not a SumatraPDF feature but a standard modification to the windows driver output, using Manage Printer Properties where the second copy is switched from “PortPrompt” to “File” folder\name, and it can be a bugbear to get it right.