HotPDF пише нативни PDF 2.0 документи от Delphi и C++Builder, включително трите архивни профила PDF/A-4 и достъпен изход PDF/UA-2 с именувани структурни елементи. Избирането им е въпрос на две свойства, но стандартите зад тези свойства са се променили повече, отколкото подсказва номерът на версията: PDF/A-4 отхвърли буквите на съответствие, които всеки научи с PDF/A-2, а PDF/UA-2 въведе структурни пространства от имена, които документ на част 1 никога не е имал
Тази статия разглежда какво реално се променя в генерирания файл и кои грешки HotPDF превръща в изключение при EndDoc, вместо в документ, който не минава валидация при клиента
Как идентификацията на PDF/A-4 се отличава от част 2 и 3
PDF/A-4 идентифицира себе си по номер на част и година на ревизия, без буква на съответствие за базовата часть. Задайте PDFACompliance на '4' и HotPDF излъчва pdfaid:part=4 с pdfaid:rev=2020 и никакъв запис pdfaid:conformance изобщо. Буквата не е изчезнала — част 4 няма нива A/B/U, защото изискванията, които по-рано ги разделяха, са сгънати в базовата часть
Две разширения запазват буква. '4E' избира PDF/A-4e за инженерни документи и излъчва съответствие E, което разрешава пъщите за 3D и RichMedia анотации, които другите профили забраняват. '4F' избира PDF/A-4f и излъчва съответствие F, което разрешава вграден файл от всякакъв формат. И трите налагат заглавка на PDF 2.0, изискват обичайните проверки за output intent и метаданни на PDF/A, и забраняват криптиране — криптиран архивен файл е противоречие, което стандартът не допуска
var
Pdf: THotPDF;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := 'invoice-archive.pdf';
Pdf.PDFACompliance := '4F'; // PDF/A-4f: associated files of any format
Pdf.BeginDoc;
Pdf.CurrentPage.SetFont('Arial', [], 11);
Pdf.CurrentPage.TextOut(50, 760, 0, 'Invoice 2026-0731');
Pdf.AddPDFAssociatedFile('invoice.xml', 'text/xml',
'Structured invoice data', 'Data', LoadInvoiceBytes);
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;AddPDFAssociatedFile вгражда файла, изгражда неговия FileSpec с /AFRelationship, и го регистрира както в масива /AF на каталога, така и в дървото с имена EmbeddedFiles. И двете регистрации са задължителни; файл, изброен само в едната, е най-честата причина хибридна фактура да минава бърза визуална проверка и да не минава реален валидатор. Низът за отношение приема Source, Data, Alternative, Supplement или Unspecified, а активният профил трябва да бъде PDF/A-3, PDF/A-4e или PDF/A-4f — базовият профил на част 4 не допуска свързани файлове. По-старото име AddPDFA3AssociatedFile все още работи за съществуващ код
Какво PDF/UA-2 изисква, а PDF/UA-1 не
PDF/UA-2 налага PDF 2.0 и излъчва pdfuaid:part=2 с pdfuaid:rev=2024, а също въвежда пространства от имена в дървото на структурата. Документ на част 1 имаше един плосък речник от стандартни роли. Документ на част 2 може да носи потребителски роли, стига всяка да принадлежи на декларирано пространство от имена, което е точно това, което прави домейн-специфичното маркиране четимо за асистивната технология, вместо да бъде отгатване
Два метода реализират това. RegisterStructureNamespace създава или преизползва индиректен речник /Type /Namespace и го изброява в StructTreeRoot /Namespaces, връщайки речника, за да можете да го преизползвате. AddStructureElementNS създава структурен елемент, чийто запис /NS сочи към този речник, което е точно това, което лицензира име на роля извън стандартния набор. Повторни извиквания с същия URI преизползват един речник вместо да трупат дубликати
var
Root: THPDFDictionaryObject;
begin
Pdf.PDFUACompliance := True;
Pdf.PDFUAPart := 2; // part 2 forces PDF 2.0
Pdf.Lang := 'en-US';
Pdf.BeginDoc;
Root := Pdf.AddStructureElement('Document', nil);
Pdf.AddStructureElementNS('WidgetGroup',
'https://example.com/ns/widgets', Root);
Pdf.EndDoc;
end;Lang не е декорация тук. Маркиран документ без деклариран естествен език оставя екранен четец да отгатва произношението, а PDF/UA третира пропуска като дефект, а не като предпочитание
Кои структурни грешки хваща EndDoc?
Четири, и всяка съответства на документ, който иначе би достигнал валидатор счупен. Коренът на структурата трябва да съдържа точно един елемент Document на най-горно ниво. Всеки речник на пространство от имена трябва да бъде индиректен, типизиран като Namespace, и да носи уникален непразен URI. Всяка референция /NS на структурен елемент трябва да се разреши до речник, реално изброен в масива /Namespaces на корена. А роля без пространство от имена трябва да бъде стандартна роля на PDF 2.0 или да се разрешава през RoleMap
Тези се задействат при EndDoc, защото това е последният момент, в който цялото дърво съществува в паметта, и първият момент, в който е завършено. Хващането им по-рано би означавало отхвърляне на валидни междинни състояния; хващането им по-късно би означавало да не се хванат изобщо. Практическото следствие за вашия код е, че структурен бъг се появява в края на генерирането със съобщение, назоваващо проблема, вместо да се появи седмици по-късно като veraPDF отчет, който някой препраща от клиент
Ролите на PDF 2.0, които си струва да се знаят
Типизираният enum на роли получава DocumentFragment, Aside, Title, FENote, Sub, Em, Strong и Artifact. Три от тях променят начина, по който маркирате обикновени бизнес документи. Aside най-накрая дава на страничните ленти и цитатите дом, който не е злоупотребен Sect. FENote маркира бележките под линия и в края като това, което са, така че четец да може да ги предложи, вместо да ги вмъква в основния текст. Em и Strong заместват семантичното отгатване, което идваше от маркиране на акцент като форматиране на ниво span
Претоварването с низ допълнително приема отворената форма Hn, включително H7 и отвъд. PDF 1.7 спираше до H6, което принуждаваше дълбоки технически документи да изравнят контура си или да преизползват нива. Ако генерирате стандарти, правни кодекси или каталози на части, само това може да бъде причината да преместите изхода към PDF 2.0
Какво да проверите преди да превключите производствения изход
PDF 2.0 е промяна на заглавка с дълга опашка. По-стари инструменти за архивно поглъщане, някои печатни RIP-ове и изненадващ брой бизнес четеци приемат само до PDF 1.7, и се провалят на заглавката, а не на нещо, което сте направили грешно. Преди превключване, потвърдете консумиращите системи, и помнете, че избирането на профил PDF/A-4 избира PDF 2.0 независимо дали сте поискали това или не
Безопасна последователност е да запазите PDF/A-3 за документи, които отиват навън към непознати читатели, да използвате PDF/A-4f за вътрешни архиви, където вие контролирате поглъщането, и да приемете PDF/UA-2 само там, където политиката за достъпност го назовава. Ако работите първо архивната страна, ръководствата за валидация на PDF/A, PDF/X и PDF/UA и за ZUGFeRD и Factur-X хибридни фактури върху PDF/A-3 разглеждат изборите на профил, които имат значение преди номера на версията, а записките за автоматизирано предполетно отчитане показват как да направите присъдата част от вашата изградба, а не ръчна стъпка
HotPDF доставя цялата авторска повърхност на PDF 2.0 като нативен VCL код за Delphi и C++Builder, така че изходът PDF/A-4 и PDF/UA-2 не се нуждае от външен двигател или преразпространим файл — страницата на HotPDF компонент изброява поддържаните профили и версии на RAD Studio