ipptransform doesn't use or preserve the input document media size for the output media size if no size is specified

[wifiprintguy]

Describe the bug
ipptransform doesn't use or preserve the input document media size for the output media size if no size is specified. When I gave ipptransform a PDF document with US Letter pages, it converts all pages to A4 unless I overtly specified the output media size using the ' -o "media=na_letter_8.5x11in" ' option.

To Reproduce
Steps to reproduce the behavior:

1. Build libcups
2. Run ipptransform on onepage-letter.pdf to produce another PDF, with no media size specified:
   ./tools/ipptransform -i application/pdf -m application/pdf examples/onepage-letter.pdf > onepage-letter-no-media-specified.pdf
3. Run ipptransform on onepage-letter.pdf to produce another PDF, with US Letter media size specified:
   ./tools/ipptransform -i application/pdf -m application/pdf -o "media=na_letter_8.5x11in" examples/onepage-letter.pdf > onepage-letter-usletter-media-specified.pdf

Expected behavior
Both files produced by ipptransform would contain the same content and page sizes.

Actual Behavior
The pages in the onepage-letter-no-media-specified.pdf file are rendered to A4 which is unexpected.

Screenshots
n/a

System Information:
System 1:
macOS 15.3.1
ippsample 94d1b3eeb6175f9a4182b38809750fb4a454e359
libcups 4a2e536

System 2:
Ubuntu 24.02
ippsample 94d1b3eeb6175f9a4182b38809750fb4a454e359
libcups 4a2e536

Additional context
Add any other context about the problem here.

[michaelrsweet]

It is probably using the "media-default" value... Probably need to have a flag to indicate whether "media" or "media-col" was explicitly specified and then only scale as needed (media specified or page size not supported by printer)

[attah]

So.. does this mean throwing out creating uniformly sized pages as default? That doesn't sound very good...
As i'm sure you are well aware, PDF doesn't have a "document media size", so following the document strictly speaking isn't a thing.

[michaelrsweet]

@attah PDF actually does have a "document media size" (the MediaBox value in the Pages object), which can be overridden in the page tree for groups or single pages. If a page object doesn't have a MediaBox value then you look to the parent objects to find a value. The same goes for the ArtBox, BleedBox, CropBox, and TrimBox values.

The issue with ipptransform is that it may not have the list of supported sizes for the destination, so it has to use the explicit or default as a fallback. If we just provide the size from the PDF then you could end up with an unprintable mess...

[attah]

Hmm... whilst i had not picked up on that concept, the way i read the spec, the Pages object is not required to have one as long as all Page objects below have their own. So the document cannot be trusted to have one, let alone a sane or usable one.

Anyway, i completely agree on the issue statement. My thinking is that the locale etc can be expected to give a likely-to-be-printable fallback paper size (e.g. through libpaper).
(I had basically the same "bug" reported against my little hobby utilities, but with not running the world i'm happy to keep the fallback being A4 - not knowing the printer attributes is a corner case anyway).

[michaelrsweet]

@attah The key is that every Page node needs to have or inherit a MediaBox value.

As for relying on the locale (or libpaper), historically we have done so in cupsd but it has always been a guess and we are better off using the printer's default/supported/ready values to map a PDF page's MediaBox to a size the printer will/can support.

[attah]

And that was my point; no one page size from a document is necessarily more correct [for the whole document] than any other - as they can all be different. From this follows that it is impossible to "follow the document" in a way that will always work.

I completely agree it is best to follow the printer whenever possible - but i understood the issue to be what to do when there is no printer in the picture.