NChannel spotfesték-konzisztencia Delphiben a HotPDF-fel

A nyomdai előkészítő visszaküldi a munkát: ugyanaz a spot festék két simítólemezre separálódott. A HotPDF ezt szerzéskor előzi meg: az NChannelt az ISO 32000-2 ötelemes DeviceN formájában írja, és spotnevenként egy kanonikus alternate teret és tinttranszformációt tart az egész dokumentumra, a második, ütköző definíciót pedig kibocsátás helyett elutasítja

Az NChannel nem színtércsaládnév

Az első, amit el kell felejteni, maga a név. Az NChannel nem színtércsalád úgy, ahogy a Separation és a DeviceN családok. Az ISO 32000-2 §8.6.6.5 a DeviceN altípusaként írja le, tehát egy szabványos NChannel tér az ötelemes [/DeviceN names alternateSpace tintTransform attributes] tömbként íródik, és az attribútumszótár viseli a /Subtype /NChannel-t. [/NChannel ...] tömb a specifikációban nincs. Ha valaha kézzel épített ilyet, és a RIP csak vállat vont rá, most már tudja, miért

A HotPDF egyszer elbukta ezt, majd javította, és érdemes ezt nyíltan kimondani, mert formálja, hogyan viselkedik a komponens ma. Régebbi HotPDF kiadások a családnév-formát bocsátották ki. A THotPDF.RegisterNChannelColorSpace ma már csak a standard DeviceN-plusz-attribútum formát írja, és mivel az NChannel altípus a PDF 1.6-ban érkezett, a producer belépőpont a RequirePDFVersion(pdf16, ...) hívásra kapuz, és régebbi céloknál egyszerűen lemond. A render oldal szándékosan megbocsátóbb, mint az író: az HPDFResolveColorSpace a régi /NChannel tokent DeviceN családként még elfogadja, így a régi író fájljai renderelnek tovább, de bármi, amit a HotPDF kiír, standard kódolást használ. Engedékeny bemenet, szigorú kimenet itt a helyes aszimmetria, mert az Ön olvasójának meg kell birkóznia olyan fájlokkal, amelyeket nem ő hozott létre, míg az írónak nincs ilyen mentsége

Miért kerül egy spot név két simítólemezre?

Mert egy spot colorant név dokumentumszintű simítólemez-identitás, nem lokális argumentum. Két hívás, amelyek mindkettő Orange-t neveznek, de más alternate teret adnak át, vagy ugyanazt az alternate teret más tinttranszformációval, két különböző festéket írnak le, amelyek véletlenül osztoznak egy címkén. A separációkat építő RIPnek nincs módja ezt kibékíteni, ezért az egyetlen becsületes dolgot teszi, és két simítőlemezt ad. A HotPDF ezért dokumentumonként kanonikus aláírást tart colorant nevenként. A RegisterSpotColorantDefinition ezt az aláírást az alternate színtérből és a tintfüggvény alakjából rakja össze, és minden RegisterSeparation, RegisterSeparationFunc, RegisterSeparationLUT és NChannel spot definíció átmegy rajta. Ha egy második definíció ellentmond, a hívás kivételt dob ahelyett, hogy csendesen regisztrálná a második változatot, és az üzenet szándékosan konkrét a hibamódról, mert a másik út az, hogy ezt egy simítólemez-próbán fedezzük fel három héttel később

// Az Orange már regisztrálva volt DeviceCMYK alternate térre a
// 0 / 0.55 / 1 / 0 tinttranszformációval teljes árnyalaton.
Conflicting := Pdf.RegisterExponentialFunction(
  Domain1, NoInk, OtherOrangeCMYK, 1, []);
try
  Pdf.RegisterSeparationFunc('Orange', 'DeviceCMYK', Conflicting);
except
  on E: Exception do
    // „Az Orange spot colorantnak ellentmondó alternate
    //  színtere vagy tint definíciója van ebben a dokumentumban"
    LogPrepressWarning(E.Message);
end;

A mesternevek felosztása process és spot szerepekre

Egy teljes NChannelnek minden mester colorant nevét pontosan egyszer kell elszámolnia, akár process komponensként, akár spot colorantként. A fejlett RegisterNChannelColorSpace túlterhelés a mester ColorantNames-t, a ProcessColorantNames-t, az alternate teret, az összesített tinttranszformációt, THPDFNChannelSpotColorant rekordok tömbjét és egy opcionális nyomtatási sorrendet veszi át. Minden spot rekord viseli a saját nevét, a saját egybemenetes Separation tinttranszformációját, egy opcionális solidityt és egy opcionális dot-gain függvényt. Az összesített tinttranszformációnak N bemenetet kell az alternate tér komponensszámára képeznie; minden spot tintnek egy bemenetet ugyanarra a számra kell képeznie

const
  Colorants: array[0..4] of AnsiString =
    ('Cyan', 'Magenta', 'Yellow', 'Black', 'Orange');
  ProcessNames: array[0..3] of AnsiString =
    ('Cyan', 'Magenta', 'Yellow', 'Black');
  Order: array[0..4] of AnsiString =
    ('Yellow', 'Magenta', 'Cyan', 'Orange', 'Black');
  Domain5: array[0..9] of Single = (0, 1, 0, 1, 0, 1, 0, 1, 0, 1);
  Range4: array[0..7] of Single = (0, 1, 0, 1, 0, 1, 0, 1);
  Domain1: array[0..1] of Single = (0, 1);
  NoInk: array[0..3] of Single = (0, 0, 0, 0);
  OrangeCMYK: array[0..3] of Single = (0, 0.55, 1, 0);
  GainC0: array[0..0] of Single = (0);
  GainC1: array[0..0] of Single = (1);
var
  Pdf: THotPDF;
  Spots: array[0..0] of THPDFNChannelSpotColorant;
  CSName: AnsiString;
begin
  Pdf.Version := pdf20;
  Pdf.BeginDoc;
  Spots[0].Name := 'Orange';
  Spots[0].TintTransform := Pdf.RegisterExponentialFunction(
    Domain1, NoInk, OrangeCMYK, 1, []);
  Spots[0].HasSolidity := True;
  Spots[0].Solidity := 0.82;
  Spots[0].DotGainFunction := Pdf.RegisterExponentialFunction(
    Domain1, GainC0, GainC1, 1, []);
  CSName := Pdf.RegisterNChannelColorSpace(Colorants, ProcessNames,
    'DeviceCMYK',
    Pdf.RegisterPostScriptFunction(Domain5, Range4,
      '{ pop pop pop pop pop 0 0 0 0 }'),
    Spots, Order);

Ebből a hívásból a HotPDF kiadja a specifikáció által kért attribútumszótárat: /Subtype /NChannel, egy /Process szótár, amelynek /ColorSpace-e a process tér és /Components-e a process neveket sorolja fel az adott tér komponenssorrendjében, egy /Colorants szótár, amely minden spothoz valódi [/Separation name alternate tintfn] tömböt tart, valamint egy /MixingHints szótár, amely viseli a /Solidities-t, /PrintingOrder-t és /DotGain-t, ha Ön szolgáltatta őket. A visszakapott erőforrásnév a SetFillColorSpace-be vagy a SetStrokeColorSpace-be kerül, pontosan úgy, mint az egyszerűbb terek, amelyeket a Separation és DeviceN spot szín rendereléséről szóló cikk tárgyal

Mit utasít el valójában a konzisztencia-ellenőrzés?

A térön belüli strukturális inkohérenciát utasítja el, és ezt megteszi, mielőtt egyetlen objektum íródna. A colorant neveknek egyedinek kell lenniük, és nem lehetnek üresek, All vagy None. A process és spot definíciók együtt pontosan le kell fedjék a mesterneveket, úgy, hogy egyik colorant sem szerepel mindkét szerepben, és egyik sem marad definiálatlan. Ha az alternate tér DeviceCMYK, a process komponenseknek Cyan, Magenta, Yellow, Black sorrendben kell állniuk, és a processnevek számának az alternate komponensszámához kell illeszkednie. Minden tinttranszformációnak és dot-gain függvénynek közvetett függvényobjektumnak kell lennie a helyes bemeneti és kimeneti aritással. A soliditynek 0..1 belüli véges értéknek kell lennie. A nyomtatási sorrend üres vagy a mesternevek teljes permutációja lehet, sosem részleges lista. Amit nem tesz, az a szín megítélése: semmi itt nem ellenőrzi, hogy az Ön Orange tinttranszformációja tényleg hasonlít-e a kannában lévő festékre, hogy a CMYK összeállítása értelmes proxy-e, vagy hogy a megadott solidity egyezik-e a hordozón mért viselkedéssel. Ezek nyomda- és mérési kérdések, és a komponensnek nincs mandátuma rájuk. Az egyszerűbb, csak process túlterhelés tervezetten még szigorúbb: csak process NChannelt termel, és szándékosan nem fogad el spot neveket, mert spot név írása a névtömbbe illeszkedő /Colorants bejegyzés nélkül strukturálisan nem szabványos fájlt termelne, és egy kitalált alapdefiníció rosszabb lenne, mint a bukás

A PDF/X-6n output intentnek le kell fednie minden regisztrált spotot

Egy N colorantos PDF/X-6n fájl kétszer deklarálja a colorantjait, és a két deklarációnak egyeznie kell. Az AddPDFX6ExternalOutputIntent a külső ICC profil referenciát írja a ColorantTable-jével, és mielőtt megtenné, a ValidateRegisteredSpotOutputColorants végigmegy a dokumentum által regisztrált minden spoton, és kivételt dob, ha egyik hiányzik a táblából. Az ellenőrzés mindkét irányban fut: ha egy output intent egyszer közzétette a colorantlistáját, akkor a listán kívüli névre irányuló későbbi spot regisztrációt is elutasítják. Az AddPDFX6ExternalOutputIntentSpotData erre ráteszi a festékenkénti metaadatokat, és saját szabályokat érvényesít, nevezetesen, hogy egy colorant vagy solidity értéket vagy CxF/X-4 spektrális adatot visel, sosem mindkettőt. Ez ugyanaz a megfelelőségi felület, amelyet a PDF/A, PDF/X és PDF/UA validálásról szóló írás tárgyal

Spectral := TMemoryStream.Create;
try
  LoadCxFForInk('Orange', Spectral);   // ISO 17972-4 tartalom
  Pdf.AddPDFX6ExternalOutputIntentSpotData(
    'ECG-5', 'Five-colour output condition',
    'https://profiles.example.com/ecg-5.icc', '5CLR',
    Colorants,
    '00112233445566778899AABBCCDDEEFF', #4#3#0#0,
    ['Cyan'], [0.70],                  // solidity egy coloranthoz
    Order,
    ['Orange'], [Spectral]);           // spektrális adat egy másikhoz
finally
  Spectral.Free;
end;

Két operatív részlet könnyen elsikkad. A mindezt mögött álló nyilvántartás dokumentumonkénti, és dokumentumhatároknál törlődik, így új fájl betöltése ugyanabba a THotPDF példányba nem örökli az előző dokumentum spot identitásait; az izoláció a lényeg, mert egy elszivárgott aláírás teljesen érvényes munkát utasítana el a következő feladatban. A profil oldalnak pedig megvannak a saját kemény korlátai: a külső output intent PDF 2.0 célt, abszolút HTTP vagy HTTPS profil URL-t, négybájtos ICC színtér-aláírást kíván, PDF/X-6n esetén pedig 2 és 15 közötti colorantot illeszkedő 2CLR-től FCLR-ig terjedő aláírással

Ahol az ellenőrzés megáll

A CxF/X-4 kezelés az a rész, amiről becsületesen kell szólni. A HotPDF határolt strukturális biztonsági ellenőrzéseket alkalmaz a spektrális streamre, és megerősíti, hogy a benne lévő festékidentitás egyezik az Ön által nevezett coloranttal. Korlátozza a tartalom méretét, elutasítja a beágyazott null bájtokat, megtagad minden DOCTYPE vagy ENTITY deklarációt tartalmazó streamet, felismerhető CxF gyökert kíván, és pontosan egy SpotInkCharacterisation elemet követel, amely pontosan egy, az Ön colorant nevével egyező SpotInkName-et visel. Ez egy kapu a hibás és ellenséges bemenet ellen, nem séma validátor. Nem teljes ISO 17972-4 implementáció, nem ellenőrzi az Ön spektrális méréseit, és nem auditálja visszafelé a tetszőleges, előzetesen meglévő harmadik fél objektumgráfjait vagy egy beágyazott ICC profil belső colorant tábláit. Ha a munkafolyamata teljes CxF megfelelőségen nyugszik, validálja a fájlt dedikált eszközzel, mielőtt átadná a komponensnek

Egy szomszédos korlát azokat csíp, akik sosem számítottak rá. A luminosity soft mask nem használhat Separation-t, DeviceN-t vagy NChannelt átlátszósági csoport /CS-eként; a csoport keverési terének device vagy CIE alapú térnek kell lennie, így a csoporton belüli spot festék a tinttranszformáción keresztül az alternate térbe oldódik fel, mielőtt a luminositást számítanák. A RegisterLuminositySoftMaskState pontosan azért épít DeviceGray csoportot, hogy ez véletlenül ne romolhasson el. A gyakorlati következmény: az így maszkolt spot-nehéz tervet a CMYK proxyján keresztül értékelik, nem a festékén, ami akkor számít, amikor a overprint próbanyomat és render eszközök jegyzeteiben leírtak szerint separált próbanyomathoz hasonlítja

Ezek egyike sem szünteti meg a simítólemez-próba szükségességét, de egy egész osztálynyi nyomdai előkészítési elutasítást költöztet át a nyomdateremből vissza a buildbe. Az itt leírt NChannel, Separation és PDF/X-6n output intent API-k a standard HotPDF Delphi Component-ban szállulnak Delphihez és C++Builderhez, ahol a referencia dokumentálja a teljes rekordelrendezéseket és azokat a pontos feltételeket, amelyek mellett minden hívás zárt módon bukik meg