PDFBOX-5074: use the tint transform of DeviceN if a spot colorant isn't white at zero tint

[valerybokov]

Problem

Problem
In PDFBOX-5074 (https://issues.apache.org/jira/browse/PDFBOX-5074), a DeviceN space with one spot colorant (PANTONE 342 C) is painted at tint 0.4. It renders as a dark green (RGB ≈ 0, 0.16, 0.12), so the tint ramp runs from black to green. Adobe Reader draws a white background with a light green fill.

Cause
When a DeviceN has an attributes dictionary, PDDeviceN converts to RGB by multiplying the RGB values of its colorants (toRGBWithAttributes). That only works if a colorant with tint 0 is white, so that no ink leaves the result unchanged.

In this file the spot colorant's Separation function maps tint 0 to black (0,0,0). Multiplying by that darkens everything, and the space ends up black-to-green. The tint transform to the CMYK alternate space gives white at tint 0.

Change

• PDDeviceN: If a spot colorant that the conversion uses (a spot colorant not replaced by a process colorant) is not white at zero tint, toRGB and toRGBImage use the tint transform and the alternate space instead of the attributes.
  • "Not white" means any RGB channel below 0.9.
  • The result is computed once, on first use, and reset in setAttributes.
  • Spaces whose spot colorants are white at zero tint keep the attributes path exactly as before.
• PDSeparation: Adds a public getTintTransform(). PDDeviceN needs it to evaluate tint 0 directly. PDSeparation.toRGB caches by (int)(tint*255), so calling it with 0 would make every later tint below 1/255 return the tint-0 color.

Notes

• The 0.9 threshold is a heuristic. I did not run the Altona suite, so I have no wider corpus data on it.
• The plain Separation square in PDFBOX-5074_2.pdf still renders dark. The file's own function defines it as black-to-green, so that is correct and unchanged.

---

Per https://www.apache.org/legal/generative-tooling.html: portions of this PR were
produced with assistance from Claude Code (Anthropic), based on a bug was described in Apache PDFBOX Issue Tracker.

I've reviewed the generated code and confirm to the best of my knowledge that the output does not include any
third-party copyrighted material and is compatible with the Apache License 2.0.

[THausherr]

Yes thanks, this works fine with the 2 files from that issue + the 2 files from the linked GS ticket and no regressions. This includes the Altona test files.