Spot & process color

Process colors are built on press from C, M, Y, and K; a spot color is a single named ink the renderer can only preview.

In short: A <Color> carries a Model that is either Process or Spot, and the difference is a printing one. A process color is built on press from the cyan, magenta, yellow, and black inks; a spot color is a single named ink — a PANTONE, say — mixed to a specific recipe. On a screen there is no physical ink, so Paged's renderer previews a spot color through its CMYK alternate, scaled by any swatch tint and run through ICC conversion. This page explains how that preview works, how ICC color management fits in, and exactly where the renderer is honest about the limits of what it can reproduce.

A <Color> carries a Model that is either Process or Spot. The difference is a printing one — process colors are built on press from the C, M, Y, and K inks, while a spot color is a single named ink (a PANTONE, say) mixed to a specific recipe. On a screen there is no physical ink, so the renderer has to preview a spot color. How it does that, and where the preview is honest about its limits, is what this page is about.

Process color is the straightforward case

A process color names a space and its channel values, and the renderer converts them to what the screen shows. For CMYK that conversion is color-managed: the four percentages go through an ICC transform keyed to the document's CMYK profile. RGB and Gray convert directly. There is nothing to approximate — the channel values are the color.

This is the path the color-fill example takes: a process CMYK red, converted and painted.

Spot color is previewed through its alternate

A spot ink's true appearance needs a spectral model of the physical ink — which this renderer does not ship. What IDML carries instead, and what the renderer leans on, is the spot color's CMYK alternate: an AlternateSpace="CMYK" plus an AlternateColorValue that says "if you can't lay down the real ink, this is the process recipe that comes closest." The renderer always previews a spot color through that alternate; it deliberately does not try to interpret the spot's own primary Space (usually Lab), because doing so without a spectral model would be a guess dressed up as accuracy.

Two things fold into the alternate before it reaches ICC:

1. Swatch-level tint. If the spot <Color> carries a TintValue, each alternate channel is multiplied by TintValue / 100. A spot at 50% mixes halfway toward paper white in CMYK — 0 100 0 0 at 50% becomes 0 50 0 0 — which is how a print preview interpolates a tinted ink.
2. ICC conversion. The resulting CMYK then goes through the document's CMYK profile, exactly like a process CMYK color.

So a spot preview is, end to end: alternate CMYK → scale by any swatch tint → ICC → screen. A spot color with no CMYK alternate has nothing to preview through; the renderer cannot resolve it to a visible color and leaves it unresolved. Parsed, not yet renderedSpot color without a CMYK alternate

ICC conversion and its fallback

The CMYK→screen step is color management, handled by the color engine. On a native build it uses a real ICC engine (Little CMS) keyed to the document's CMYKProfile. In the browser — the WebGPU live preview, compiled to wasm — that native engine is not available, so the engine substitutes a naive CMYK→RGB approximation. It is close enough to read a layout by, but it is not color-accurate, and saturated or profile-sensitive colors can drift.

Parsed, not yet renderedICC color management on wasm (naive fallback)

The honest edges

Several parts of IDML's color surface are part of the format and are parsed, but do not yet get their full rendered meaning. They are listed here so a document that uses them is never silently misread:

• Mixed inks and mixed-ink groups. A <MixedInk> (or MixedInkGroup) describes a swatch built from several inks at given percentages — genuinely a spectral construct. The parser recognizes the model but collapses it to an unhandled color rather than decomposing the inks; there is no spectral model to render it faithfully. A mixed-ink fill resolves to whatever fallback the surrounding code provides, not the true mix.

  Parsed, not yet renderedMixedInk / MixedInkGroup (no spectral decomposition)

• Overprint. OverprintFill / OverprintStroke ask that a fill mix with the ink already behind it instead of knocking it out. The renderer approximates this on RGB by darkening where the marks overlap; true per-separation CMYK overprint is deferred.

  Parsed, not yet renderedOverprintFill / OverprintStroke (RGB darken approximation)

• Color groups. A <ColorGroup> organizes the palette into named families ("Brand colors") for the editor. The parser keeps the grouping for round-trip, but the renderer does not branch on it — a color renders the same whether or not it belongs to a group.

  Parsed, not yet renderedColorGroup (organizational only)

None of these change how the common case behaves: a process color or a spot color with a CMYK alternate previews correctly. The badges mark exactly where the preview stops being faithful, so you always know which side of the line a given document sits on.

Frequently asked questions

What is the difference between spot and process color? A process color is built on press from the four C, M, Y, and K inks; a spot color is a single named ink mixed to a specific recipe, such as a PANTONE. In IDML this shows up as a <Color> whose Model is Process or Spot.

How does the renderer preview a spot color on screen? Through the spot color's CMYK alternate. End to end it is: take the AlternateColorValue, scale each channel by any swatch TintValue / 100, then run the result through the document's CMYK ICC profile to reach the screen. The renderer deliberately does not interpret the spot's own primary space (usually Lab), because doing so without a spectral model would be a guess.

What happens to a spot color with no CMYK alternate? There is nothing to preview through, so the renderer cannot resolve it to a visible color and leaves it unresolved.

Why might color look off in the browser preview? On a native build, ICC conversion uses a real engine (Little CMS) keyed to the document's CMYKProfile. In the WebGPU live preview, compiled to wasm, that native engine is not available, so a naive CMYK→RGB approximation is substituted. It is close enough to read a layout by, but it is not color-accurate, and saturated or profile-sensitive colors can drift.