If you tried testing for the presence of ``colorimage'', your application will fail on PostScript level 2 printers. Several applications make this mistake, simply testing for the presence of a color operator (``colorimage'', ``setcmykcolor'', etc.). This is not sufficient - some level 1 PostScript black and white devices and all level 2 devices include the color operators.
However, before you do this, you should ask yourself *why* you want to know. There are really two reasons an application might care about the color capabilities of a printer.
1. To determine if the printer will accept PostScript language programs using the color extensions (colorimage, setcmykcolor, etc.)
2. To determine if the printer, as currently configured, will actually produce color output. This is what processcolors tells you.
These are entirely different questions, and developers should make sure they are asking the right one. (1) is a language compatibility question, similar to the issue of Level 1 versus Level 2 (see red book, appendices A and D). (2) is a device dependent query, which is essentially independent of (1).
In particular, it makes sense to ask (2) only if the application intends to take different actions depending on the outcome. For example, a CAD application might paint objects with stipple patterns on a monochrome device but true color on a color device. Or a prepress application might want to query and/or change the many Level 2 page device parameters dealing with production of separations (see PostScript Language Supplement for version 2012 or greater).
On the other hand, if an application is not going to do such things, it should ask only question (1). If the printer will accept the color extensions, the application should sent it color output, whether or not the printer will actually produce color. That way, the PostScript language file captures the application's intent, and color will be produced if the file is later diverted to a color printer.
Some times it's sensible to make such a test, though. For example, an application might want to display red and green on a color device, but a varying fill pattern on a black and white device since red and green are difficult to distinguish when rendered as gray.
In ``statusdict'', the ``processcolors'' operator, if present, returns the number of device colors. Black and white level 2 devices I have tested (TI microLaser Turbo, Apple LaserWriter IIg) omit ``processcolors''. Level 2 Color devices (such as the Tektronix Phaser III PXi) include it, and it returns the number of device colors.
So, on both level 1 and level 2, the correct technique is to test for the presence of ``processcolors'' in ``statusdict'' and assume black and white if it is not present. If it is present, execute it and test the result for a ``1'', indicating black and white.
% returns true for black & white, false otherwise
/black-and-white-device
{ statusdict begin
/processcolors where
{ pop processcolors } { 1 } ifelse
end
1 eq
} def