tray
tray copied to clipboard
HP, Ricoh Printers show Paper Types with Printer Trays
With certain HP printer drivers (e.g. 'HP Universal Printing PCL 6 driver'), the Paper Types and Printer Trays are combined in QZ Tray.
Please see the following screenshot where Matte paper is listing in the trays area.

Filed bug upstream with an OpenJDK support provider as QZ-7
. I have a strong feeling that this is a bug with the driver implementation, however the fact that the Device Settings tab is correct leads me to believe that it's possible to filter these.
What's even stranger is that for the offending printers, the correct tray names all come back with a space before hand. 🤔
What's even stranger is that for the offending printers, the correct tray names all come back with a space before hand. :thinking:
So it turns out the Ricoh PCL 6 drivers also report the paper type when trays are requested, but no leading whitespace to the actual Trays like HP.
Public discussion posted here: https://stackoverflow.com/questions/71446909/why-does-getsupportedattributevalues-return-paper-types
Our OpenJDK support provider replied with the following information:
To narrow the problem I copied the code which retrieves media ids/names and media tray ids/names from OpenJDK jdk/WPrinterJob.cpp at 3e393047e12147a81e2899784b943923fc34da8e · openjdk/jdk to a
printer_info.cpp
file:
printer_info.cpp.zip
To compile and run the printer_info.cpp file I use Mingw-w64 from MSYS2 Compile:g++ -o printer_info.exe printer_info.cpp /c/Windows/System32/winspool.drv
The program queries the name of the default printer and uses the predefined printer port
#define DEFAULT_PORT "LPT1:"
The program uses
DeviceCapabilities
to print:
- all media ids:
DeviceCapabilities(printerName, printerPort, DC_PAPERS, buf, NULL)
- all media names:
DeviceCapabilities(printerName, printerPort, DC_PAPERNAMES, buf, NULL)
- media tray ids:
DeviceCapabilities(printerName, printerPort, DC_BINS, buf, NULL)
- media tray names:
DeviceCapabilities(printerName, printerPort, DC_BINNAMES, buf, NULL)
The output [looks identical to what Java reports).
So, the issue appears to be driver related. They recommend reaching out to HP and Ricoh to report this issue however we do not believe that would yield any timely results, so instead we've asked the OpenJDK support provider to assist us with filtering out the erroneous data using alternate APIs.
With the help of our JDK support provider, we've found that Ricoh and HP seem to reliably use media tray IDs > 1,000 for bad values.
If we can get the underlying tray ID (e.g. using the JDK or using JNA) we can filter these.
Quoting our latest reply to the (private) bug report:
False-negatives with evaluation:
[ 5] bin id: 1000, is paper tray: false, name: 'LCT' [ 0] bin id: 1025, is paper tray: false, name: ‘Auto Tray Select' [ 1] bin id: 7165, is paper tray: false, name: 'Automatically Select' [ 2] bin id: 7151, is paper tray: false, name: 'Tray 5 (Bypass)' [ 3] bin id: 7153, is paper tray: false, name: 'Tray 1' [ 4] bin id: 7154, is paper tray: false, name: 'Tray 2' [ 5] bin id: 7155, is paper tray: false, name: 'Tray 3' [ 6] bin id: 7156, is paper tray: false, name: 'Tray 4' [ 7] bin id: 7158, is paper tray: false, name: 'Tray 6 (High Capacity)'
7xxx
is Xerox. The PCL6 driver probably doesn't have the same bug, we can pattern match these out.1000
is Konica. The driver does NOT mention PCL6 and driver probably doesn’t have the samem bug. We can pattern match these out.1025
is Ricoh, but it is using PCL5, NOT PCL6 which driver probably doesn't have the same bug. We can pattern match these out.So far only HP and Ricoh using PCL6 seem to have this bug. If this is the case, I can filter these trays out for these two pattern match combinations.
Unfortunately we found some exceptions to the printer tray IDs, so th workaround provided in #947 won't work, we'll need to find another way to do this. The code will remain on the PR, but the PR will be closed and the branch will be deleted.
It's very unfortunate that the drivers misrepresent the trays this way, but at time of writing this, I believe we're at the mercy of the driver manufacturers. If another solution is found to filter these out, we'll happily reopen.