PDF/A: 6.2.4.4 Separations and DeviceN color spaces

[reknih]

Typst uses DeviceN color spaces for HSV, HSL, Oklab, and Oklch. The PDF/A-2 spec requires the following:

For any spot colour used in a DeviceN or NChannel colour space, an entry in the Colorants dictionary shall be present. Any Separation colour space which appears in a Colorant dictionary shall obey the same restrictions as any other Separation colour space.

To express a colorant as a separation dictionary, it must act as either an subtractive or additive colorant. None of the components in the spaces we use DeviceN for behave this way. To drive this point home:

The Separation arrays in the Colorants dictionary of DeviceN and NChannel colour spaces should be consistent with the tintTransform and alternateSpace of the DeviceN or NChannel colour space itself.

Quick fix:
Fail PDF/A export if one of these color spaces is used.

Principled solution:
Convert these color values into a calibrated RGB space. The reason we do not do this at the moment is that we don't is to allow smooth interpolation by the reader in gradients. These have to be implemented as sampled functions or PostScript functions that yield RGB instead.

Note that Oklab is not expressible in ICC profile form: mm2/Little-CMS#380

[Dherse]

The problem with using a PostScript function is that some readers (most notably the macOS/safari one) don't support them on coons patch meshes, meaning that conic gradients simply don't work. I think that maybe the solution is to write the gradients in RGB with many stops when the user wants to produce a PDF/A PDF. Additionally, we don't have Oklch, HSV, and HSL as DeviceN color spaces anymore, just Oklab. I would strongly urge keeping oklab as-is for non-PDF/A document because it keeps the file sizes small and is perceptually uniform which is important for accessibility.

[reknih]

Also see https://bugs.ghostscript.com/show_bug.cgi?id=707601