Raster filter crops to ImageableArea, PDF filter fills blank to PaperDimension

[ValdikSS]

Describe the bug

I'm trying to print A4 page without borders, printer filter accepts cups-raster.
My printer is unable to print the top 4mm of the page, but otherwise prints the whole page without borders from left, right, and bottom.

To make print-scaling=fit skip the first 4mm of the page to print any A4 document to the whole imageable area, I've added the following to PPD generator:

// left bottom right top
HWMargins 0 0 0 4mm

pdftopdf (first filter when printing PDF) works as expected: it scales the content and fill the top with the blank space, preserving w×h and aspect ratio.

gstoraster (second filter), however, also processed the data, and instead of fitting the page by adding blank space on the top of the document, crops the document from the top (resulting in lower height, lower pixel count, different aspect ratio, non 210 × 297mm A4 document).

Example

Original document (A4 210 × 297mm, PDF):

Here how it looks with HWMargins 0 0 0 25mm

cupsfilter … -m application/vnd.cups-*pdf* … -o print-scaling=fit input.pdf
resulting in proper A4 (210 × 297 mm) document with the blank space on top, this is exactly what I'm trying to achieve.

But
cupsfilter … -m application/vnd.cups-*raster* … -o print-scaling=fit input.pdf
resulting in 4961 × 6425 pixel cups-raster data (210mm × 271 mm, not A4), with the top blank space cut out.

Filter prints the document from top to bottom, which results in cropped 4mm from the top due to hardware limitation, with borders from left and right and large border from the bottom.

I also tried to use PNG image as input, which uses only imagetoraster / imagetopdf.
imagetopdf has exactly the same result, however imagetoraster also crops width as well, resulting in 4546×6425 pixel image (192 mm × 271 mm).

Data

Here's all the files:

hwmargin-issue.zip

Is my understanding of HWMargins / ImageableArea incorrect? How can I achieve 4mm padding for my raster printer?

Software

• cups-filters-2.0.1-12.fc43.x86_64
• libcupsfilters-2.1.1-5.fc43.x86_64

The same result on 1.x cups-filters.

[tillkamppeter]

@ValdikSS Thank you for the detailed bug report.

The different formats should work as following:

PDF or PostScript output (like of pdftopdf for example): The output page has the size of the paper to be printed on. If the content is scaled down due to unprintable margins (print-scaling=fit), the content is positioned appropriately on the page and there are white margins around it. So what you have told what pdftopdf is doing for you is correct.

CUPS Raster delivers only the pixels which get actually printed. Page size, margins, resolution, pixel counts are in the metadata (header) of each page. The page's raster data is only the printable area. There is no padding for the unprintable margins. So for your page the bitmap has the width of the page printed on (210 mm) and the height of the page minus the unprintable margin at the top (297 mm - 4 mm = 293 mm). So what you have observed for CUPS Raster is correct. CUPS Raster is usually fed into a rasterto... driver filter. Note that the driver filter has to do the "right thing" here so that the content appears correctly on the page. If you get a wrong result out of the printer, the bug is in the driver filter.

PWG Raster and Apple Raster (URF) deliver pixels for the whole sheet, so the width of the bitmap is 210 mm and the height 297 mm. The top part of your page is padded with white pixels if needed. When the printer prints the page it discards the pixels which fall into unprintable margins. PWG/Apple Raster is usually fed into a driverless IPP printer.

In the print workflow usually the document goes through the pdftopdf filter (except when input is image, then imagetoraster or imagetopdf is used). The usual workflow for Raster output (either CUPS Raster to feed into driver or PWG/Apple Raster to feed into a driverless printer) is that first, the pdftopdf filter applies the print-scaling and number-up attributes. and puts the content in the correct size onto the correct place of the output page. Then a ...toraster filter rasterizes the PDF. It does not scale or move the content. It either makes a bitmap/raster data of the whole page, including white margins for PWG/Apple Raster or it makes a bitmap/raster data of only the printable area for CUPS Raster. The full page geometry is always put into the metadata/header of the Raster page.

This means that you should not apply a ...toraster filter directly to an input PDF file, the one which comes from the application or ehich you supply on the lp command line. The ...toraster filter only makes sense if run after pdftopdf.

For PNG image input you say "imagetopdf has exactly the same result"? What do you mean with that? The same as pdftopdf for PDF input, so meaning that you got correct output?

The imagetoraster also shrinking width seems not to be correct though. This seems to be actually a bug.

So all in all, we have a bug in imagetoraster and perhaps also in the rasterto... driver filter which is used for your printer. All the other output seems to be correct.

[ValdikSS]

Thanks Till!

For PNG image input you say "imagetopdf has exactly the same result"? What do you mean with that? The same as pdftopdf for PDF input, so meaning that you got correct output?

PNG → imagetopdf produces the same result as PDF → pdftopdf (210 × 297 mm document with the blank space on top).
PNG → imagetoraster produces result similar to gstoraster (cropped from the top), but also additionally cropped from the left and right.

PDF → pdftopdf → gstoraster
4961 × 6425 px, borders from left and right

PNG → imagetoraster
4546 × 6425 px, no left/right borders

also in the rasterto... driver filter which is used for your printer.

Yes, the filter needs to handle margins, I didn't know that.
For anyone who will read this ticket somewhere in the future, the filter needs to get the margin by reading cups raster header data: cupsPageSize and cupsImagingBBox.
https://www.cups.org/doc/spec-raster.html#:~:text=Single%20Precision%20(4)-,cupsimagingbbox,-Four%20floating%20point

cupsPageSize is a (physical) page size in (float) points, cupsImagingBBox is where the raster data positioned on this page, also in (float) points

[ValdikSS]

So, @tillkamppeter, should imagetoraster and gstoraster produce identical raster data, and the screenshots in my latest post seem like a bug?
If so, please just rename this issue then.