Uscita PDF/A, PDF/X e PDF/UA in Delphi con HotPDF

PDF/A, PDF/X e PDF/UA sono tre standard diversi che risolvono tre problemi diversi: archiviazione a lungo termine, scambio per la stampa e accessibilità. Non sono tre caselle di spunta su un unico modulo di conformità, e l'errore più comune è trattarli come se lo fossero. Un file può essere PDF/A impeccabile e inutile per una tipografia; un master di stampa perfetto può risultare illeggibile per uno screen reader. Peggio ancora, tutti e tre sono vincoli sulla struttura interna del file, non sul suo aspetto. Un documento che si apre senza problemi in ogni visualizzatore che possedete può comunque fallire la validazione al primo tentativo, e di solito fallisce

HotPDF, la libreria PDF VCL nativa di losLab, tratta la conformità come qualcosa da dichiarare prima che esista la prima pagina. Impostate una proprietà di conformità, allegate le strutture che lo standard richiede e la libreria rifiuta al salvataggio le configurazioni che contraddicono il profilo. È un modello migliore che generare un file e sperare che un post-processore riesca ad adattarlo a posteriori, perché la maggior parte di ciò che questi standard richiedono non si può aggiungere dopo

Tre standard ISO, tre promesse diverse

Il PDF/A (ISO 19005) riguarda il tempo. Promette che un file verrà disegnato in modo identico anche fra decenni, quindi esige una completa autosufficienza: ogni font incorporato, ogni colore dotato di significato indipendente dal dispositivo attraverso un OutputIntent, metadati XMP completi e il divieto di tutto ciò il cui comportamento dipenda dall'ambiente. Cifratura e JavaScript sono esclusi, perché nessuno può garantire che il decifratore o il motore di script esisteranno nel 2050

Il PDF/X (ISO 15930) riguarda il colore sulla carta. Esiste perché un grafico possa consegnare a una tipografia un file su cui nessuno dei due debba discutere, il che significa condizioni di stampa caratterizzate, una chiave /Trapped obbligatoria, geometria di rifilo e abbondanza definita e, nella variante X-1a, nessuna trasparenza viva che il RIP debba interpretare a intuito. Il PDF/UA (ISO 14289) riguarda chi può leggere il risultato. Le tecnologie assistive hanno bisogno di un albero dei tag completo, di un ordine di lettura sensato, di una lingua del documento dichiarata e di alternative testuali per tutto ciò che non è testo

Poiché i tre tirano in direzioni diverse, scegliete lo standard di riferimento per ciascun canale di uscita invece di inseguire un unico file che li soddisfi tutti. Un master di stampa solo CMYK è esattamente la cosa sbagliata da consegnare a chi usa uno screen reader e non vede mai il colore, e la chiusura del profilo archivistico verso i comportamenti dinamici entra in collisione con qualunque cosa sia interattiva. Generate per canale dagli stessi dati di origine e schivate l'intero conflitto

PDF/A: lo OutputIntent è la parte che tutti dimenticano

Se un file PDF/A fallisce la validazione, lo OutputIntent è la prima cosa da controllare. È la struttura che i generatori saltano più spesso, proprio perché nulla di visibile dipende da essa. La ISO 19005 ne richiede uno: un profilo ICC incorporato che fissi che cosa significhino davvero i colori di dispositivo del documento. HotPDF rende quel profilo un ingresso esplicito anziché un ripensamento:

var
  Pdf: THotPDF;
  ICC: TFileStream;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.FileName := 'invoice-archival.pdf';
    Pdf.PDFACompliance := 'B';            // livello B: fedeltà visiva
    Pdf.Lang := 'en-US';
    Pdf.StandardFontEmulation := False;   // font reali incorporati, niente Base-14
    ICC := TFileStream.Create('sRGB.icc', fmOpenRead);
    try
      Pdf.AddPDFAOutputIntent('sRGB IEC61966-2.1', '', ICC, 3, 'DeviceRGB');
    finally
      ICC.Free;
    end;
    Pdf.BeginDoc;
    Pdf.CurrentPage.SetFont('Arial', [], 11);
    Pdf.CurrentPage.TextOut(50, 760, 0, 'Archival invoice body');
    Pdf.EndDoc;
  finally
    Pdf.Free;
  end;
end;

Qui alcuni dettagli decidono fra promosso e bocciato. StandardFontEmulation deve essere disattivato: i font Base-14 emulati non sono incorporati, e l'incorporamento non è negoziabile sotto la ISO 19005. La cifratura deve restare disabilitata, quindi non combinate mai PDFACompliance con ActivateProtection; un file archivistico cifrato è una contraddizione che il validatore coglie all'istante. Il numero di componenti in AddPDFAOutputIntent deve corrispondere al profilo, cioè 3 per un profilo RGB come sRGB IEC61966-2.1 e 4 per il CMYK. HotPDF tiene traccia dell'uso di DeviceRGB e DeviceCMYK rispetto allo intent dichiarato mentre scrive, così un riempimento CMYK sfuggito in un documento con intent RGB diventa un problema segnalato anziché silenzioso

Una cosa da dire sul profilo ICC: trattatelo come un artefatto di distribuzione versionato, non come un file che qualcuno una volta ha depositato sul server di build. I suoi byte vengono incorporati in ogni documento che generate, quindi un profilo troncato o corrotto avvelena in silenzio un intero lotto, e ve ne accorgete solo al momento della validazione. Distribuitelo con il vostro installer, registratene il checksum nel log di esecuzione e caricatelo con lo schema TFileStream mostrato sopra, così un file mancante fallisce rumorosamente durante la generazione invece che in silenzio al cancello dell'archivio

PDF/X per la stampa: Trapped, CMYK e il profilo di macchina

I master di stampa ribaltano la storia del colore. La macchina vuole un CMYK caratterizzato, e lo standard vi obbliga a dichiarare se il trapping sia stato applicato anche quando la risposta onesta è che non ne avete idea. La chiave /Trapped è comunque obbligatoria:

Pdf.PDFXCompliance := 'X-1a';
Pdf.Trapped := 'Unknown';        // chiave obbligatoria sotto ISO 15930
ICC := TFileStream.Create('FOGRA39.icc', fmOpenRead);
try
  Pdf.AddPDFXOutputIntent('FOGRA39 (ISO 12647-2:2004)', '', ICC, 4, 'DeviceCMYK');
finally
  ICC.Free;
end;
Pdf.BeginDoc;
// disegnate con colori sicuri in CMYK, senza trasparenza né cifratura
Pdf.EndDoc;

Il numero di componenti ora è 4 per il profilo di macchina CMYK. La X-1a vieta anche la trasparenza viva, quindi passate in rassegna qualunque codice di disegno che sovrapponga elementi traslucidi; ciò che un visualizzatore compone a schermo è esattamente ciò che un RIP si rifiuterà di interpretare. Quando la vostra tipografia invia una caratterizzazione diversa, sostituite i byte del profilo e la stringa identificativa ma lasciate intatta la struttura circostante

PDF/UA: la struttura si genera, non si aggiunge dopo

L'accessibilità è lo standard che i team cercano più spesso di appiccicare alla fine, e punisce quell'approccio più duramente degli altri due. L'albero dei tag deve rispecchiare l'ordine in cui il contenuto è stato logicamente creato, cioè una informazione che semplicemente non avete più una volta scritto il file. Impostare PDFUACompliance attiva l'uscita taggata, e l'API di struttura lega ogni chiamata di disegno al proprio ruolo semantico man mano che procedete:

Pdf.PDFUACompliance := True;     // attiva automaticamente il PDF taggato
Pdf.Lang := 'en-US';             // impostatela esplicitamente; se vuota ripiega su 'en'
Pdf.BeginDoc;

Root := Pdf.AddStructureElement(sstDocument, nil);
H1 := Pdf.EmitTaggedHeading(1, Root, 50, 700, 'Quarterly Report');
Para := Pdf.BeginTaggedContent('P', Root);
Pdf.CurrentPage.TextOut(50, 650, 0, 'Revenue grew in all regions.');
Pdf.EndTaggedContent;

Pdf.EndDoc;

Il difetto da sorvegliare è il testo disegnato fuori da qualsiasi coppia BeginTaggedContent/EndTaggedContent. Viene disegnato perfettamente e resta invisibile a uno screen reader, quindi nessun collaudatore vedente lo intercetta mai; il difetto viene consegnato e affiora soltanto quando una persona che usa davvero una tecnologia assistiva incontra la lacuna. Quando i vostri modelli portano nomi di ruolo di struttura personalizzati, mappateli sull'insieme standard con AddStructRoleMap('MyHead', 'H1') così che i lettori conformi sappiano che cosa significano. La ISO 14289 richiede anche una lingua dichiarata. HotPDF ripiega su 'en' quando Lang è vuota, ma quella è una rete di sicurezza, non un motivo per lasciare non impostata la lingua reale del documento

Verifica: fidatevi del validatore, non del visualizzatore

Un visualizzatore che apre il vostro file non prova nulla sulla conformità, quindi la verifica appartiene al percorso di rilascio con strumenti che controllano la struttura anziché il disegno. Per PDF/A e PDF/UA, veraPDF è il validatore aperto di riferimento; segnala i fallimenti per clausola ISO, e ciò rimanda direttamente alla configurazione vista sopra. Per il PDF/X, i profili Preflight di Adobe Acrobat restano il controllo pratico, perché la conformità di stampa riguarda tanto lo intent di colore quanto la sintassi

Il generatore fa la sua parte. Al salvataggio HotPDF riconcilia i flag delle funzioni con la versione PDF configurata, degradando in silenzio ciò che quella versione non può esprimere, come l'AES-256 che scende ad AES-128 sotto il PDF 1.7. I cancelli di conformità in EndDoc vanno oltre e sollevano una eccezione netta sulle contraddizioni dure, come chiedere PDFACompliance insieme alla cifratura. Nessuno dei due sostituisce il validatore esterno. Impediscono soltanto alle configurazioni impossibili di arrivarci

Una abitudine ripaga di continuo: versionate l'intero assetto di conformità come una unità. La release di HotPDF, la revisione del modello, il checksum del profilo ICC, la build del validatore che ha dato il via libera. La conformità va alla deriva nel momento in cui uno qualsiasi di essi cambia sotto gli altri, e gli audit più sgradevoli sono quelli in cui nessuno riesce a ricostruire quale combinazione abbia prodotto un file d'archivio di cinque anni fa. Un solo record di configurazione per lotto risolve la faccenda una volta per tutte

Infine, fate girare il validatore su uscite di produzione reali, mai su un campione ordinato costruito a mano. I fallimenti che mordono nascono da dati che nessuno aveva previsto: un logo del cliente che arriva in CMYK mentre lo intent dichiara RGB, una modifica al modello che infila un font non incorporato, un nuovo percorso di codice che disegna testo fuori dall'albero dei tag. Conservate un file difettoso noto per ciascun incidente passato come ingresso di regressione e il cancello di conformità resterà onesto nel tempo. Per il lato del disegno di queste catene, vedete il nostro articolo su uscita dei rapporti, font e immagini con HotPDF; per collegare i validatori a una build, c'è un pezzo di accompagnamento sull'automazione dei controlli di preflight PDF

Le proprietà di conformità, gli output intent e l'API di tagging usati in questi esempi sono distribuiti con lo HotPDF Delphi Component per Delphi e C++Builder; la pagina di prodotto rimanda al riferimento completo di ogni chiamata mostrata qui