psnup with output page size set to tabloid produces bad results about psutils

[rrthomas]

Thanks for the report; please can you attach the input and output documents, as I can't reproduce the problem with test documents (see below!)?

[rrthomas]

I can't reproduce this bug with some simple tests. I tried imposing letter 2-up on to letter (as a sanity check), and on to tabloid size paper, and then tabloid on to tabloid. All of these worked fine.

[efalk]

Oh wow, fast response. I'm attaching a trivial test file that shows the issue. I invoked it with:

psnup -2 -ptabloid test.ps test2.ps

I'm using the version installed by brew install psutils on a Mac. psnup --version reports:

    psnup 3.1.1
    Copyright (c) Reuben Thomas 2023.
    Licence GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

test.ps.tgz

(I've updated test.ps.tgz to include the output as well)

[rrthomas]

This is simply a case where you have to tell psutils the input paper size, as there's no paper size it can read in the input file.

Given that this sort of problem seems to be quite common there's perhaps a case for optionally using the bounding box to guess the paper size. I'll close this bug and file another issue to consider that.

[efalk]

Yes, the apps I've written to process postscript look at the BoundingBox and the PageBoundingBox fields both.

What would the correct arguments have been? I did play with it for a while before giving up and filing the bug. I tried

psnup -2 -Pletter -ptabloid test.ps test3.ps

and it was still wrong. I have yet to find a combination of arguments that work to place two letter-sized pages onto one tabloid-size page.

I actually cobbled together my own app that's basically psbook and psnup -2 rolled into one: https://github.com/efalk/Tools/blob/master/ps2book.py. The key function is analyze() which makes a list of all the pages, and assigns them sizes based on their PageBoundingBox if found, else the document BoundingBox. Then the individual pages are scaled to fit their assigned space within the output page. It's worked fine for the few documents I've tried it with.

[rrthomas]

What would the correct arguments have been? I did play with it for a while before giving up and filing the bug. I tried

psnup -2 -Pletter -ptabloid test.ps test3.ps

This is correct, and indeed when I run that command the output is correct. I attach the result.

test3.ps.gz

[rrthomas]

P.S. Thanks for the tip about PageBoundingBox.

[efalk]

Hmmm. Your version of test3.ps also looks wrong on my Mac. I assume you have a Linux box? There's something about it that Mac doesn't like. This is true whether I open the .ps file directly (in which case Mac converts it to pdf before displaying), or if I run ps2pdf first.

Could you try running ps2pdf on your test3.ps and see what it looks like?

[efalk]

Update: adding this line immediately after %%BeginProlog seems to have made My system happy:

<< /PageSize [ 792 1224 ] /Duplex true>> setpagedevice

[rrthomas]

I can pretty confidently say this is not a Mac vs Linux issue, as neither macOS nor Linux has "built-in" support for PostScript. The problem is arising because the PostScript viewer (I guess that might be Preview on macOS? I didn't recognize it from the screenshot!) is not using the %%DocumentMedia header, whereas Evince (which is what I'm using) definitely is.

I'm certainly not about to inject actual PostScript, as you did, into the output of PSUtils, as there's no telling what that might do in general—the downside of PostScript being a relatively unstructured Turing-complete language. Already, PSUtils's approach to PostScript is fairly ad-hoc, even at the DSC level at which it works.

Hence, I think I can conclude that the output of PSUtils is correct, that I can keep the issue closed, and indeed in general I always prefer where possible to work with PDF (and that's why I added PDF support to PSUtils).

When I run ps2pdf on test3.ps I get a result that is A4 landscape. That's not a surprise: it too is using the default paper size I have configured. The following incantation gives the right result:

gs -sOutputFile=test3.pdf -dNOPAUSE -dBATCH -sPAPERSIZE=a4 -sDEVICE=pdfwrite -dSAFER test3.ps

Anyway, thanks again for your report; I will shortly be releasing PSUtils with better support for reading e.g. BoundingBox to get the paper size. This won't help in this case, as the problem is (in my opinion) in the viewer program.

It looks as though there's also something to be said for adding PS↔PDF conversion to PSUtils. Big picture: PostScript is difficult to work with, and tools including PSUtils tend to operate with conservative assumptions to avoid creating new problems. Since PSUtils users are usually concerned with page size (and in most cases, they "ought to know" what size they're working with), PSUtils can at least optionally be more strict about knowing the page size, and hence writing it explicitly into the output document (as it already does in this case). For a putative option to convert PS↔PDF, it would be possible to effectively do the same as the GhostScript invocation above, that is, explicitly write the page size.

[efalk]

Mac "sort of" has native postscript support. That is, if you open a .ps file, it converts it to a pdf file and then displays that. I half suspect that it's running ps2pdf under the hood. At any rate, the flaw shows up both ways, either by displaying the .ps file directly, or by running ps2pdf and then displaying the results.

Anyway, I have a working solution now, so thanks for your help.

[rrthomas]

By the way, I have made the release I referred to above.