Adding more control over the GS call

tavinus commented 6 years ago

Adding more control over the GS call. Also need to decide on default values (use 600dpi and bicubic?)

Add parameters and default values for:

DPI ( -dColorImageResolution= )
Rescaling Method ( -dColorImageDownsampleType= )
Output Device ( -sDEVICE= )
GS PDF Settings ( -dPDFSETTINGS= )

Example of dpi/rescaling on @czr's fork: https://github.com/czr/pdfScale/commit/058bfbbb20bcd6924f1a42745c6af353115f6cbd

        # Scale page
        "$GSBIN" \
-q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dSAFER \
-dCompatibilityLevel="1.5" -dPDFSETTINGS="/printer" \
-dColorImageResolution=600 -dColorImageDownsampleType=/Bicubic \
-dGrayImageResolution=600 -dGrayImageDownsampleType=/Bicubic \
-dColorConversionStrategy=/LeaveColorUnchanged \
-dSubsetFonts=true -dEmbedAllFonts=true \
-dDEVICEWIDTHPOINTS=$PGWIDTH -dDEVICEHEIGHTPOINTS=$PGHEIGHT \
-sOutputFile="$OUTFILEPDF" \
-c "<</BeginPage{$SCALE $SCALE scale $XTRANS $YTRANS translate}>> setpagedevice" \
-f "$INFILEPDF"

References:

czr commented 6 years ago

It turns out that I'd thought that the resolution should be an option, and I'd half-written it then forgotten about it. I fixed it up and pushed it just now: https://github.com/czr/pdfScale/commit/955d1a5c31d7b6ac704d1eba8e11e36cb94f7438 – please feel free to use as much or as little of that as you like.

I couldn't say whether 600dpi should be the default or not. It was just where I ended up on the file size / quality tradeoff.

As for bicubic, I took another look at the ps2pdf options and actually bicubic comes with the /Printer settings. I'd probably just misread the table. So I've taken that out from the commit above.

One thought that I've had about this, though, is that Ghostscript's options are complex. It's easy to get into a situation where you think, "oh, I'll just add an option for image resolution," and a month later, "oh, I'll just add an option for the PDF compatibility level," and before you know it you've got a massive list of options. It might be better to just have some generic way of passing through options to Ghostscript rather than doing it one at a time.

tavinus commented 6 years ago

Thanks for the reply!

You are right on GS. It is very complicated.

One of the main reasons for having pdfScale is that it is SIMPLE and EASY to use. Most times I just use it without options (for -5% size on PDFs with no margins). There is also the use case of people shrinking their documents in byte size. I should probably do something for this use case, even though /printer tends to shrink documents.

On the other hand, I have no problems on giving more options and more control to the user. It is then optional and should have a default value that works well on "most" cases.

I have been a bit busy so I could not do this yet. But then I would have missed your last PR if had done it already.

Your PR seems pretty good to me. I will probably merge it on another branch so I can change more stuff before releasing.

Cheers!

tavinus commented 6 years ago

I have finally pulled @czr 's stuff and implemented the rest.
It has also been published as a release - v2.2.0.

I gave up on the Output Device ( -sDEVICE= ) parameter because that could make it not render a PDF and then we would be going way beyond the scope of pdfScale.

All else was implemented!

Edit: v2.2.1 is out!

Cheers!
Gus

tavinus / pdfScale