Global technology/business coverage. Sources re-read 24 October 2026.

An image that looks pleasing on a display may not produce the same appearance on paper. Krita’s soft-proofing documentation describes a preview tied to a chosen output profile, rather than a blanket guarantee of print accuracy. For a designer discussing a print job, the practical question is which output the preview is intended to represent.

The profile identifies the intended output

Krita 5.3 documentation says the proofing profile is important and should be determined by the printing house in a professional print workflow. It describes per-view proofing and the option to store the configuration in a KRA image, including the ICC profile. That makes the preview an explicitly configured representation, not a universal “print mode”.

The distinction matters when the same illustration is prepared for more than one output. A preview associated with one device, paper and process should not silently stand in for another. Recording the profile’s identity gives collaborators a way to ask whether they are discussing the same intended result.

A screen comparison has conditions

The manual discusses display settings, paper white and viewing conditions. These factors mean that a screen and physical print cannot be compared meaningfully merely by placing them next to each other. This article has not calibrated a display or examined a test print, so it cannot report a colour match or recommend particular numerical settings.

A useful conversation with the print provider can identify the output profile, the intended conversion and how a physical proof will be reviewed. That is more informative than saying that a software checkbox makes colours accurate. The preview can guide questions and adjustments, while the actual output still needs appropriate evidence.

Keep warnings separate from a final verdict

Krita describes gamut warnings as an additional aid for identifying colours affected by the previewed output range. A warning can draw attention to an area; it does not, by itself, decide whether the image is acceptable for the intended use. A creative choice may involve contrast, appearance and the project’s purpose, which a warning colour cannot judge.

The manual also lists environment and colour-space limitations. Those qualifications should remain part of a technical discussion rather than being removed to create a simpler but misleading promise. Instructions for a particular team need to match its installed version and environment.

Make the handoff auditable

When passing an image to another person, identify the working file, the output being considered and whether a proofing configuration is stored with it. If a screenshot is used in a discussion, state whether it shows the original view or the proofed view. Otherwise collaborators may appear to disagree about colour while actually looking at different representations.

The purpose is not to burden a small project with an invented certification process. It is to keep the preview’s meaning visible. Krita’s feature can help a reader reason about an intended output, but only when its profile and conditions are understood. A physical print result remains a separate observation; no software description or unchecked screenshot establishes it automatically.

A print-provider discussion record

Field	Record or question
Output	Record the intended printer, paper/process and profile supplied for that job; do not substitute a generic CMYK label.
View	State whether a screenshot is proofed or original and whether the proofing configuration is stored in the KRA.
Evidence	A screen preview, a gamut warning and a physical proof are different observations. No print or calibrated-display test was performed here.

Sources and scope

• Official primary source — Krita 5.3.0 Manual, Soft Proofing, per-view configuration, output profile and viewing-condition sections read 24 October 2026. No universal colour-match or calibration claim.

Official documentation interpretation, not a calibrated display or print test. Output-device profile, software environment and physical proof must be confirmed for the actual project.

Related reading: Technology coverage and the product-launch source checklist.