Client software inconsistency in `media`/`PageSize`

[ValdikSS]

Describe the bug

In short, I'm unable to reliably print Envelope DL (E65) page size from Linux when the printer is shared from another CUPS server.

This is a combination of three issues:

1. The client software does not always use Adobe standard PageSize names
2. The client software sends media=iso_…, media=NAME, PageSize=NAME, or both
3. If PPD on the print server does not use Adobe names, and the clients sends PageSize only, no mapping between IPP PageSize and PPD PageSize is applied (the mapping is applied only for media attributes).

I have:

• Desktop: Fedora 42 (cups 2.4.14)
  • both drvless and ippeve local generated .ppd files have PageSize = EnvDL for both printers
• Print server: Debian 12 (cups 2.4.2 + multiple patches backported, incl. b2a002a and b46fac8)
  • Samsung SCX-4200, splix, accepts cups-raster
  • Canon LBP1120, proprietary driver, accepts postscript
  • pdftops = poppler

Program	PPD Envelope DL name on print server	Sends in Create-Job	Result	Info
Chromium, drvless	DL (splix Samsung SCX-4200)	PageSize = EnvDL	A4 page printed	gstoraster: -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -scupsPageSizeName=A4
Chromium, drvless	dl_envelope (Canon LBP-1120)	PageSize = EnvDL	A4 page printed	pdftops: Page = 595x842; 14,14 to 581,828
Firefox, drvless	DL (splix Samsung SCX-4200)	media = iso_dl_110x220mm, PageSize = EnvDL	DL page printed	gstoraster: -dDEVICEWIDTHPOINTS=312 -dDEVICEHEIGHTPOINTS=624 -scupsPageSizeName=DL
Firefox, drvless	dl_envelope (Canon LBP-1120)	media = iso_dl_110x220mm, PageSize = EnvDL	DL page printed	pdftops: Page = 312x624; 28,28 to 284,596
Firefox, ippeve	DL (splix Samsung SCX-4200)	media = iso_dl_110x220mm, PageSize = EnvDL	DL page printed	gstoraster: -dDEVICEWIDTHPOINTS=312 -dDEVICEHEIGHTPOINTS=624 -scupsPageSizeName=DL
Firefox, ippeve	dl_envelope (Canon LBP-1120)	media = iso_dl_110x220mm, PageSize = EnvDL	DL page printed	pdftops: Page = 312x624; 28,28 to 284,596
Okular 25.08.0, drvless	DL (splix Samsung SCX-4200)	media = DL	DL page printed	gstoraster: -dDEVICEWIDTHPOINTS=312 -dDEVICEHEIGHTPOINTS=624 -scupsPageSizeName=DL
Okular 25.08.0, drvless	dl_envelope (Canon LBP-1120)	media = DL	A4 page printed	pdftops: Page = 595x842; 14,14 to 581,828
Okular 25.08.0, ippeve	DL (splix Samsung SCX-4200)	media = DL	DL page printed	gstoraster: -dDEVICEWIDTHPOINTS=312 -dDEVICEHEIGHTPOINTS=624 -scupsPageSizeName=DL
Okular 25.08.0, ippeve	dl_envelope (Canon LBP-1120)	media = DL	A4 page printed	pdftops: Page = 595x842; 14,14 to 581,828
Document Viewer 48.1, drvless	DL (splix Samsung SCX-4200)	PageSize = EnvDL	A4 page printed	gstoraster: -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -scupsPageSizeName=A4
Document Viewer 48.1, drvless	dl_envelope (Canon LBP-1120)	PageSize = EnvDL	A4 page printed	pdftops: Page = 595x842; 14,14 to 581,828
Document Viewer 48.1, ippeve	DL (splix Samsung SCX-4200)	PageSize = EnvDL	A4 page printed	gstoraster: -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -scupsPageSizeName=A4
Document Viewer 48.1, ippeve	dl_envelope (Canon LBP-1120)	PageSize = EnvDL	A4 page printed	pdftops: Page = 595x842; 14,14 to 581,828

All in all,

• Chromium and Document Viewer send only Adobe PageSize, which is different from the PPD PageSize and not getting mapped by ppd-cache
• Okular sends non-Adobe media, and by mere coincidence it is mapped to non-Adobe DL for Samsung PPD (hard-coded in core/fileprinter.cpp)
• Firefox uses proper media and Adobe PageSize, which is correctly handled thanks to b2a002a and b46fac8

Who is to blame here, what should be done and where to start? There's a code which treats media and PageSize differently (and a special case when both are present in raster handling, which is now skipped due to these two mentioned commits), I assume we can't just treat both equally?

[ValdikSS]

.ppd files and ipp jobs (c files)

Archive.zip

[ValdikSS]

Android, Mopria Print:

Both printers produce DL.
media-col = {media-source=auto media-type=plain media-size={x-dimension=11000 y-dimension=22000}}

Windows

Both printers produce DL.
Tested with Chrome, Firefox, Acrobat Reader
media-col = {media-size={x-dimension=11000 y-dimension=22000} media-type=stationery-recycled}

[ValdikSS]

macOS 15

Both printers produce DL.

com.apple.print.PageToPaperMappingMediaName = Letter
media = EnvDL
PageSize = EnvDL

[ValdikSS]

CUPS doesn't generate media when printing to other CUPS servers: it is detected by the presence of cups-version IPP option.

cups/backend/ipp.c

Lines 1313 to 1325 in 930966f

	if (!cups_version && media_col_sup)
	{
	/*
	* Load the PPD file and generate PWG attribute mapping information...
	*/
	ppd_attr_t *mandatory; /* cupsMandatory value */
	ppd = ppdOpenFile(getenv("PPD"));
	pc = _ppdCacheCreateWithPPD(NULL, ppd);
	ppdMarkDefaults(ppd);
	cupsMarkOptions(ppd, num_options, options);

This code was added >15 years ago, way before AirPrint/Mopria/IPP Everywhere. I assume it was supposed to be used with PPD files in sync on all the clients, and does not work with PPD generators like driverless or ippeve.

Forcing no-cups-version code results in media-col IPP attribute only (no PageSize), which is good. However printing from Okular results in no media/PageSize whatsoever—it's printing default A4, but Okular is broken anyway (created a MR: https://invent.kde.org/graphics/okular/-/merge_requests/1242)

For now I made a workaround on the server side to map PageSize to ppd-cached value.

@michaelrsweet @zdohnal @tillkamppeter any comments welcome.

[michaelrsweet]

OK, well the local cupsd should be adding the (default) media size if none is supplied by the application, which then gets passed on to the remote cupsd.

Having "media-type" be "plain" (not a standard type) or "stationery-recycled" seems odd when it should be one of the "envelope" media types, but whatever...

[HinTak]

Yes, I remember custom paper size and envelopes used to work 15 to 20 years ago. HELLO @michaelrsweet btw.