Color, profiles, and why your red is not my red

SpecSpec: ISO 32000-2, §8.6ISO 32000-2 §8.6SpecSpec: ISO 15930, PDF/XISO 15930 PDF/X

At a glance

A color in a PDF is not a fixed sensation. It is an instruction, and whether that instruction produces the same red on your laptop, on a phone, and on a printing press depends entirely on how the color was described. This page is about the difference between a color that merely tells a device what to do and a color that says what it should actually look like.

Why this matters

Pick a brand red. Set it once. Now look at it on a cheap office monitor, then on an OLED phone in a bright room, then pulled off an offset press. Three reds. Sometimes three obviously different reds. Nobody changed the number; the number was never the whole story.

For a casual document this is a shrug. For a logo, a regulated label, a photograph in a catalogue, or a record meant to survive for decades, a color that drifts is a defect. The cost is not abstract: it is a reprint, a rejected proof, or an archive whose pages no longer match the originals. The fix is not a better number. It is telling the truth about what the number means.

The short version

• Device color names a color by the control values a device receives, so the result is whatever that device makes of them (SpecSpec: ISO 32000-2, §8.6.4ISO 32000-2 §8.6.4). DeviceRGB, DeviceCMYK, and DeviceGray are device color spaces. Same numbers, different hardware, different color.
• Calibrated, ICC-based color ties those numbers to a measured, device-independent reference through an embedded profile (SpecSpec: ISO 32000-2, §8.6.5.5ISO 32000-2 §8.6.5.5). Now the document carries enough information to reproduce the intended color, not just a recipe of control values.
• An ICC profile is that measured mapping: how a device’s numbers — or those of a standard color space or output condition — relate to the color a human eye would perceive, anchored to a device-independent connection space.
• A rendering intent is the policy for what to do when a color is out of a device’s reach, because no device can show every color.
• An output intent is the document declaring, up front, the output condition it was prepared for (SpecSpec: ISO 32000-2, §14.11.5ISO 32000-2 §14.11.5). Print-grade (PDF/X) and archival (PDF/A) workflows depend on it.

How NextPDF approaches it

Start with the honest version of the problem. DeviceRGB does not contain a color. It contains three numbers between 0 and 1 and an unspoken assumption that some screen will turn them into light. Two screens with different backlights, different panels, and different calibration will turn the same three numbers into visibly different light. That is not a bug in PDF. It is what “device color” means, and the standard is candid about it: device color spaces are defined by the values a device receives, not by an absolute appearance (SpecSpec: ISO 32000-2, §8.6.4ISO 32000-2 §8.6.4).

Calibrated color closes that gap by adding a reference. An ICC profile is the result of characterizing a device or color space — a monitor, a printer, a press, or a standard space such as sRGB — and recording how its raw numbers relate to color in a device-independent connection space that approximates human vision. Embed that profile and the numbers stop being a private dialect; they become a statement anchored to something everyone can agree on. That is exactly what an ICC-based color space carries (SpecSpec: ISO 32000-2, §8.6.5.5ISO 32000-2 §8.6.5.5): the color, plus the measured mapping that says what it means.

There is a second, unavoidable wrinkle. The set of colors a press can print is not the set a phone can display, and neither is the full set the human eye can see. When a color falls outside what a target device can reproduce, some choice has to be made: clip it to the nearest reachable color, or shift a whole range of colors together so their relationships stay intact. That choice is the rendering intent — a deliberate policy, picked for the job, not an accident of rounding. A photograph and a corporate logo often want different intents, because one cares about smooth gradients and the other cares about hitting an exact swatch.

Finally, a document that is going somewhere specific can say so. An output intent is the file declaring the output condition it was prepared for — typically an embedded ICC destination profile naming a print condition or device (SpecSpec: ISO 32000-2, §14.11.5ISO 32000-2 §14.11.5). It is the difference between handing a printer a file and handing them a file that says “I was built for this press.” Print-exchange profiles make it mandatory: a PDF/X file (the ISO 15930 family) is required to carry an output intent (SpecSpec: ISO 15930, PDF/XISO 15930 PDF/X), and PDF/A relies on the same mechanism so that an archived file’s device-dependent colors remain interpretable far in the future, long after the originating environment is gone.

1. Name the colourChoose a colour space. DeviceRGB/CMYK/Gray name control values; an ICC-based space anchors them to a device-independent reference (ISO 32000-2 §8.6).
2. Anchor it (optional but decisive)Embed an ICC profile so the numbers carry their measured meaning, not just a device recipe (ISO 32000-2 §8.6.5.5).
3. Reconcile to the deviceA rendering intent decides what happens to colours the target device cannot reproduce — clip the nearest, or shift the range to preserve relationships.
4. Declare the destinationAn output intent states the output condition the document was prepared for, as PDF/X and PDF/A workflows require (ISO 32000-2 §14.11.5).

How a color travels from your code to a faithful result: it is named in a colour space, optionally anchored to a measured reference by an ICC profile, reconciled to the target device through a rendering intent, and interpreted against the output condition the document declares.

NextPDF’s job in this chain is to be standards-correct: to write the color spaces, embedded profiles, and output intents the way the format defines them, so a downstream tool — a printer’s RIP, an archival validator, a viewer — reads exactly what was intended. It produces the declarations; it does not pretend to be the device.

Practical example

The shape below sketches the decision, not a specific API. The point is that the destination is stated, not guessed.

<?php

declare(strict_types=1);

use NextPDF\Contracts\PdfDocumentInterface;

/**
 * Prepare a print-bound document that declares its intended output condition.
 *
 * The colour numbers alone do not fix the appearance. Declaring the output
 * intent — the print condition the file was built for — is what lets a press
 * interpret those numbers faithfully (ISO 32000-2 §14.11.5).
 *
 * @param PdfDocumentInterface $doc            A composed document.
 * @param string               $iccProfileBytes The destination ICC profile for the
 *                                              target print condition.
 *
 * @return string The document bytes, carrying a declared output intent.
 */
function prepareForPress(
    PdfDocumentInterface $doc,
    string $iccProfileBytes,
): string {
    // Declare the output condition explicitly. The document now states the
    // device/print condition it was prepared for, instead of leaving its
    // device colours open to interpretation.
    $doc->setOutputIntent(
        identifier: 'Custom press condition',
        iccProfile: $iccProfileBytes,
    );

    return $doc->output();
}

The colors did not change. What changed is that the file now says what they were meant to look like, which is the only thing a press or a validator can act on.

Common misconception

“It is the same hex value, so it is the same color.” The hex value is a set of device control values. Without a profile or an output intent, it is a recipe with no kitchen specified — it will taste different in every one. Two files can carry identical RGB numbers and be honestly different colors, because one declares the context that gives the numbers meaning and the other leaves it to chance.

A second trap: assuming DeviceCMYK automatically means “print-ready.” It does not. CMYK is still device color; it is press-shaped, but it is not calibrated until a profile or output intent names the actual press condition.

Limits and boundaries

NextPDF produces standards-correct color: it writes device and ICC-based color spaces and declares output intents for PDF/X-style and PDF/A workflows, the way the format defines them. That is the producing half of the job, and it is the half a document can own.

What NextPDF is not is a color-proofing system. It does not measure your monitor, soft-proof a press on screen, or certify that the printed result matches an intended swatch within a tolerance. Those belong to a color-managed proofing chain and the people who run it. The engine makes the file say the right thing; whether the final device honors it is decided downstream, by the device, the ICC profiles in play, and — for PDF/X and PDF/A — by a validator, not by the producer.

Human-factors note:Human-factors note

The most useful mental model is this: a color number is a question, and a profile or output intent is the part of the document that supplies the context to answer it. Strip away the context and every device answers differently — which is exactly why your red is not my red until the file says which red it meant.

Related docs

• What a PDF actually is — the object model these color spaces and output intents live inside.
• Archival and PDF/A — why long-term preservation leans on device-independent color and output intents.
• The standards landscape — where ISO 32000-2, PDF/X (ISO 15930), and PDF/A (ISO 19005) sit relative to each other.
• PDF 2.0: what changed — how the current format edition frames color and conformance.

Glossary

• Device color space — a color named by the control values a device receives (DeviceRGB, DeviceCMYK, DeviceGray); the appearance depends on the interpreting device (ISO 32000-2 §8.6.4).
• Calibrated / ICC-based color — color anchored to a device-independent reference through an embedded ICC profile, so the intended appearance is reproducible across devices (ISO 32000-2 §8.6.5.5).
• ICC profile — a measured mapping between a specific device’s numbers and a device-independent reference that approximates human vision.
• Rendering intent — the policy for handling colors a target device cannot reproduce: clip to the nearest reachable color, or shift a range to preserve color relationships.
• Output intent — the document’s declaration of the output condition it was prepared for, typically via an embedded destination ICC profile (ISO 32000-2 §14.11.5); required by PDF/X and used by PDF/A.
• PDF/X — the ISO 15930 print-exchange profile family of PDF; a PDF/X file must carry an output intent naming its target print condition.