I wrote in Bug 693053, about -dMEDIAATTRS needing better documentation:

---
Ghostscript is supposed to be used with an InputAttributes dictionary (possibly set via setpagedevice at the beginning of the job, or other hardware mechanism if used in an embedded usage) which describes what are the available media, and what attributes they have, to know what media choices is available, and try to match that to media selection setpagedevice calls. In the absence of an InputAttributes dictionary, most media selection setpagedevice calls are dropped; this seems to be overriden by the -dMEDIAATTRS switch, which allows them to pass-through.
---

AFAIK the current behaviour of dropping most attributes dates backs at least to Raph Levien's time (and sort of make sense, as far as *not* blindly passing attributes downstream to devices which may not even have them) - and the -dMEDIAATTRS is really added to work-around that issue.

Basically *all* devices ignore input attributes, because say, a PCL/Epson printers (or something that's not even a printer!) may not have a postscript tray of media of any equivalent. It is only when users etc expects some postscript attributes are converted to their PCL/PXL equivalents, that becomes an issue, so cups added a work-around.

As far as I understand it.

I also stated in Bug 693053 :

...
AFAIK only two drivers do anything with the information, - pcl5 and pxl (for MediaPosition/tray selection), and may be one or two of the 3rd party drivers.
...

further background: bug 690376 and urls therein.

Also, Just notice the comments around line 170 and
commit 3b79a8091c9b30428c87399acf7a083666b4d171
about policy 7/impose is a bit wrong now, and needs updating according to how the code behaves.

I did look at this briefly using the InputAtrributes dictionary as prescribed in the documentation:

https://www.ghostscript.com/doc/current/Drivers.htm#Tray

The documented example does not set the media position without NOMEDIAATTRS either.  Perhaps there is more to setting up the device than is documented.

There are so many problems here that its difficult to know how to explain them all.

The first problem is that the supplied example files are *terrible* examples. They do not work properly even in PostScript. The code does this:

<</DeferredMediaSelection true /MediaPosition 0>>
  setpagedevice

There is no attempt to set the MediaSize or any other properties of the requested media, simply a statement to use the tray in MediaPosition 0. Take this file to a different PostScript printer, with a different tray setup, and the output *will* be incorrect. It might choose media which is too large, or too small. And that's assuming the printer even has more than one tray, if it doesn't it may well simply throw an error and refuse to print the program.

This rather neatly illustrates the point hinted at in comment #3, and the reason why the other vector devices (eg ps2write) make *NO* attempt to preserve the tray information. There is no good reason to expect that a particular combination of tray setup, in a PostScript program intended for printing to a specific PostScript printer, should then match the tray setup of some PCL/PXL printer. In fact I'd rather expect that, in the general case, they will *not* match, so preserving the tray selection is counter productive.

Henry did point out one possible reasonable use case, which is where the user *knows* the setup of the target printer, and wants to send PostScript on the command line to get the tray setup correct. There are problems with this; it requires some considerable PostScript knowledge to get the matching correct and the incoming PostScript program may contain its own media requests, which will override any requests on the command line. These problems can be solved, but its non-trivial.

This is demonstrated by Henry's inability to get media matching to work using an InputAttributes dictionary; this is because the media matching code falls into a 'this can't happen' case and gives up (see gs_setpd.ps, .computemediasize, at about line 321) because of the extremely limited (basically, bad) PostScript in the program.

I can solve this by changing the Policies dictionary for PageSize from 0 (exact matches only) to 3 (select and adjust). As described in drivers.htm, section 10 Tray Selection, this then properly sends a /%MediaSource key with the value of 1.

Which the pxlmono device completely ignores.

So that's problem number 2, the device doesn't implement the API as described in the documentation.

If I add code to process the /%MediaSource key to the pxlmono device, treating it as the MediaPosition key which it already processes, then I get 'correct' (ie tray set to 1) PXL output when I prepend the file with:

  currentpagedevice /InputAttributes get
  dup { pop 1 index exch null put } forall

  dup 0 << /PageSize [612 792] /MediaPosition 0 >> put
  1 << /PageSize [612 792] /MediaPosition 1 >> put
  <</Policies <</PageSize 3>> >> setpagedevice

Which clears the current InputAttributes, sets up an InputAttributes with two trays; 0 and 1 (for tray2.ps a third tray, 2, would be required as well) and then sets the /Policies /PageSize to 3 so that it will match the abbreviated setup in tray1.ps.

This is the correct way to deal with the problem as things stand today; the media matching will take the request from the PostScript program, use the InputAttributes description of the target device to select the best media, and then send that to the device.

We can't change the behaviour of -dNOMEDIAATTRS (much though I would like to) because the CUPS device relies on it. However, I don't believe that we should either encourage the use of this undocumented parameter, or document its behaviour (except possibly to note that its CUPS-specific and should not be used with a non-CUPS device).

Now as a final note; as I stated above getting all this media matching to work is, well, tricky. Simply preserving the tray position (as in using -dNOMEDIAATTRS) is a truly bad idea, because in general the tray in the PostScript program can't be assumed to be the correct tray in the target printer. The only real use case for this is where the user *knows* the tray they want to use. In which case there is no real reason to make them jump through the media matching hoops. It would be far simpler to define a new switch (eg PXL_TRAY_POSITION) which would write the required tray selection directly to the output, ignoring everything in the PostScript program.

Since I don't own the device, I'm going to leave this to Henry to decide what to do. IMO there are four options:

1) Do nothing, preserving the tray is a bad idea.

2) Document -dNOMEDIAATRS (again I think this is a bad idea, it will *only* work for PostScript program which include /MediaPosition and there is no way to be sure that the PostScript is even correct for the target printer). If we document the switch people will misunderstand it and use it inappropriately.

3) Add /%MediaSource processing to the pxlmono device, so that media matching in PostScript will work properly.

4) Add a new switch to do away with all this messing about and simply set the tray position directly.

We could do both 3 & 4, and have the command line switch override the PostScript if its present.

Created attachment 16846 [details]
modifications made to gdevpx.c for /%MediaSource

A diff of the changes I made to gdevpx.c to process the /%MediaSource key. Note this still processes /MediaPosition, in case the CUPS device is using it in conjunction with -dNOMEDIAATRS.

Henry pointed out on IRC (1-1-2019 at around 15:55) that "preserving" the tray selection in the PXL output actually does entirely the wrong thing.

Preserving 'MediaPosition 1' results in the tray selection in PXL becoming value 1, "auto select" while preserving MediaPosition 2 would result in the tray selection becoming "Manual feed". Clearly these are not equivalent, which rather reinforces the point about passing PostScript media selection to the PXL output being counter-productive.

Re-assigning this one to Henry to decide what (if anything) to do about this.