NChannel-erikoisvärin yhtenäisyys Delphissä HotPDF:llä

Esipainotalo palauttaa työn: sama erikoisväri on erottunut kahdelle painolevylle. HotPDF estää sen jo kirjoitusvaiheessa kirjoittamalla NChannelin ISO 32000-2:n viisialkioisena DeviceN-muotona ja pitämällä yhden kanonisen vaihtoehtoavaruuden ja sävymuunnoksen kutakin erikoisvärin nimeä kohti koko dokumentissa sekä hylkäämällä toisen, ristiriitaisen määrittelyn sen sijaan, että antaisi sen läpi

NChannel ei ole väriavaruusperheen nimi

Ensimmäinen opittava unohtaminen on nimi itse. NChannel ei ole väriavaruusperhe niin kuin Separation ja DeviceN ovat perheitä. ISO 32000-2 §8.6.6.5 kuvaa sen DeviceN:n alityyppinä, joten norminmukainen NChannel-avaruus kirjoitetaan viisialkioisena taulukkona [/DeviceN names alternateSpace tintTransform attributes], ja attribuuttisanakirja kantaa /Subtype /NChannelia. Määrittelyssä ei ole [/NChannel ...]-taulukkoa. Jos olet joskus rakentanut sellaisen käsin ja nähnyt RIPin kohauttavan olkapäitään, syy on tämä

HotPDF erehtyi tässä kerran ja korjasi sen, mikä kannattaa sanoa suoraan, koska se muokkaa komponentin nykyistä käyttäytymistä. Vanhemmat HotPDF-julkaisut antoivat läpi perhenimimuodon. THotPDF.RegisterNChannelColorSpace antaa nykyään läpi vain standardin DeviceN-ja-attribuutit-muodon, ja koska NChannel-alityyppi saapui PDF 1.6:ssa, tuottajan aloituspiste portittaa RequirePDFVersion(pdf16, ...)illa ja kieltäytyy yksinkertaisesti vanhemmilla kohteilla. Piirtopuoli on tahallaan sallivampi kuin kirjoitin: HPDFResolveColorSpace hyväksyy yhä vanhan /NChannel-tokenin DeviceN-perheenä, joten vanhan kirjoittajan tiedostot pysyvät piirrettävinä, mutta kaikki, mitä HotPDF kirjoittaa ulos, käyttää standardikoodausta. Salliva sisääntulossa, tiukka ulostulossa on tässä oikea epäsymmetria, koska lukijasi joutuu selviytymään tiedostoista, joita se ei luonut, kun taas kirjoittajallasi ei ole tällaista tekosyytä

Miksi yksi erikoisvärin nimi päätyy kahdelle levylle?

Koska erikoisvärin nimi on dokumentin laajuinen painolevyidentiteetti, ei paikallinen argumentti. Kaksi kutsua, jotka molemmat nimeävät Orangein mutta luovuttavat eri vaihtoehtoavaruuden tai saman vaihtoehtoavaruuden eri sävymuunnoksella, kuvaavat kahta eri mustetta, jotka sattuvat jakamaan etiketin. Erotuksia rakentava RIP ei voi sovittaa sitä yhteen, joten se tekee ainoan rehellisen asian ja antaa sinulle kaksi painolevyä. HotPDF ylläpitää siksi dokumentikohtaista kanonista allekirjoitusta kutakin colorant-nimeä kohti. RegisterSpotColorantDefinition somettelee kyseisen allekirjoituksen vaihtoehtoväriavaruudesta ja sävyfunktion muodosta, ja jokainen RegisterSeparation, RegisterSeparationFunc, RegisterSeparationLUT ja NChannel-erikoisvärimäärittely kulkee sen kautta. Kun toinen määrittely kiistää ensimmäisen, kutsu nostaa poikkeuksen sen sijaan, että rekisteröisi hiljaa toisen variantin, ja viesti on tahallaan täsmällinen vikaantumistavasta, koska vaihtoehto on löytää asia painolevyvedokselta kolmen viikon päästä

// Orange oli jo rekisteröity DeviceCMYK:lle sävymuunnoksella
// 0 / 0.55 / 1 / 0 täydessä sävyssä.
Conflicting := Pdf.RegisterExponentialFunction(
  Domain1, NoInk, OtherOrangeCMYK, 1, []);
try
  Pdf.RegisterSeparationFunc('Orange', 'DeviceCMYK', Conflicting);
except
  on E: Exception do
    // 'Spot colourant "Orange" has inconsistent alternate colour
    //  space or tint definition in this document'
    LogPrepressWarning(E.Message);
end;

Päänimien jakaminen prosessikomponentteihin ja erikoisväreihin

Täydellisen NChannelin on huomioitava jokainen sen pää-colorant-nimi täsmälleen kerran, joko prosessikomponenttina tai erikoisvärin colorantina. RegisterNChannelColorSpacen edistynyt ylikuorma ottaa pää-ColorantNamesit, ProcessColorantNamesit, vaihtoehtoavaruuden, kokonaissävymuunnoksen, taulukon THPDFNChannelSpotColorant-tietueita ja valinnaisen painojärjestyksen. Jokainen spot-tietue kantaa omaa nimeään, omaa yhden syötteen Separation-sävymuunnostaan, valinnaista kiinteyttä ja valinnaista pistekasvufunktiota. Kokonaissävymuunnoksen on yhdistettävä N syötettä vaihtoehtoavaruuden komponenttilukumäärään; jokaisen spot-sävyn on yhdistettävä yksi syöte samaan lukumäärään

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);

Kyseisestä kutsusta HotPDF antaa läpi attribuuttisanakirjan, jota määrittely pyytää: /Subtype /NChannel, /Process-sanakirja, jonka /ColorSpace on prosessiavaruus ja jonka /Components luettelee prosessinimet kyseisen avaruuden komponenttijärjestyksessä, /Colorants-sanakirja, joka pitää sisällään aidon [/Separation name alternate tintfn]-taulukon kutakin spotia kohti, ja /MixingHints-sanakirja, joka kantaa /Soliditiesin, /PrintingOrderin ja /DotGainin, kun toimitit ne. Palautettu resurssinimi menee SetFillColorSpacelle tai SetStrokeColorSpacelle täsmälleen niin kuin yksinkertaisempien avaruuksien kohdalla artikkelissa Separation- ja DeviceN-erikoisvärien piirto

Mitä yhtenäisyystarkistus oikeasti hylkää?

Se hylkää rakenteellisen epäjohdonmukaisuuden avaruuden sisällä, ja se tekee sen ennen kuin yhtään objektia on kirjoitettu. Colorant-nimien on oltava ainutlaatuisia, eivätkä ne saa olla tyhjiä, All tai None. Prosessi- ja spot-määrittelyjen on yhdessä katettava pää-nimet täsmälleen, ilman että yksi colorant esiintyy molemmissa rooleissa tai jää määrittelemättä. Kun vaihtoehtoavaruus on DeviceCMYK, prosessikomponenttien on oltava Cyan, Magenta, Yellow, Black tässä järjestyksessä, ja prosessinimien lukumäärän on täsmättävä vaihtoehtoavaruuden komponenttilukumäärään. Jokaisen sävymuunnoksen ja pistekasvufunktion on oltava epäsuora funktioobjekti oikealla syöte- ja tulosteariteetilla. Kiinteyden on oltava äärellinen arvo välillä 0..1. Painojärjestyksen on oltava tyhjä tai täysi permutaatio pää-nimistä, ei koskaan osittainen lista. Se, mitä se ei tee, on värien tuomitseminen: täällä ei mikään tarkista, muistuttaako Orange-sävymuunnoksesi oikeasti purkin mustetta, onko sen CMYK-seos järkevä välittäjä vai vastaaako toimittamasi kiinteyys mitattua käyttäytymistä pohjalla. Ne ovat painokoneen ja mittauksen kysymyksiä, eikä komponentilla ole asemaa vastata niihin. Yksinkertaisempi, vain prosessia käsittelevä ylikuorma on suunnittelultaan yhä tiukempi: se tuottaa vain prosessia sisältävän NChannelin ja kieltäytyy tahallaan hyväksymästä spot-nimiä, koska spotin kirjoittaminen nimet-taulukkoon ilman vastaavaa /Colorants-tietuetta tuottaisi rakenteellisesti normista poikkeavan tiedoston, ja oletusmäärittelyn valmistaminen olisi pahempaa kuin epäonnistuminen

PDF/X-6n output intentien on katettava jokainen rekisteröity spot

N-colorant-PDF/X-6n-tiedosto ilmoittaa colorantinsa kahdesti, ja kahden ilmoituksen on sovittava yhteen. AddPDFX6ExternalOutputIntent kirjoittaa ulkoisen ICC-profiilin viittauksen ColorantTableineen, ja ennen sitä ValidateRegisteredSpotOutputColorants kulkee läpi jokaisen dokumentin rekisteröimän spotin ja nostaa poikkeuksen, jos jokin puuttuu taulusta. Tarkistus toimii molempiin suuntiin: kun output intent on julkaissut colorant-listansa, myöhempi spot-rekisteröinti listan ulkopuoliselle nimelle hylätään myös. AddPDFX6ExternalOutputIntentSpotData lisää mustekohtaiset metatiedot sen päälle, ja se valvoo omia sääntöjään, erityisesti sitä, että colorant kantaa joko kiinteyysarvon tai CxF/X-4-spektridatan, ei koskaan molempia. Tämä on sama norminmukaisuuspinta, josta keskustellaan kirjoituksessa PDF/A-, PDF/X- ja PDF/UA-validointi

Spectral := TMemoryStream.Create;
try
  LoadCxFForInk('Orange', Spectral);   // ISO 17972-4 -sisältö
  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],                  // kiinteyys yhdelle colorantille
    Order,
    ['Orange'], [Spectral]);           // spektridata toiselle
finally
  Spectral.Free;
end;

Kaksi toiminnallista yksityiskohtaa on helppo ohittaa. Rekisteri, joka tukee kaikkea tätä, on dokumenttikohtainen ja tyhjennetään dokumenttirajoilla, joten uuden tiedoston lataaminen samaan THotPDF-ilmentymään ei peri aiemman dokumentin spot-identiteettejä; kyseinen eristys on tarkoitus, koska vuotanut allekirjoitus hylkäisi täysin kelvollisen työn seuraavassa työssä. Ja profiilipuolella on omat kovat rajansa: ulkoinen output intent vaatii PDF 2.0 -kohteen, absoluuttisen HTTP- tai HTTPS-profiili-URL:n, neljän tavun ICC-väriavaruussignaaturin ja PDF/X-6n:lle 2–15 coloranttia vastaavalla 2CLR–FCLR-signaaturilla

Missä tarkistaminen pysähtyy

CxF/X-4-käsittely on se osa, josta kannattaa puhua rehellisesti. HotPDF soveltaa spektrivirtaan rajattuja rakenteellisia turvatarkistuksia ja varmistaa, että sen sisällä oleva muste-identiteetti vastaa nimeämääsi coloranttia. Se rajoittaa sisällön koon, hylkää upotetut nullitavut, kieltäytyy mistä tahansa DOCTYPE- tai ENTITY-ilmoituksen sisältävästä virrasta, vaatii tunnistettavan CxF-juuren ja vaatii täsmälleen yhden SpotInkCharacterisation-elementin, joka kantaa täsmälleen yhtä SpotInkNameia, joka on yhtä suuri kuin colorantin nimesi. Se on portti muodotonta ja vihamielistä syötettä vastaan, ei skeemavalidoija. Se ei ole täydellinen ISO 17972-4 -toteutus, se ei varmista spektrimittauksiasi, eikä se tee takaperin auditointia mielivaltaisista ennestään olemassa olevista kolmannen osapuolen objektigraafeista tai upotetun ICC-profiilin sisäisistä colorant-tauluista. Jos työnkulkusi nojaa täyteen CxF-norminmukaisuuteen, validoi tiedosto omistetulla työkalulla ennen kuin luovutat sen komponentille

Yksi viereinen rajoitus puraisee niitä, jotka eivät koskaan odottaneet kohtaavansa sen. Luminositeettipehmeä maski ei voi käyttää Separationia, DeviceNia tai NChannelia läpinäkyvyysryhmänsä /CSinä; ryhmän sekoitusavaruuden on oltava laite- tai CIE-peräinen avaruus, joten ryhmän sisällä oleva spot-maali ratkaistaan sävymuunnoksensa kautta vaihtoehtoavaruuteen ennen luminositeetin laskemista. RegisterLuminositySoftMaskState rakentaa DeviceGray-ryhmän nimenomaan siksi, ettei tämä voi mennä pieleen vahingossa. Käytännön seuraus on, että spot-painotteinen, tällä tavalla maskattu suunnittelu arvioidaan sen CMYK-välittäjän kautta, ei sen musteen, mikä merkitsee, kun verraat sitä erotettuun vedokseen niin kuin muistiinpanot artikkelissa ylipainoprooffaus ja piirtolaitteet kuvaavat

Mikään tästä ei poista tarvetta painolevyvedokselle, mutta se siirtää kokonaisen esipainohylkäysluokan painokonehuoneesta takaisin koontiin. Täällä kuvatut NChannel-, Separation- ja PDF/X-6n output intent -API:t toimitetaan standardin HotPDF Delphi Component -komponentin mukana Delphille ja C++Builderille, joissa referenssi dokumentoi täydet tietueasettelut ja täsmälliset olosuhteet, joissa jokainen kutsu epäonnistuu suljettuna