Under Community Review

Add support for defining color using newer models in the XPP colorspec

Historically, defining a spot color in XPP was a two step process of 

  1. going to Pantone.com and looking up out the CMYK definition for a specific color in their Coated or Uncoated color books; and
  2. taking those CMYK values and plugging them into the XPP colorspec.

This changed when the Pantone Connect product was released. The CMYK definitions for Coated or Uncoated Pantone numbers were scrubbed from the site, leaving users with only the sRGB, HEX and LAB values for describing the Pantone color (shown below). 

I've contacted Pantone to ask if the CMYK definitions for Pantone Coated or Uncoated colors would be restored or made available to Pantone Connect subscribers and was guided to use the Pantone CP or Pantone UP color bridge guide definitions. The problem with this suggestion is that the CP and UP colors are different from Coated and Uncoated colors.

Additional responses from Pantone provide some detail behind this change:

In the past beta version of Pantone Connect and the Pantone Color Finder tool on our website we did publish the CMYK value on both the Solid (spot) color and its CMYK simulation (Color Bridge library) however based on technical aspects, this was incorrect which is why it was removed.  Solid or spot colors do not have CMYK values as this is color space that is produced in a specific method of printing/production.  These were the same CMYK values between the spot and CMYK simulation, we simply removed them from being listed under the Spot color as this is inaccurate to give a value of a color that is not produced in this method. 

With all that said, this is the reason I'm asking for the colorspec to support the color models that are now commonly being used across color "owners" such as Pantone and Adobe. 

Thomas Mangan

  • Quick update:

    I just received the following email from Adobe, in which the plan to eliminate certain Pantone color books that come pre-loaded in some of the Creative Cloud applications. 

    While this doesn't impact XPP directly, for those of us that have to use color information provided by designers (external and internal), this could signal a shift in how color information is specified. I'm hoping this will reinforce the original request to have the XPP color spec support additional color models. 

    Related URLs

    Photoshop: https://helpx.adobe.com/photoshop/kb/pantone-color-books-photoshop.html 

    Illustrator: https://helpx.adobe.com/illustrator/kb/pantone-color-books-illustrator.html

    InDesign: helpx.adobe.com/.../pantone-color-books-indesign.html

  • Hmm ... I may not have all my facts correct, but IMO that would only be "hiding" the fact to your clients that XPP is doing that "conversion" itself.

    I think that certainly would be true with the PostScript workflow (psfmtdrv), because even though Pantone colors should by definition be treated as "spot" colors by XPP (if I understand correctly), I think they would still have to be converted to CMYK or RGB color values in the PS.

    Now the Direct to PDF (divpdf) workflow might be able to directly use the Pantone color definitions. But I see in the PDFlib documentation a reference that "PDFlib contains PANTONE® spot color data". So, that may just mean that PDFlib is then converting the Pantone color to a spot color with CMYK or RBG values. The Pantone colors might be expressed in PDFlib using a different color model. I cannot really say on this one, because I don't know the details of the internals of PDFlib.

    But, I do understand your point. If the colors could just be entered as Pantone (or other color model) values, then there's one less point of error.

  • in reply to Jonathan Dagresta

    Going through a conversion process (vs. using the values supplied directly from Pantone) does introduce the risk that we're not matching what a client has specified.

    If I can show a client that the values I've used in an XPP color spec match those available on Pantone exactly - any additional conversation or contention is eliminated. 

  • From Wikipedia:

    The sRGB component values Rsrgb, Gsrgb, Bsrgb are in the range 0 to 1. When represented digitally as 8-bit numbers, these color component values are in the range of 0 to 255, and should be divided (in a floating point representation) by 255 to convert to the range of 0 to 1.

    So, I would think you would then just need to multiple those resulting values by 100 (and round) to get the RGB values you would enter into the XPP color spec.