gstoraster shifts image over a bit but pdftoraster is correct

[speachy]

I just ran into an odd problem. I'm trying to print a full-bleed image that is perfectly sized for the printer's imagable area. If I submit the job as an image (ie jpeg), the image prints correctly.

However, if I convert the image to a pdf first and submit that, the image is offset about 3-4mm from the left of the page, leaving a white visible margin.

When debugging I noticed that the filter flow was calling 'gstoraster' for the pdf conversion. On a whim, I disabled gstoraster (commenting out the entries in mime/cupsfilters-ghostscript.convs) so that pdftoraster would be used instead, and the image printed properly centered, with correct (ie zero) margins.

It is clear that the two pdf --> raster conversion paths are not in agreement, and it is my belief that gstoraster is incorrect.

I'm using cups-filters 1.22.5 on a Fedora 30 system. cups 2.2.11, ghostscript 9.26.

A quick scan of the changelogs show nothing noteworthy vs the current 1.24.2, but I can rebuild and retest with that if necessary. I can also supply scans of the failure I'm talking about.

[speachy]

Further info -- I'm submitting these images on the command line using 'lp', to a local queue. The printer in this specific instance is a USB-attached DNP DS620, driven by git master Gutenprint. I can also supply the PPD and source image (in jpeg and pdf form) that demonstrates the problem.

[tanmayanand44]

@speachy Can you share the PPD and the image for us to look upon. Probably, there is a margin offset bug in gstoraster.

[speachy]

files.zip

In the zip file are the PPD, and a source image in the original jpg, and converted to pdf. Note that these images have (symmetrical) borders, which makes it pretty easy to see if/how the image gets shifted.

I used PageSize=w432h648 Resolution=300dpi.

[speachy]

Here's a quick side-by-side comparison of what came out of the printer.

[tillkamppeter]

The paper size information in the PPD for the "w432h648" is as follows:

[...]
*PageSize w432h648/6x9:         "<</PageSize[460.800 657.600]/ImagingBBox null>>setpagedevice"
[...]
*PageRegion w432h648/6x9:       "<</PageSize[460.800 657.600]/ImagingBBox null>>setpagedevice"
[...]
*ImageableArea w432h648/6x9:    "9.120 0.000 451.680 657.600"
[...]
*PaperDimension w432h648/6x9:   "460.800 657.600"
[...]

From a paper size named "w432h648" or "6x9" I expect that it is 6 inches by 9 inches or 432 pt by 648 pt. Thebactual dimensions defined in the PPD file are bigger. Also strange is that there is only an unprintable border defined for the X dimension and not for the Y dimension (but the actually printable area is still bigger than the expected physical paper size of 432 pt by 648 pt).
Are these dimensions to achieve an overspray for borderless printing on all four edges of the sheet?
Could you provide a CUPS error_log (in debug mode) for both cases if you have achieved the shown pages by sending print jobs to CUPS? Or if you have used the cupsfilter command, could you provide the screen output for both cases?

[speachy]

(The above was printed using the 6x8"/432x576pt size, but the problem is more general)

The short answer is that, yes, these dimensions are needed to satisfy both the printer's raster data format requirements and "overspray" for full-bleed printing. The final image is "nominally" 432x576pt, but the printer has a native imageable area of 1844x2436px @300dpi (442.56x584.64pt) with a non-printable 38px/9.12pt margin on either side, resulting in (from the printer's perspective) a raster of 1920x2436px/460.80x584.64pt.

The results were achieved using CUPS (submitting the PDF on an lpr command line) but one way or another I'll get you the logs from each run.

Oh, I recall seeing similar problems when printing (again with Gutenprint) to a more traditional PCL5 laser, but I never bothered to dig into that one.

[tillkamppeter]

I have tested now with cupsfilter using a command line like this

cupsfilter -P DS620.ppd -m application/vnd.cups-raster -o PageSize=w432h648 -o Resolution=300dpi tile1.pdf > test.raster

and the files you supplied in the current directory. When I display the resulting file with rasterview I see the decentered output.
The screen output of the cupsfilter command shows the Ghostscript command line used and I tested running it separately.
At first, I generated the input PDF file for Ghostscript, the output of the pdftopdf filter. To get this output I run the cupsfilter command with application/vnd.cups-pdf as output format so that it stops after pdftopdf:

cupsfilter -P DS620.ppd -m application/vnd.cups-pdf -o PageSize=w432h648 -o Resolution=300dpi tile1.pdf > test.pdf

I have checked test.pdf displaying with evince and there is no decentering, so the decentering is actually occurring in the gstoraster step (otherwise the problem would also occur with the next step being done by the Poppler-based pdftoraster which was not the case).
So I run Ghostscript separately as follows:

cat test.pdf | PPD=DS620.ppd gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -r300x300 -dDEVICEWIDTHPOINTS=460 -dDEVICEHEIGHTPOINTS=657 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=1 -dcupsCompression=1 -scupsPageSizeName=w432h648 -I/usr/share/cups/fonts -c '<</.HWMargins[9.120000 0.000000 9.119995 0.000000] /Margins[0 0]>>setpagedevice' -f -_ > test.raster

Important is to set the PPD environment variable to the name of the PPD file as the cups output device reads it. This reproduces the problem, meaning that the bug is in Ghostscript.
Please report a bug to Ghostscript upstream with the Ghostscript command line shown here, and the test.pdf file and your PPD file attached. I have tested with Ghostscript 9.27 on Ubuntu Eoan.

[speachy]

Reported to upstream ghostscript at https://bugs.ghostscript.com/show_bug.cgi?id=701438

They seem to think it's a problem with how pstopdf invokes ghostscript, and suggested a different cmdline. See comment 5.

[tillkamppeter]

See my comment #6 on the Ghostscript bug report for more detailed info.
The printer driver used here reports a wider page size than the actual width of the paper but the correct page height. The original PDF is probably prepared for the actual paper width and so it does not exactly match the width of the page size advertised by the printer driver's PPD file. Ghostscript (called by gstoraster) aligns the PDF file to the left border of the page and so it gets decentered (perhaps pdftoraster centers it).
To get the printout with the driver as it is now, use the "-o fit-to-page", "-o fill", or "-o crop-to-fit" command line options or their equivalents in print dialogs, as these center (and optionally scale) the image on the page. GUI photo apps will probably scale the photo into the page width repoirted by the PPD file and print correctly.
The problem of the printer driver design is that the driver/PPD reports a wider page than the actual paper which can mislead users (and also GUI apps, for example when adding a border and on the left and on the rigfht half of the border do not get printed).

[speachy]

To echo what I put in the ghostscript ticket.

I didn't file this bug due to "application" or "user" confusion, I filed it because 'gstopdf' and 'pdftopdf' generate inconsistent results with the same input and (explicit) parameters.

[speachy]

The input image is perfectly filtted to the imageable area for the print size. The behavior with a non-PDF (ie raster) flow is already correct, and pdftopdf behaves consistently with that.

It's one thing to claim that gutenprint's decade-plus-old approach to non-printable paper margins is incorrect (I suspect this would come as a surprise to Robert Krawitz) but I don't think I'm being unreasonable in expecting consistent output no matter which pdf->pdf filter is used.

[speachy]

So far the solution presented is "rewrite your printer driver to reduce user confusion" -- but the user here was not confused by a PageSize that is larger than the ImageableArea. Instead, they were confused as to how this series of commands would yield different results:

]$ user_application input.jpg outimage.jpg # generates output perfectly fitting ImageableArea
]$ convert outimage.jpg -density 300 outimage.pdf # native resolution
#Time to print
]$ lpr -P printername -oPageSize=B7 outimage.jpg ## looks good, full bleed print
]$ lpr -P printername -oPageSize=B7 outimage.pdf ## image shifted left by several mm, no good

They were confused because that last command used to work. And that is how this was reported to me.

[tillkamppeter]

Now both gstoraster and pdftoraster should do the right thing. Both now support also matching the input page size against the imageable area of the PPD's page sizes (if none of the PPD's sizes matches with its full size) and matching is generally done with only 1% of tolerance. Your file comes out correctly now and I also have done some regression tests and all seems to work correctly now.
Fixes: pdftoraster by commit b226393, gstoraster (Ghostscript) in Ghostscript bug #701438.