Created attachment 19986 [details]
When print a file created with pdf2ps command with a PDF driver, the image shifts to the upper right as the number of pages increases.
## Steps to reproduce the behavior
1. Add "Generic PDF Driver" on Cups
2. Print "Data.zip\NG-create at Ubuntu2004\Test3Page - Created by pdf2ps.ps"
## Expected behavior
Print out like a PS file preview
## Actual behavior
As the number of pages increases, the image moves out to the upper right
## General information
* print "ps file created on Ubuntu 16.04 (GS 9.26) or later" on Ubuntu 16.04 (GS 9.26) or later
### does NOT occur on Ubuntu 14.04 (GS 9.10) or earlier
* print "ps file created on Ubuntu 16.04 or later" on Ubuntu 14.04 or earlier
* print "ps file created on Ubuntu 14.04 or earlier" on Ubuntu 16.04 or later
the files attached don't seem to correspond with the Ghostscript versions
from the bug report.
Examination of the 'NG' prn file shows (after the PJL header):
% This file was generated by pdftopdf
%%PDFTOPDFNumCopies : 1
%%PDFTOPDFCollate : false
1 0 obj
<< /Pages 3 0 R /Type /Catalog >>
2 0 obj
<< /CreationDate (D:20201014095015+09'00') /Creator (GPL Ghostscript 950 \(ps2write\)) /ModDate (D:20201014095015+09'00') /Producer (GPL Ghostscript 9.50) >>
When I open the 'NG' prn file with Acrobat, it shows the pages shifted for 2
Ghostscript also shows the same (with a warning that there is data before the
However, when I use the following (with Ghostscript 9.50):
gs9.50/bin/gsw -sDEVICE=pdfwrite -o z.pdf Test3Page-OriginalPDF
the output file is correct, doesn't have the PJL header, and starts with:
%%Invocation: path/gs -sDEVICE=pdfwrite -sOutputFile=? ?
The NG prn file being used as input to Ghostscript is the problem, which seems
to be created by 'pdf2pdf' -- not Ghostscript. If Ghostscript is used with
pdfwrite on the original input file, the PDF file produced is a lot different
and doesn't have the problem.
Please refer this to the 'pdf2pdf' maintainers.
There is, unfortunately, insufficient information here to reproduce the problem. The key missing piece of information was supplied independently by a Ghostscript user on the #ghostscript IRC channel.
In order to reproduce the problem the PostScript interpreter must have a current device dictionary which includes the key /.HWMargins and the array values must be non-zero.
Since /.HWMargins is Ghostscript-specific this suggests that the reporter is taking the output of ps2write and running it back to a Ghostscript device, I have no idea why.
**If** this is the case then this commit:
should resolve the problem.