PDF/E-1, mühendislik belgeleri için arşiv profili budur ve PDFlibPas, onu SetPDFEMode ile açtığınız bir author mode artı içerik akışlarını operator operator okuyan sınırları çizilmiş bir preflight olarak uygular. Profil, etiketi değişmiş bir PDF/A değildir: kendi kimlik namespace'i, kendi yaşam döngüsü metadata zorunluluğu ve içerik doğrulamasını şimdiye kadar karşılaştığınız her arşiv profilinden daha katı yapan bir kuralı vardır
Profilin var olma nedeni mühendislik çıktılarıdır. Yirmi yıl sonra okunabilir ve kanıtlanabilir biçimde değişmemiş olması gereken, revizyon geçmişi hayatta kalan ve rengi diğer binadaki plotter üzerinde aynı anlama gelen bir çizim seti. Bu gereksinimler, talepleri çoğunlukla sayfa içeriğinin dışında, metadata ile renk yönetiminde duran bir spesifikasyon üretir; genel amaçlı bir PDF yazıcısının tam da bunları yanlış yaptığı yerdir
Kendi kimliği; PDF/A üzerinde bir varyasyon değil
Doğru kurulması gereken ilk şey, PDF/E-1 kimliğinin PDF/A ya da PDF/X kalıbının uyarlanmasıyla üretilemeyeceğidir. Profil ayrı bir XMP namespace kullanır, http://www.aim.org/pdfe/ns/id/; sürüm değeri iki yerde görünmek zorundadır: bir document information girdisi ve namespace nitelemeli XMP özelliği olarak. Yalnızca XMP özelliğini ya da yalnızca bilgi girdisini yazmak, niyeti taşıyan ama doğrulamadan kalan bir dosya üretir
Output intent de aynı derecede özgül bir şekle sahiptir. PDF/E-1, ISO_PDFE1 alt tür kimliğine sahip gömülü bir ICC profili ister ve profilin bileşen sayısı, belgenin gerçekte kullandığı cihaz renk ailesiyle eşleşmelidir. Son unsur, uygulamaların sessizce yanlış gittiği yerdir; çünkü bu madde, intent'in baştan seçilip sonra unutulamayacağı anlamına gelir
Cihaz rengi neden tüm belgeyi dolaşan bir tarama ister?
Çünkü renk alanları, sayfa düzeyi bir taramanın asla ulaşamadığı resource dictionary'lerde saklanır. PDF/E-1, DeviceRGB ile DeviceCMYK'yi bir belge için birbirini dışlayan aileler olarak ele alır; profili doğrulamak, dosyadaki her şeyin kullandığı her cihaz renk alanını bilmek demektir. Bir form XObject'in kendi kaynakları vardır. Bir pattern'in de, bir imgenin de. Bir sayfa içindeki form XObject içindeki tiling pattern üç seviye derindedir ve yalnızca en üst düzey sayfa kaynaklarını kontrol eden bir doğrulayıcı, her iki aileyi de kullanan bir belgeyi geçirebilir
Bu yüzden tarama, sayfaları, formları, imgeleri ve pattern'leri tek bir dolaşım olarak yürürken renk alanlarını kaydeder ve ancak ondan sonra belgenin tutarlı olup olmadığına ve output intent'in eşleşip eşleşmediğine karar verir. Aynı akıl, preflight mimarisini genel olarak da yönetir: kısmi dolaşım yanlış geçişler üretir ve bir conformance kontrolünde yanlış geçiş, hiç kontrol olmamasından kötüdür; çünkü kanıt olarak kayda geçer
var
Lib: TPDFlib;
Diag: WideString;
begin
Lib := TPDFlib.Create(nil);
try
Lib.LoadFromFile('assembly-drawings.pdf');
if Lib.SetPDFEMode(1) = 0 then
raise Exception.Create('PDF/E author mode was refused');
// Author mode, yaşam döngüsü metadata'yı her kayıtta güncel tutar.
// Kaydetmeden önce belgenin kendi kapısından geçip geçemeyeceğini sorun
if not Lib.PDFEReadyForSave then
begin
Diag := Lib.GetPDFEDiagnostics;
Writeln('PDF/E blockers: ', Diag);
Exit;
end;
Lib.SaveToFile('assembly-drawings-pdfe.pdf');
finally
Lib.Free;
end;
end;Yaşam döngüsü metadata her kayıt başına bir yükümlülüktür
PDF/E-1, bir belge tanımlayıcısından fazlasını ister. Asgari set, media management belge tanımlayıcısını, bir sürüm tanımlayıcısını, bir rendition sınıfını, oluşturma zamanını, değiştirme zamanını, metadata zamanını ve bir başlığı kapsar. Bu bir revizyon takibi söz dağarıdır ve var olma nedeni, mühendislik çıktısının bir kez yazılan değil yeniden yayımlanan bir şey olması beklentisidir
Bir uygulama için sonucu şudur: bu alanlar belge oluşturulurken ayarlanamaz. Modu açtığınız anda değiştirme zamanı yazılırsa ve belge sonrasında düzenlenirse, XMP anlık görüntüsü ile belgenin gerçek durumu birbirinden ayrışır ve ikisini karşılaştıran bir doğrulayıcı, kimsenin istemediği bir tutarsızlık bildirir. Author mode bu yüzden alanları her kayıttan hemen önce eşzamanlar; böylece metadata, mod açıldığı anda var olan baytları değil yazılmak üzere olan baytları tarif eder
Bu, conformance metadata için genel bir ilkedir ve PDF/E'den bağımsız olarak da söylemeye değer: türetilmiş metadata, düzenleme yoluna değil kayıt yoluna aittir. Belge durumundan hesaplanan her alan, durumun dondurulduğu anda yeniden hesaplanmak zorundadır; yoksa geçersiz kılınması olmayan bir önbellektir
İçerik doğrulamasını katı yapan kural
PDF/E-1, uyumluluk bölümü operatorlerinin bilinmeyen içeriği yutmasına izin vermez. Sıradan PDF'te BX ve EX, tüketicinin tanımadığı operatorleri yok saymak zorunda olduğu bir bölgeyi kuşatır; bu, üreticinin eski okuyucuları kırmadan daha yeni yapılar yazmasını sağlayan kaçış kancasıdır. PDF/E-1 altında bu kaçış kapalıdır; dolayısıyla preflight'ın tanımadığı her operator, bir uyumluluk bölümünün içinde olup olmamasına bakılmaksızın koşulsuz bildirilir
Bir doğrulayıcı üzerindeki etkisi büyüktür. Anlamadığı bölgeleri atlayamaz; bu da operand çözümleyicisinin her içerik akışındaki her operatorü gerçekten çözümlemek zorunda olduğu anlamına gelir. Sınırların devreye girdiği yer burasıdır. Dolaşım, 128 iç içe seviye, bir milyon nesne ve 64 MiB içerikle sınırlıdır ve bu limitler performans ayarı değildir. Düşmanca ya da yalnızca bozuk bir dosya, özyinelemeli bir doğrulayıcıyı stack overflow'a çeviren döngülü bir nesne grafiği ya da iç içe geçme derinliği sunabilir; limitler, bir doğrulama geçişinin denial-of-service vektörüne dönüşmesini önleyen şeydir. Aynı savunmacı duruş güvensiz PDF'leri güvenle çözümleme makalesinde tarif edilir
// Üretmediğiniz bir dosyanın bağımsız doğrulaması; dosyayı bir belge
// örneğine yüklemeden yapılır
var
Issues: TStringList;
Stream: TFileStream;
I: Integer;
begin
Issues := TStringList.Create;
Stream := TFileStream.Create('incoming.pdf', fmOpenRead or fmShareDenyWrite);
try
if CheckCompliancePDFE(Stream, '', 0, Issues) = 0 then
for I := 0 to Issues.Count - 1 do
Writeln('PDF/E: ', Issues[I]);
finally
Stream.Free;
Issues.Free;
end;
end;Kayıt kapısının onardıkları ve reddettikleri
Kapı işini iki aşamaya böler ve bu bölünme kendi başına kullanılabilir bir tasarım fikridir. Önce güvenle onarılabilir şeyleri normalize eder: annotation baskı bayrakları, text annotation'lardaki zoom yasak ile döndürme yasak bayrakları ve form sözlüğündeki görünüm üretim bayrağı. Bunlar, profil altında tek bir doğru değeri olan ve bilgi taşımayan ayarlardır; sessizce düzeltmek doğrudur, bunların üzerinden reddetmek ise inatçılık olurdu
Ardından, belgenin ne anlama geldiğini değiştirmeden onarılamayan kısıtları kontrol eder: sürüm, kimlik, şifreleme, output intent, cihaz rengi tutarlılığı ve dinamik form içeriğinin varlığı. Bunlardan herhangi birinde kalan bir belge reddedilir; çünkü yazar adına bir output intent icat etmek ya da renk ailesi seçmek, doğrulamayı geçen ama içeriği yanlış temsil eden bir dosya üretir
Kaydetmeden önce tanılamaları GetPDFEDiagnostics üzerinden geri okumak, o reddi başarısız bir işlem yerine üzerinde işlem yapılabilir bir listeye çevirir. Toplu bir işlem hattında her belge için çağırın, engelleri dosya başına günlüğe yazın ve kalanları bir insanın baktığı kuyruğa yönlendirin. Bu, istisna fırlatan bir kayıttan çok daha faydalıdır; çünkü engeller genellikle kümeleşir: aynı eksik output intent yüzünden kalan kırk belge tek bir düzeltmedir, kırk değil
Arşiv profilleri arasında seçim
Çıktı, revizyon yaşam döngüsü olan mühendislik belgeleriyse ve özellikle çıktı plotter'lara ve geniş formatlı yazıcılara giderken cihaz rengi tutarlılığı önemliyse doğru hedef PDF/E-1'dir. Amaç genel olarak belgelerin uzun vadeli okunabilirliğiyse doğru hedef PDF/A'dır ve doğrulayıcı desteği en geniş profil odur. İkisi birbirinin yerine geçmez ve bir belge birini sağlayıp ötekini geçemeyebilir
Seçim yapıyorsanız, uçta dosyayı kimin doğrulayacağından başlayın. PDF/A doğrulama araçları her yerdedir ve PDFlibPas'taki karşılık gelen preflight, PDF/A ve PDF/UA preflight makalesinde anlatılır. PDF/E doğrulaması daha özeldir ve genellikle varsayılan değil sözleşmesel bir gerekliliktir. Mevcut bir arşiv, hiç yazılmadığı bir profile getirilmek zorundaysa izlenecek kalıp, metadata onarımıyla PDF/A'ya dönüştürme makalesindeki metadata onarım yoludur ve aynı şekil burada da geçerlidir: kimliği belirle, güvenli olanı onar, kalanını listeyle reddet
Author mode, sınırları çizilmiş içerik preflight'ı ve bağımsız compliance kontrolü, PDFlibPas Delphi PDF kütüphanesi ile birlikte gelir; böylece bir belge profil altında üretilip sonrasında ayrı bir kod yolu üzerinden bağımsız doğrulanabilir ve bir conformance iddiası için güvenilmeye değer tek düzen de budur