HotPDF, Delphi ve C++Builder'dan yerel PDF 2.0 belgeleri yazar; üç PDF/A-4 arşiv profili ve ad alanlı yapı öğelerine sahip PDF/UA-2 erişilebilir çıktı dahil. Bunları seçmek iki özelliğin işidir, ama o özelliklerin arkasındaki standartlar sürüm numarasının önerdiğinden daha fazla değişti: PDF/A-4, herkesin PDF/A-2 ile öğrendiği uyumluluk harflerini bıraktı ve PDF/UA-2, bir 1. bölüm belgesinin hiç sahip olmadığı yapı ad alanlarını tanıttı
Bu makale, üretilen dosyada gerçekte neyin değiştiğini ve HotPDF'in hangi hataları müşterinin yerinde doğrulamada başarısız olan bir belge yerine EndDoc'ta bir istisnaya çevirdiğini ele alır
PDF/A-4 tanımlaması 2. ve 3. bölümden nasıl farklıdır?
PDF/A-4 kendisini bölüm numarası ve düzeltme yılı ile tanımlar; temel bölüm için uyumluluk harfi yoktur. PDFACompliance'i '4' yapın ve HotPDF pdfaid:part=4'ü pdfaid:rev=2020 ile yayar ve hiç pdfaid:conformance girdisi olmaz. Harf kaybolmadı; 4. bölümün A/B/U düzeyleri yoktur, çünkü onları ayıran gereksinimler temel bölümün içine katıldı
İki uzantı bir harf korur. '4E', mühendislik belgeleri için PDF/A-4e'yi seçer ve diğer profillerin yasakladığı 3B ve RichMedia ek açıklaması yollarına izin veren E uyumluluğu yayar. '4F', PDF/A-4f'i seçer ve herhangi bir biçimde gömülü dosyaya izin veren F uyumluluğu yayar. Üçünün tamamı bir PDF 2.0 başlığını zorlar, her zamanki PDF/A çıktı niyetini ve üst veri denetimlerini gerektirir ve şifrelemeyi yasaklar; şifreli bir arşiv dosyası standardın hiç düşünmediği bir çelişkidir
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 dosyayı gömer, FileSpec'ini bir /AFRelationship ile inşa eder ve hem Katalog /AF dizisinde hem de EmbeddedFiles ad ağacında kaydeder. Her iki kayıt da gereklidir; yalnızca birinde listelenen bir dosya, hibrit bir faturanın hızlı bir gözden geçirmeyi geçip gerçek bir doğrulayıcıda başarısız olmasının tek en yaygın nedenidir. İlişki dizesi Source, Data, Alternative, Supplement veya Unspecified kabul eder ve etkin profil PDF/A-3, PDF/A-4e veya PDF/A-4f olmalıdır; temel 4. bölüm profili ilişkili dosyalar kabul etmez. Eski AddPDFA3AssociatedFile adı var olan kod için hâlâ çalışır
PDF/UA-2'nin PDF/UA-1'in olmadığını istediği nedir?
PDF/UA-2 PDF 2.0'ı zorlar ve pdfuaid:part=2'yi pdfuaid:rev=2024 ile yayar ve yapı ağacına ad alanlarını tanıtır. 1. bölüm belgesinin standart rollerin düz bir kelime dağarcığı vardı. 2. bölüm belgesi, her biri bildirilmiş bir ad alanına ait olduğu sürece özel roller taşıyabilir; bu, etki alanına özgü etiketlemeyi yardımcı teknoloji için tahmin yerine okunabilir yapar
Bunu iki yöntem uygular. RegisterStructureNamespace, dolaylı bir /Type /Namespace sözlüğü oluşturur veya yeniden kullanır ve onu StructTreeRoot /Namespaces içinde listeler ve yeniden kullanabilmeniz için sözlüğü döndürür. AddStructureElementNS, /NS girdisi o sözlüğe işaret eden bir yapı öğesi oluşturur; bu da standart küme dışında bir rol adına izin veren şeydir. Aynı URI ile yinelenen çağrılar yığınlar oluşturmak yerine tek bir sözlüğü yeniden kullanır
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 burada dekorasyon değildir. Doğal dil bildirilmemiş etiketli bir belge, ekran okuyucuyu telaffuzu tahmin etmeye bırakır ve PDF/UA bu eksikliği bir tercih değil bir kusur olarak ele alır
EndDoc hangi yapı hatalarını yakalar?
Dört tane, ve her biri aksi takdirde bir doğrulayıcıya bozuk ulaşacak bir belgeye karşılık gelir. Yapı kökü tam olarak bir üst düzey Document öğesi içermelidir. Her ad alanı sözlüğü dolaylı, Namespace olarak yazılmış ve benzersiz boş olmayan bir URI taşımalıdır. Her yapı öğesi /NS başvurusu, kök /Namespaces dizisinde fiilen listelenen bir sözlüğe çözümlenmelidir. Ve ad alanı olmayan bir rol, bir PDF 2.0 standart rolü olmalı veya RoleMap üzerinden çözümlenmelidir
Bunlar EndDoc'ta ateşlenir çünkü o tam ağacın bellekte var olduğu son an ve tamamlandığı ilk andır. Daha erken yakalamak geçerli ara durumları reddetmek demek olurdu; daha geç yakalamak hiç yakalamamak demek. Kodunuz için pratik sonuç, bir yapı hatasının sorunu adlandıran bir iletiyle üretimin sonunda yüzeye çıkmasıdır; haftalar sonra birinin bir müşteriden ilettiği veraPDF raporu olarak yüzeye çıkması yerine
Bilinmeye değer PDF 2.0 rolleri
Türlü rol sabit listesi DocumentFragment, Aside, Title, FENote, Sub, Em, Strong ve Artifact kazanır. Bunlardan üçü sıradan iş belgelerini nasıl etiketlediğinizi değiştirir. Aside sonunda kenar çubuklarına ve alıntılara kötüye kullanılmış bir Sect olmayan bir yuva verir. FENote dipnotları ve sonnotları oldukları gibi işaretler, dolayısıyla bir okuyucu onları gövde metniyle araya katmak yerine sunabilir. Em ve Strong, vurguyu yayılma düzeyinde biçimlendirme olarak etiketlemekten gelen anlamsal tahminlerin yerini alır
Dize aşırı yüklemesi ek olarak açık uçlu Hn biçimini, H7 ve sonrasını kabul eder. PDF 1.7 H6'da duruyordu ve bu da derin teknik belgeleri dış hatlarını düzleştirmeye veya düzeyleri yeniden kullanmaya zorluyordu. Standart belgeleri, yasal kodları veya parça katalogları üretiyorsanız, çıktıyı PDF 2.0'a taşımanın tek başına nedeni bu olabilir
Üretim çıktısını değiştirmeden önce neyi denetlemek gerekir?
PDF 2.0 uzun bir kuyruğu olan bir başlık değişikliğidir. Eski arşiv alım araçları, bazı baskı RIP'leri ve şaşırtıcı sayıda iş kolu görüntüleyicisi yalnızca PDF 1.7'ye kadar kabul eder ve başarısızlık yaptığınız herhangi bir yanlış şeyden değil başlıktan olur. Değiştirmeden önce tüketen sistemleri doğrulayın ve bir PDF/A-4 profili seçmenin isteyip istemediğinize bakmaksızın PDF 2.0 seçtiğini unutmayın
Güvenli bir sıra, bilinmeyen okuyuculara dışarı giden belgeler için PDF/A-3'ü tutmak, alımı denetlediğiniz iç arşivler için PDF/A-4f kullanmak ve PDF/UA-2'yi yalnızca erişilebilirlik politikası onu adlandırdığında benimsemektir. Önce arşiv tarafını çalışıyorsanız, PDF/A, PDF/X ve PDF/UA doğrulama ve PDF/A-3 üzerinde ZUGFeRD ve Factur-X hibrit faturalar kılavuzları sürüm numarasından önce önemli olan profil seçimlerini ele alır ve otomatik preflight raporlama notları kararı elle bir adım yerine derlemenizin parçası yapmayı gösterir
HotPDF tüm PDF 2.0 yazma yüzeyini Delphi ve C++Builder için yerel VCL kodu olarak sunar, dolayısıyla PDF/A-4 ve PDF/UA-2 çıktısı harici bir motor veya yeniden dağıtılabilir gerektirmez; HotPDF bileşeni sayfası desteklenen profilleri ve RAD Studio sürümlerini listeler