Created attachment 19986 [details] TestData 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 ### occurs * 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): %PDF-1.3 %¿÷¢þ % This file was generated by pdftopdf %%PDFTOPDFNumCopies : 1 %%PDFTOPDFCollate : false 1 0 obj << /Pages 3 0 R /Type /Catalog >> endobj 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 and 3. Ghostscript also shows the same (with a warning that there is data before the %PDF-) 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: %PDF-1.7 %Çì¢ %%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: 40d306bf6707c365996eb1d41782ca3f063311d0 should resolve the problem.