Define tray to print from with a procedure

I have a requirement to define one of two available trays when printing. Both trays are letter size, one loaded with white paper and the other with pink paper. Note, this is different than printing an envelope vs letter size. The printer properly selects the envelope tray when I use printtopdf with the envelope dimensions, but in this case, both trays have the same paper size.

In Pan6, I’m able to change the printer setup by modifying the contents of the _PrintSettings variable for the form that I need to print.

I understand that PanX doesn’t have unique page setup settings for each form, but, is there such variable that keeps the universal page setup settings? Can I access it to extract the current printer settings and modify it on the fly?

Has anyone figured out a way to pick from two printer trays?

Really?!!?!?

I guess you must have figured that out by trial and error. FYI, that solution is only going to work with your specific brand of printer. The _PrintSettings is an opaque, undocumented data structure that Panorama knows nothing about. macOS gives Panorama the value and says “please save it for later and give it back to me the next time you print.” I believe that macOS itself doesn’t even know anything about the paper tray – that part is handled by the printer driver.

The old, “classic” version of MacOS (that Panorama 6 runs under) required each application to store the printer settings somewhere. Panorama 6 did that with the _PrintSettings variable. In OS X/macOS, the operating system handles this in the standard document format, so Panorama doesn’t need to keep it’s own _PrintSettings variable. There is no way to access the settings from within Panorama. However, the settings are saved with the database. If you right click on a Panorama database and choose Show Package Contents, you’ll see that it contains a file named printinfo.archive. This contains the printer settings. This file contains text, you can open it with BBEdit. I tried printing with a custom paper tray and saving the document. I have a Brother printer, it appears that the driver for that printer saves information in a binary format, there was a big blob of Base64 encoded data inside the printinfo.archive file.

Ok, I went one step further and used the Formula Wizard with the decodebase64( function to see what was inside this binary blob. It turns out to be more XML text. However, there was no mention of my paper tray selection in that XML. And in fact, I think this isn’t saved, because when I tried to print again, the Print dialog had no memory of my previous paper tray choice. So I think that it is not possible to save or control the tray selection at all, at least if you are using a Brother printer.


The current version of macOS has a documented API for specifying the most common print options, like page size and orientation, scale, and number of copies. In 2021 there are a lot of printers that support tray selection and two-sided printing. It would be very nice if Apple brought support for these features into the operating system itself (instead of leaving them completely up to individual printer drivers) and allowed applications to access and modify this information programmatically thru an API instead of only being accessible thru the Print dialog. However, I would not hold my breath waiting for this. My guess is that there isn’t even currently an Apple programmer with responsibility for the printing code. I don’t think there have been any changes in the printing API’s in over a decade, maybe 15 years. (In fact, I just checked, most of the printing API’s have not changed since OS X 10.0 in 2001, a couple changed in 2005 with 10.4 - ZERO changes since then. So probably no one at Apple has looked at this code in 16 years!) Apple probably thinks that printing is a dead end technology that no one uses any more.

Looking through Apple’s documentation, it does look like Duplex has some interface within their printing system: Apple Developer Documentation. What I cannot find is the method of accessing the printing presets. If we could just choose a preset, we could set up a preset with Tray 1 or Tray 2 and switch between them as necessary. It might be possible through the CUPS interface, but it has been a while since I fiddled with that.

It is frustrating that there are things that you know have to exist, but knowing how to find and access them is so difficult. I was talking to a neighbor in the coding business about how it seems that so much of modern programming is a few basic concepts and a big bag of magic tricks that you have to sift through to find what you want. At least Panorama has a Help system that tells you what is in the bag in one central place, although knowing which magic trick you want is still difficult.

I have disappointing news for you, the link you included is for UIKit, not AppKit. In other words, apparently iOS may have some sort of support for duplex, but this text does not apply to the Mac (except possibly for Catalyst apps). Here is the equivalent documentation page for the Mac:

As you can see, no mention of duplex. FYI, Panorama already uses the NSPrintInfo in various info( functions and the printtopdf statement. Believe me, I’ve extracted every documented morsel out of this API method.

I guess this underscores your point of how difficult it is to find information about APIs. I consider crafting good google searches to be a fundamental skill for programmers today. Usually you try one search, then that gives you an idea for another, then another, until hopefully you find what you’re looking for. But it’s not always a happy ending.

Ah, yes, the opacity of Apple documentation! As I said, the solution probably lies in the CUPS documentation and the workings of its interface, but the documentation is through CUPS, (localhost:631 plus enabling the interface) rather than Apple Developer. Sometimes you find yourself holding the wrong bag of tricks.

Thank you for your comments and Jim, thank you for your detailed testing. I see potential with the CUPS interface as Bruce points out, but at this moment, buying an inexpensive printer dedicated to color paper will be a cheaper option than spending the time to figure it out.

If I ever get to it and find a solution, I will reply to this post.

Why would you have to buy another printer? You would have to switch the printer driver each time you want to print on your color paper then. That is the same or even more effort than to check the correct printer option manually in the print dialog, isn’t it?

Here is an off-the-wall idea that may or may not work. Since the tray selection seems to depend upon the paper size selected, could you possibly set a just slightly smaller dimensioned custom paper size (8.375 x 10.875) for the colored paper when printing? Would that trigger the second tray? Just a stab in the dark.

With printtopdf this is easy, I just need to set the “Printer” option to the name of the printer that I need. For the most part, all of our applications are fully automated without dialogs.

Unfortunately no, as soon as I define any custom size, it defaults to tray 1, the envelope feeder, without any option to change the default tray for custom sizes other than that. It seems to be a limitation in the printer itself, and old HP 4000 TN.

Hugo, I posted a method to do what you are looking for just now in a separate post. ~ Scott

Thanks for sharing your solution Scott. It is good to have another option to make this work.

That being said, I found another solution, but never came back to update this post.

I few years ago I tried defining one of the trays with a slightly smaller paper size, like 8.4 x 11. This solution didn’t work in an old HP 4000 TN printer, but it works perfectly in a newer HP M605.

After defining the custom tray size, all you have to do is print your form specifying the modified size. It then automatically picks the correct alternative tray, like this:

printtopdf "","Printer","","Height",11,"Width",8.4

Unfortunately, this solution depends on the capabilities of your printer.