API reference › PDF/A & Conformance
pdfAddDeviceNProcessColorants
Attach the PDF 2.0/DeviceN /Process (which real process
BOOL32 __stdcall pdfAddDeviceNProcessColorants(PPDF IPDF, uint32_t DeviceNCS, PPAnsiChar Colorants, uint32_t NumColorants, TExtColorSpace ProcessCS, int32_t Handle);
BOOL32 __stdcall pdfAddDeviceNSeparations(PPDF IPDF, uint32_t DeviceNCS, PPAnsiChar Colorants, int32_t* SeparationCS, uint32_t NumColorants);
function pdfAddDeviceNProcessColorants(const IPDF: PPDF; DeviceNCS: Cardinal; const Colorants: PPAnsiChar; NumColorants: Cardinal; ProcessCS: TExtColorSpace; Handle: Integer): LongBool; stdcall;
function pdfAddDeviceNSeparations(const IPDF: PPDF; DeviceNCS: Cardinal; const Colorants: PPAnsiChar; SeparationCS: PInteger; NumColorants: Cardinal): LongBool; stdcall;
Purpose. Attach the PDF 2.0/DeviceN /Process (which real process color space, and which of the DeviceN's colorant names correspond to its components) and /Colorants (per-colorant Separation color-space handles) attribute dictionary entries to an already-created DeviceN color space (Color-Space Creation and Color Conversion).
Description. Both genuinely validate DeviceNCS resolves to a real DeviceN-kind color space before doing anything (FindCSByHandle + Kind = cskDeviceN check). pdfAddDeviceNProcessColorants marshals the PPAnsiChar colorant-name array into a real Pascal array and stores it plus the process color space; ProcessCS (TExtColorSpace) is reduced to a 3-way switch — only ordinal 1 (CMYK) and 2 (Gray) are distinguished; every other value (including RGB's own real ordinal, and any invalid value) collapses to the RGB fallback (else Proc := csDeviceRGB) — a caller passing a Lab/ICCBased/other extended color space ordinal here silently gets RGB instead. Handle (the last parameter of pdfAddDeviceNProcessColorants) is accepted by the ABI but not passed to AddDeviceNProcessAttr at all — its purpose (an output handle? a pre-allocated resource handle?) could not be determined from the wrapper alone, and it has no observable effect. pdfAddDeviceNSeparations similarly marshals both the colorant names and their per-colorant Separation color-space handles (SeparationCS, one Integer handle per colorant) into parallel arrays and stores them as-is (no validation that each SeparationCS[i] resolves to a real color space at this point — that would surface later, at serialization or actual paint time).
Parameters.
| Parameter | Description |
|---|---|
IPDF | Document handle. |
DeviceNCS | Target DeviceN color space handle; must already exist. |
Colorants | Array of colorant name strings. |
NumColorants | Element count for Colorants (and SeparationCS, for the Separations variant). |
ProcessCS | *(ProcessColorants only)* Only CMYK/Gray are distinguished; everything else silently becomes RGB. |
Handle | *(ProcessColorants only)* Accepted but never used. |
SeparationCS | *(Separations only)* Parallel array of per-colorant Separation color-space handles. |
Return value. True if DeviceNCS resolves to a real DeviceN space and the arrays are non-empty/consistently sized.
C# (P/Invoke)
[return: MarshalAs(UnmanagedType.Bool)]
Content Creation
pdfAddDeviceNProcessColorants
The …A form takes UTF-8, …W
takes UTF-16; a bare name aliases the ANSI form.
Worked examples — complete programs in ten languages.