PDFium Component, ISO 19005-1 Ek C uygulama sınırlarını doğrular; 127 bayt ad belirteçleri, 8191 dizi öğesi, 4095 sözlük girdisi ve 28 düzey kapsayıcı iç içeliği ve bir /Encoding girdisi taşıyan sembolik TrueType yazı tipini raporlar. Her iki denetim de bayt tarama yolunda çalışır, dolayısıyla bir Delphi veya Lazarus uygulaması PDFium DLL'ini hiç yüklemeden kararı alır
Bunlar insanları en çok şaşırtan başarısızlıklardır, çünkü belge iyi görünür. İşler, yazdırılır, her yazı tipi gömülüdür, çıktı niyeti mevcuttur. Sonra bir doğrulayıcı onu 4096 girdisi olan bir sözlük yüzünden reddeder ve görünür belgede hiçbir şey nedenini açıklamaz
Ek C sınırları gerçekte neyi koruyor?
Üreticinizden önce gelen uygulamalarla birlikte çalışabilirliği. Ek C, PDF Reference uygulama sınırlarını her PDF/A bölümüne taşır ve sayılar keyfi değildir; uyumlu bir okuyucunun geçmişte ele almasının gerektiği şeyi tanımlarlar. Onları aşan bir dosya modern bir görüntüleyicide mükemmel açılabilir ve bir kayıt sisteminin on beş yıl önce standartlaştığı arşiv okuyucusunda başarısız olabilir; bu da tam olarak PDF/A'nın var olmasının önlediği senaryodur
Dört sınır dahildir. Tam 127 baytlık bir ad belirteci doğrulanır; 128 doğrulanmaz. Tam 8191 öğesi olan bir dizi doğrulanır; 8192 doğrulanmaz. PDFium Component bu nedenden dolayı test dersindeki her sınırın iki yanını da sabitler, çünkü bir sınır denetiminde tek yöne kayma hatası en kötü türden bir doğrulayıcı üretir: uyumlu dosyaları reddeden ve yine de inanılan
uses FPdfPdfa;
var
Src: TFileStream;
Res: TPdfAValidationResult;
begin
Src := TFileStream.Create('archive.pdf', fmOpenRead or fmShareDenyWrite);
try
Res := ValidatePdfACompliance(Src);
if pvaiArrayOverLimit in Res.Issues then
Memo1.Lines.Add('An array carries more than 8191 elements');
if pvaiDictOverLimit in Res.Issues then
Memo1.Lines.Add('A dictionary carries more than 4095 entries');
if pvaiNestingOverLimit in Res.Issues then
Memo1.Lines.Add('Containers nest deeper than 28 levels');
if pvaiNameOverLimit in Res.Issues then
Memo1.Lines.Add('A name token is longer than 127 bytes');
finally
Src.Free;
end;
end;Bu sınırlara gerçekte hangi üreticiler çarpar?
Yapıyı programsal olarak inşa edenler, ki bu da iş kolu çıktılarının çoğudur. Birkaç bin alana sahip bir form, 8191'i geçen bir /Annots dizisi veya AcroForm /Fields dizisi üretir. Kaynak sözlüğü üretilen her görsel veya yazı tipi örneği için bir girdi biriktiren bir sayfa 4095'i geçer. Derin üretilen yapı ağaçları (iç içe veri modeli üzerinde özyineleme ile inşa edilmiş etiketli bir belge), kimsenin iç içe derinliğine bakmaması nedeniyle 28 düzeyi fark edilmeden geçer
Uzun adlar farklı bir alışkanlıktan gelir: verileri ad belirteçlerine kodlama. Müşteri tanımlayıcısından yapılmış bir renklendirici adı, tam dosya yoluyla adlandırılmış bir isteğe bağlı içerik grubu, tam nitelikli adı hiyerarşinin altı düzeyini birleştiren bir form alanı. Adlar üretmesi ucuz ve uzun yapması kolaydır ve bir UTF-8 kodlu etiket işin içine girdiğinde 127 bayt beklediğinizden daha hızlı tükenir
Düzeltme her durumda yapısal. Diziyi bölün, sözlüğü bölün, iç içeliği düzleştirin, adı kısaltın; her sorun için preflight önerisi dosyanın geçersiz olduğunu söylemek yerine somut sınırı adlandırır. İşaretçi enjeksiyonu burada yardımcı olamaz: bunlar üst veri iddiaları değil, nesne grafiğinin şeklidir
Sembolik bir TrueType yazı tipi neden /Encoding taşımamalı?
Çünkü ISO 19005-1 §6.3.7 sembolik TrueType yazı tipleri için yalnızca yazı tipinin yerleşik cmap'ine izin verir ve bir /Encoding girdisi onunla çelişir. Sembolik bir yazı tipi kodları kendi terimleriyle glyph'lere eşler; semboliğin anlamı budur. Bir kodlama tablosu ekleyin ve artık "0x41 baytı hangi glyph'i seçer" sorusunun iki yanıtı vardır; dosyada hangisinin kazandığını söyleyen hiçbir kural yok. Farklı okuyucular onu farklı çözer ve bir görüntüleyicide metin olarak işlenen bir belge diğerinde dingbat olarak işlenir
PDFium Component sembolik bayrağı /FontDescriptor'dan okur; tanımlayıcı yazı tipi sözlüğünde satır içi mi yoksa dolaylı olarak mı referans verildiğine bakmaksızın. Sembolik olmayan bir TrueType yazı tipi, gerekli /WinAnsiEncoding veya /MacRomanEncoding'ini işaretlenmeden korur, çünkü sembolik olmayan yazı tipleri için kodlama tam olarak standardın istediği şeydir. Denetim bir kodlamanın varlığında değil çelişkide ateşlenir
if pvaiSymbolicTrueTypeEncoding in Res.Issues then
Memo1.Lines.Add(
'A symbolic TrueType font carries /Encoding; PDF/A admits only its ' +
'built-in cmap (ISO 19005-1 6.3.7)');Bu kusurun pratik kaynağı, her TrueType yazı tipini aynı şekilde ele alan bir üretici tarafından yapılan yazı tipi alt kütlemedir. Sembol, Wingdings, barkod yazı tipleri ve simge yazı tipleri her zamanki taşıyıcılardır; bir iş belgesinin onay kutuları, logolar ve barkodlar için kullandığı yazı tipleri tam olarak bunlardır ve bir belge doğrulamada "yazı tipleri" yüzünden başarısız olduğunda kimsenin yeniden incelemediği yazı tipleri de tam olarak bunlardır
Sorunlar bir preflight raporuna nasıl ulaşır?
Dört kapsayıcı sınırı yapı altında sınıflandırılır; sembolik TrueType kodlama sorunu içerik altında. Bir rapor iki farklı kişiye gittiğinde bu ayrım önemlidir: yapı bulguları çoğunlukla üreticiyi yazan kişiye aittir ve içerik bulguları çoğunlukla varlıkları sağlayan kişiye
Her sorun, çareyi somut terimlerle adlandıran bir öneri taşır; ad belirteçlerini 127 bayt veya daha azına kısaltın, dizileri 8191 öğeden fazlasını taşımayacak şekilde bölün, sembolik TrueType yazı tiplerinden /Encoding'i kaldırın. "PDF/A uyumlu değil" diyen bir rapor bir soruşturma başlatır. Hangi sınırın ve neden aşıldığını söyleyen bir rapor bir soruşturmayı bitirir
DLL olmadan doğrulama ve neden burada önemli olduğu
Yukarıdaki tüm denetimler dosya baytları karşı çalışır, dolayısıyla dağıtılmış bir PDFium ikili dosyası olmayan bir hizmette, bir derleme adımında veya yerel bir DLL yüklemenin bir politika sorunu olduğu bir makinede çalışırlar. Bu, PDFium Component'te kasıtlı bir tasarım çizgisidir: yapılardan yanıtlanabilecek denetimler yapılardan yanıtlanır ve DLL yalnızca gerçekten bir işleme motoruna ihtiyaç duyulanlar için ayrılır
Çevreleyen iş akışı için (bir klasör üzerinde doğrulama çalıştırma, raporlar üretme ve bulgularla ne yapılacağına karar verme) Delphi'de PDF/A preflight doğrulaması ve toplu preflight rapor CLI yazılarına bakın. Tüm bu denetimlerin üzerinde duran arşiv profili seçimi için PDF/A arşiv uyumluluğu notları, bulguları düzeltmeye başlamadan önce hangi bölümü ve düzeyi hedefleyeceğinizi ele alır
PDFium Component, PDFium motorunu Delphi, C++Builder ve Lazarus için DLL'le veya DLL'siz çalışan bir dizi uyumluluk doğrulayıcısıyla birlikte üst düzey bir VCL API'siyle sarar; desteklenen standartlar ve platformlar için PDFium Component ürün sayfasına bakın