psnup not honouring page size?

[jgclark]

From #57 I'm testing private release of 3.09 at your request. Waiting for a fix to the underlying PDF library, I'm going via PS before converting back to PDF. You can test with the same test file I supplied in #57.

I found:

• psbook test.ps testbook.ps is fine
• psnup -2 testbook.ps testnup.ps stage is clipping the text from the previous stage. In more detail the 'top edge' is clipped, and as far as I can see its writing more to 'US letter' size than A4.
• this is even when I try it with psnup -2 -p a4 testbook.ps testnup.ps or psnup -2 -P a4 testbook.ps testnup.ps or psnup -2 -p A4 -P a4 testbook.ps testnup.ps.

I confirm the original testbook.ps appears to be A4 dimensions.

Incidentally, psbook seems to be detecting and keeping A4 size, but psnup seems not to be ... and I've not got as far as pstops to try that out.

[rrthomas]

I can't reproduce this problem. I have been testing with https://github.com/rrthomas/psutils/files/12389190/test.pdf and the latest git version of pspdfutils.

For me, paper says my default paper size is A4.

I'm also using GhostScript 9.55, and pdftops 22.02.0, and viewing documents with Evince 42.3, all as supplied with Ubuntu 22.04.

I observe the following:

• test.pdf is A4 portrait.
• I run pdf2ps test.pdf test.ps, and the resultant test.ps is A4 according to its BoundingBox. However, currently psutils can only read the size of a PostScript document from its explicit DocumentMedia, and there isn't one.
• I run psbook test.ps testbook.ps, and the result is A4, again according to its BoundingBox. psbook does not change the page size, it only rearranges the pages.
• I run psnup -2 testbook.ps testnup.ps. The output looks fine. The DocumentMedia has been set by psnup, which always explicitly sets the output page size.

So far, no problem. The obvious thing to try is changing my default paper size:

$ export PAPERSIZE=letter
$ paper
Letter: 8.5x11 in

Now I try the conversions again.

• I run pdf2ps test.pdf test.ps, and the result is A4 as before. No surprise here, changing my default paper size shouldn't affect this conversion.
• I run psbook test.ps testbook.ps. The result is identical to before, as expected: psbook does not explicitly change the paper size.
• I run psnup -2 testbook.ps testnup.ps. The output is US Letter, as I would expect: I didn't specify an output size, so psnup uses my default paper size. The text is clipped at the top, as you found.

So, what if my default paper size is US Letter (and I don't want to change it), but I want to work with an A4 document?

The --help for psnup says:

The output page size defaults to the input page size; if that is not
given, the default given by the `paper' command is used.

The input page size defaults to the output page size.

So, if we only give the input page size, the output will be taken as the same, and vice versa. Therefore, specifying either -p A4 or -P A4 should have the same effect.

• I run psnup -2 -p A4 testbook.ps testnup-outa4.ps and psnup -2 -p A4 testbook.ps testnup-ina4.ps. They produce identical results, both A4, and also identical to the results I obtained above. (Note: when I say "identical", I mean the files are character-by-character identical, with the exception of the CreationDate header field.)

So, I can't reproduce your problem, and PSUtils seems to be working as designed: it uses the user's default paper size when no explicit paper size is given and it can't find one in the file; otherwise, it respects the explicitly-provided paper size.

[jgclark]

Thanks for the details, and pointers to see in more detail what's going on.
paper says "A4: 210x297 mm"
The output of psbook remains A4.
The output of psnup is 216x279mm = US Letter, I believe.
So psnup -2 with any of the various specification of A4 size (including just relying on paper), results in A4 → Letter.
This is, AFAICT, not what the manual says.
What happens when you try setting default to A4 and then trying it?

[rrthomas]

paper says "A4: 210x297 mm"

Then your default size is A4. This matches my first case above.

The output of psnup is 216x279mm = US Letter, I believe.

Yes, that's US Letter. As I showed above, I get this result only when a) my paper size is set to US Letter and b) I don't give psnup a paper size.

So psnup -2 with any of the various specification of A4 size (including just relying on paper), results in A4 → Letter. This is, AFAICT, not what the manual says.

I can't reproduce this. Sorry, but without a way to reproduce it, I can't find a bug, if there is one. As I showed above, for me the program behaves exactly as documented.

What happens when you try setting default to A4 and then trying it?

It works fine, as I showed above.

[jgclark]

I also write and maintain open source software in my free time, so I know what this unsatisfactory situation is like.
Something must be different: perhaps my attempt to install this latest test version weren't successful.
So I've double checked what version I'm running.

• After pip install ..., psnup -v says 3.0.9.
• Then downloaded from git and ran python -m build. No errors that I could see (apart from "warning: no files found matching 'psjoin-include.man'")
• PYTHONPATH=. python -m psutils.command.psnup -v says 3.1.1.
• psnup -v continues to say 3.0.9
  So: AFAICT I've done everything the README says. What else do I need to do to install it properly on my system? (I know Unix but not python.)

I tried again with the long form of the commands:

• PYTHONPATH=. python -m psutils.command.psnup -2 -p A4 -P A4 testbook.ps testnup.ps which again produces US Letter not A4.
  So: what else might be different between our environments? As you can see, I'm still very keen to use your utilities.

[rrthomas]

Thanks for noticing the warning about psjoin-include.man, I've fixed that (it should cause an error IMO, but apparently not; it's harmless, anyway).

As to which version you're running, there's no need to install your development version (you can run it using the PYTHONPATH… incantation, as you are), but if you want to, you can with pip install .. The README doesn't cover this, or a host of other possible things one might want to do, which are best left to the documentation of the relevant tools.

The only thing I can think of is that for some reason PSUtils is not getting the same result from paper as you are at your shell. If in your git checkout you edit psutils/libpaper.py, and add the following lines:

        import sys
        print(f'paper: for {cmd} output was {out.rstrip()}', file=sys.stderr)

before return out.rstrip() in the paper function, then you'll get the output from every invocation of paper printed to stderr. In particular, I get a line like this:

paper: for ['paper', '--no-size'] output was A4

which shows what PSUtils gets as the default paper size.

[rrthomas]

By the way, there are signs of activity on the pypdf bug, so hopefully there will soon be a fix, and you can go back to working directly with PDFs the page size of which can be reliably read and set!

[rrthomas]

@jgclark if you're able to follow my debugging suggestion above, please let me know. If not, if you could attach input and output files, and the exact command you run, I can at least verify that we don't get the same result, and perhaps get a more precise idea of where the problem might lie (almost certainly, it seems to me, in the interface between PSUtils and libpaper). In particular, as it goes wrong for you when you specify both input and output paper size, perhaps psnup is not getting the correct information from libpaper (or indeed any information) but is ignoring an error.

[jgclark]

Just to say I'm not ignoring this, but I can't get to it until the weekend.

[rrthomas]

Version 3.3.0 fixes a bug which seems as though it could have caused your problem. I doubt it, as I couldn't reproduce your problem with the previous version of PSUtils, but you never know! In any case, please do any further testing with the latest release, or git main HEAD.

[rrthomas]

In any case, 3.3.0 also fixes the bug that meant you had to use PostScript in the first place, so you may not want to pursue this issue any longer, in which case please close it!

[jgclark]

Not wishing to pursue further :-)