PDF/A, PDF/X и PDF/UA изходни формати в Delphi: Ръководство за HotPDF

PDF/A, PDF/X и PDF/UA са три различни стандарта, решаващи три различни проблема: дългосрочно архивиране, обмен на файлове за печат и достъпност. Те не са просто три отметки в един формуляр за съответствие и най-честата грешка е да се третират като такива. Даден файл може да бъде безупречен съгласно стандарта PDF/A и напълно неизползваем за печатница; перфектен оригинал за печат може да се окаже нечетим за екранен четец. По-лошото е, че и трите стандарта налагат ограничения върху вътрешната структура на файла, а не върху неговия външен вид. Документ, който се отваря безпроблемно във всеки четец, с който разполагате, все пак може да не премине валидирането при първия опит, което обикновено се случва

HotPDF, VCL PDF библиотеката на losLab, третира съответствието като нещо, което декларирате още преди първата страница да съществува. Вие задавате свойство за съответствие, прикачвате структурите, които стандартът изисква, и библиотеката отхвърля конфигурации, които противоречат на профила в момента на записване. Това е много по-добър модел от генерирането на файл с надеждата, че последващ процесор ще го коригира, тъй като повечето изисквания на тези стандарти не могат да бъдат добавени впоследствие

Три ISO стандарта, три различни обещания

PDF/A (ISO 19005) е свързан с времето. Той гарантира, че файлът ще се визуализира по абсолютно същия начин след десетилетия, поради което изисква пълна независимост (self-containment): всеки шрифт трябва да бъде вграден, всеки цвят да има дефинирано независимо от устройството значение чрез OutputIntent, пълни XMP метаданни и забрана за всичко, чието поведение зависи от външната среда. Шифрирането и JavaScript са изключени, тъй като никой не може да гарантира, че дешифраторът или скриптовият двигател ще съществуват през 2050 г

PDF/X (ISO 15930) е свързан с цветовете върху хартия. Той съществува, за да може дизайнерът да предаде файл на печатница без нужда от допълнителни обсъждания, което означава стандартизирани условия за печат, задължителен ключ /Trapped, дефинирана геометрия за обрязване и наддаване (trim и bleed) и, при варианта X-1a, липса на прозрачност, която RIP процесорът да интерпретира на сляпо. PDF/UA (ISO 14289) се отнася до това кой може да прочете резултата. Асистиращите технологии се нуждаят от пълно дърво на таговете (tag tree), логически ред на четене, деклариран език на документа и текстови алтернативи за всичко, което не е текст

Тъй като трите стандарта имат различни изисквания, изберете водещия стандарт според изходния канал, вместо да се опитвате да създадете един-единствен файл, който да отговаря на всички тях. Оригинал за печат само в CMYK е точно това, което не трябва да давате на потребител с екранен четец, който не вижда цветове, а ограниченията на архивния профил спрямо динамичното поведение си противоречат с всеки интерактивен елемент. Генерирайте файлове за всеки отделен канал от едни и същи изходни данни и ще избегнете този конфликт

PDF/A: OutputIntent е частта, която всеки забравя

Ако PDF/A файл не премине валидирането, OutputIntent е първото нещо, което трябва да проверите. Това е структурата, която генераторите пропускат най-често, именно защото нищо видимо не зависи от нея. Стандартът ISO 19005 изисква наличието й: вграден ICC профил, който определя какво точно означават цветовете на устройствата в документа. HotPDF прави този профил изричен входен параметър, а не допълнение след свършена работа:

var
  Pdf: THotPDF;
  ICC: TFileStream;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.FileName := 'invoice-archival.pdf';
    Pdf.PDFACompliance := 'B';            // level B: visual fidelity
    Pdf.Lang := 'en-US';
    Pdf.StandardFontEmulation := False;   // embed real fonts, no Base-14 emulation
    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;

Няколко детайла определят дали валидирането ще бъде успешно. Свойството StandardFontEmulation трябва да бъде изключено: емулираните Base-14 шрифтове не се вграждат, а вграждането е задължително съгласно ISO 19005. Шифрирането също трябва да бъде изключено, така че никога не комбинирайте PDFACompliance с ActivateProtection. Шифрираният архивен файл е противоречие, което валидаторът открива веднага. Броят на компонентите в AddPDFAOutputIntent трябва да съответства на профила, което е 3 за RGB профил как sRGB IEC61966-2.1 и 4 за CMYK. HotPDF проследява използването на DeviceRGB и DeviceCMYK спрямо декларираното намерение (intent) по време на запис, така че случайно CMYK запълване в документ с RGB намерение се превръща в докладван проблем, а не остава скрито

Нещо много важно за ICC профила: третирайте го като артефакт за внедряване с версия, а не като файл, който някой някога е качил на сървъра за компилиране. Неговите байтове се вграждат във всеки генериран от вас документ, така че непълен или повреден профил тихомълком компрометира цялата партида, а вие разбирате за това едва при валидирането. Доставяйте го с инсталатора на софтуера си, записвайте контролната му сума (checksum) в лога и го зареждайте чрез модела с TFileStream, показан по-горе, така че липсващ файл да предизвика видима грешка по време на генерирането, а не при архивирането

PDF/X за печат: Trapped, CMYK, и печатният профил

Оригиналите за печат изискват различен подход към цветовете. Печатната машина се нуждае от стандартизиран CMYK цвят и стандартът изисква да декларирате дали е приложено застъпване на цветовете (trapping), дори когато честният отговор е, че нямате представа. Ключът /Trapped е задължителен във всички случаи:

Pdf.PDFXCompliance := 'X-1a';
Pdf.Trapped := 'Unknown';        // mandatory key under 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;
// draw with CMYK-safe colors, no transparency, no encryption
Pdf.EndDoc;

Броят на компонентите вече е 4 за CMYK печатния профил. Стандартът X-1a също така забранява използването на прозрачност, така че проверете всеки чертожен код, който наслоява полупрозрачни елементи. Всичко, което четецът комбинира визуално на екрана, е точно това, което RIP процесорът ще откаже да интерпретира. Когато печатницата ви изпрати различна спецификация, сменете байтовете на профила и идентификационния низ, но запазете останалата структура непроменена

PDF/UA: структурата се генерира, тя никога не се добавя допълнително

Достъпността е стандартът, който екипите най-често се опитват да добавят накрая, и този подход се наказва по-строго в сравнение с останалите два стандарта. Дървото на таговете трябва да отразява реда, в който съдържанието е било логически създадено - информация, с която просто не разполагате, след като файлът е записан. Задаването на PDFUACompliance активира изхода с тагове, а приложният програмен интерфейс (API) за структури свързва всяко извикване за изчертаване със семантичната му роля в движение:

Pdf.PDFUACompliance := True;     // auto-enables tagged PDF
Pdf.Lang := 'en-US';             // set explicitly; empty falls back to '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;

Пропускът, за който трябва да следите, е изчертаването на text извън двойката BeginTaggedContent/EndTaggedContent. Той се визуализира перфектно на екрана, но остава невидим за екранните четци, така че тестващ потребител без зрителни проблеми никога няма да го забележи. Грешката се внедрява и се появява едва когато потребител на асистиращи технологии се сблъска с нея. Когато шаблоните ви съдържат персонализирани имена на ролите в структурата, ги съпоставете със стандартния набор чрез AddStructRoleMap('MyHead', 'H1') за да знаят съвместимите четци какво означават те. Стандартът ISO 14289 изисква също деклариран език на документа. HotPDF се връща към 'en', когато свойството Lang е празно, но това е просто защитна мярка, а не причина да оставяте реалния език на документа незададен

Валидиране: доверявайте се на валидатора, а не на четеца

Това, че даден четец отваря файла ви, не доказва неговото съответствие със стандартите. Проверката трябва да се извършва по време на изграждане на софтуера (release path) с инструменти, които анализират структурата, а не визуализацията. За PDF/A и PDF/UA софтуерът veraPDF е еталонният инструмент за валидиране; той докладва грешки по ISO клаузи, които съответстват директно на горната конфигурация. За PDF/X профилите Preflight в Adobe Acrobat все още са най-практичната проверка, тъй като съответствието за печат е свързано колкото със синтаксиса, толкова и с цветовата спецификация

Генераторът също изпълнява своята част от този процес. При записване HotPDF съпоставя флаговете на функциите с конфигурираната версия на PDF, като тихомълком понижава характеристиките, които съответната версия не може да изрази (например AES-256 се понижава до AES-128 за версии под PDF 1.7). Защитите за съответствие в EndDoc отиват по-далеч и генерират изключения при сериозни противоречия, като например изискване за съответствие с PDFACompliance едновременно с шифриране. Нито една от тези мерки не замества външния валидатор. Те просто предотвратяват достигането на невъзможни конфигурации до него

Един навик носи постоянни ползи: управлявайте версията на цялата конфигурация за съответствие като едно цяло. Версията на HotPDF, редакцията на шаблона, контролната сума на ICC профила и софтуерната компилация на валидатора, която е потвърдила резултата. Съответствието се нарушава в момента, в който някой от тези елементи се промени спрямо останалите, а най-неприятните одити са тези, при които никой не може да възстанови коя комбинация е създала архив на пет години. Поддържането на единен запис на конфигурацията за всяка партида решава този проблем веднъж завинаги

И накрая, стартирайте валидатора върху реални производствени резултати, а не върху тестов пример, съставен ръчно. Проблемите, които възникват в реална среда, се дължат на непредвидени данни: лого на клиент, което пристига в CMYK, докато намерението (intent) изисква RGB, корекция в шаблона, която вмъква невграден шрифт, или нов път в кода, който изчертава текст извън дървото на таговете. Запазете по един доказано повреден файл от всеки минал инцидент като тест за регресия и защитата за съответствие ще остане надеждна във времето. За визуализацията на тези процеси вижте статията за генериране на отчети, шрифтове и изображения с HotPDF. За интеграция на валидаторите в процеса на изграждане вижте и статията за автоматизиране на предпечатни проверки на PDF

Свойствата за съответствие, изходните намерения и API за тагове, използвани в тези примери, се доставят с компонента HotPDF за Delphi и C++Builder; продуктовата страница съдържа връзка към пълния справочник за всяко представено тук извикване