Comment by csours

Once this category of error is raised to your attention, you start to notice it more and more.

A little piece of technology made sense in the original context, but then it got moved to a different context without realizing that move broke the contract. Specifically in this case a flying boat became an airplane.

---

I recently worked a bug that feels very similar:

A linux cups printer would not print to the selected tray, instead it always requested manual feed.

Ok. Try a bunch of command line options, same issue.

Ok. Make the selection directly in the PPD (postscript printer definition) file. Same issue.

Ok! Decompile the PXL file. Wrong tray is set in pxl file... why?

Check Debug2 log level for cups - Wrong MediaPosition is being sent to ghostscript (which compiles the printer options into the print job) by a cups filter... why?

Cups filter is translating the MediaPosition from the PPD file... because the philosophy of cups is to do what the user intended. The intention inferred from MediaPosition in the PPD file (postscript printer definition) is that the MediaPosition corresponds to the PWG (Printer Working Group) MediaPosition, NOT the vendor MediaPosition (or local equivalent - in this case MediaSource).

AHA!! My PPD file had been copied from a previous generation of server, from a time when that cups filter did NOT translate the MediaPosition, so the VENDOR MediaSource numbers were used. Historically, this makes sense. The vendor tray number is set in the vendor ppd file because cups didn't know how to translate that.

Fast forward to a new execution context, and cups filters have gotten better at translating user intention, now it's translating a number that doesn't need to be translated, and silently selecting the wrong tray.

TLDR; There is no such thing as a printer command, only printer suggestions.