ICC color technology operates on-host: the conversion of color from an ICC source profile to an ICC destination profile occurs (either implicitly or under the control of the user) in the applications (application-level) or in the printer driver (driver-level).

PCM, on the other hand, does not support ICC profiles and operates in-rip, that is, inside the PostScript Level 3 printer: the color conversion from CSA to CRD occurs under the control of the rip (whose parameters can be set by the user if necessary). Insertion of CSA and perhaps CRD in the print stream may take place from the PostScript printer driver onward.

The ICC and PCM technologies can only meet in the PostScript print driver, that is, in the moment when the on-host management of the image finishes and in-rip begins.

Nonetheless, PCM and ICC are not separate and uncommunicating worlds. A CSA and the source part (from device to PCS) of an ICC profile essentially contain the same data, likewise a CRD and the destination part (from PCS to device) of an ICC profile. Thus, the transformation of an ICC device profile into a CSA or CRD and vice versa is simple to do without losing information, using mathematical formulae. (But a device linking profile does not have an equivalent in PostScript, since the links in PostScript are constructed during runtime.)

ColorSync includes functions to convert a device profile into a CSA or CRD, even during PostScript printing, using LaserWriter or AdobePS. But support is lacking in the majority of applications.

From the point of view of workflow philosophy, the idea of PostScript Color Management is attractive because it leaves the task of conversion to the rip, at the moment of printing. In this way the workload is more evenly distributed and the computer is less overloaded.

One thing to be said in favor of PostScript profiles is that a CSA is usually more compact than an ICC profile and can be more precise, because it is based on an algorithm and not on a table. A CRD can also be more compact than an ICC profile because it usually contains only one table, whilst an ICC printer profile can contain as many as eight (for different rendering intents).

On the other hand, one should note that PostScript Color Management can only be supported by a Level 3 or Level 2 rip with a version higher than 2017. These new rips may support PCM, but they do not necessarily. The rip constructor may or may not have included PCM support, may or may not have built in a CRD, and may or may not have provided for control over this CRD. Consequently, different Level 3 rips may support PostScript Color Management in different ways. Some rips, for example, accept a CMYK CSA, others do not (like Level 2 rips). For the latter, in-rip proof is not possible: one should check the rip version to avoid surprises.

In favor of ICC profiles, one should note that they are two-directional, whilst CSA and CRD are "one-way". Furthermore, although PostScript is more accurate, it is also slower and needs an interpreter. An ICC profile on the other hand, only requires a color engine, which is a much less complex piece of software. It is perhaps for this reason that PostScript color Management is less successful than ICC. Even the Adobe PDF graphic format, version 1.3, has chosen ICC profiles for specifing colors, because they are simpler and more widespread.

The most commonly quoted disadvantage to PCM is that if the CRD is resident in the printer, the quality and efficiency of the color management depends on the make of printer. The CRD is rarely documented (eg. the CRD in Kodak sublimation printers) and when it is, often only vaguely.

Some CRDs are permanently "engraved" on the ROM of the rip and it is impossible to replace them with a custom-made CRD. Ideally, more than one CRD should be available (either automatically or manually), to take account of changes in ink and paper combinations.

Often the only way to use another CRD (for the whole document) is to insert it into the print stream and hope that the rip will think "I have to use this CRD instead of the built-in one like the specifications say". If it is a CRD for a single image, the built-in one returns when the image has been printed.

Ideally, it should be possible to insert the whole CRD (not only the name) into the printer PPD. Then the application could use the built-in one or insert the PPD one into the PostScript print stream. But I don’t believe this is possible yet.

It should also be possible to interrogate and extract the CRD resident in the rip. Otherwise it is not possible to make a soft proof, for example. No program is capable of interrogating the printer, lifting out the CRD and using it for the soft proof. Only a few software packages allow you to construct a CRD (Logo ProfileMaker, Heidelberg PrintOpen). And not all of them support all four rendering intents.

Some rips (e. g. some HP DesignJet printers) accept DeviceCMYK and convert it into a CSA as device-independent color in order to separate it with the printer CRD (e.g. for proofing, but special ink effects are lost and there are rounding up/down errors). Standard rips cannot do this.

Please note that if the source colors referred to the printer are defined in a CMYK space by the CSA, PCM will in any case transform them into XYZ and then back into CMYK with the CRD. In theory, one should get back to the original data, but rounding up/down errors can creep in. In addition, it is not possible to preserve special ink effects such as overprint and knock-out. These would be lost even if the data could be used directly.

PostScript does not support ICC profiles, only CSAs and CRDs. On the other hand, PDF (i.e. interpreted PostScript) supports CSA (not all types) and ICC profiles.

Some recent Level 3 rips accept and recognise ICC profiles incorporated in a PDF.