Delphi'de PDF/raster Taranmış Belgeleri Doğrulama

ISO 23504-1 olarak standartlaştırılan PDF/R, taranmış belgeler için PDF profilidir: her sayfa tam olarak bir şerit görsel ve başka hiçbir şey taşır. PDFium Component onu Delphi, Lazarus ve C++Builder'dan bir akış okuyup uyumluluk düzeyini artı somut sorunlar kümesi döndüren ValidatePdfRCompliance aracılığıyla doğrular

Profil, tarayıcıların ve belge yakalama sistemlerinin PDF/A'dan daha dar bir hedefe ihtiyaç duyması nedeniyle var. Arşivlik bir PDF bölümün izin verdiği her şeyi içerebilir; bir raster PDF kasıtlı olarak yoksul bırakılır, dolayısıyla uyumlu her okuyucu onu özdeş görüntüleyebilir ve uyumlu her yazıcı bir yazma motoru olmadan bir taramadan üretebilir

PDF/R, PDF/A'nın izin verdiği neyi yasaklar?

Uygulamada metni. Bir raster sayfa taranan görseli ve başka hiçbir şeyi taşır, dolayısıyla bir sayfada yazı tipi kaynağı bir ihlaldir; ISO 23504-1 §6.5.2 altında pvriFontForbidden olarak rapor edilir. Bu, aranabilirlik için görünmez bir OCR metin katmanı ekleyen insanları şaşırtır; bu, bir PDF/A akışında normal ve yararlı bir şeydir ve yalnızca PDF/R değildir

Sayfadan-görsele ilişki eşit derecede katıdır. §6.5.1 her sayfayı tam olarak bir şerit görsel yapar, dolayısıyla görsel sayısı sayfa sayısıyla eşleşmediğinde pvriPageImageMismatch ateşlenir; görseli olmayan bir sayfa ve iki görseli olan bir sayfanın ikisi de uyumlu değildir. Ve pvriBadMediaBox, MediaBox'i [0 0 w h] biçiminde olmayan bir sayfayı raporlar (§6.5.3), çünkü bir taramanın konum kaynaklı bir başlangıç noktasında durması için hiçbir nedeni yoktur

uses FPdfPdfr;

var
  Src: TFileStream;
  Res: TPdfRValidationResult;
begin
  Src := TFileStream.Create('scan-batch-0142.pdf', fmOpenRead or fmShareDenyWrite);
  try
    Res := ValidatePdfRCompliance(Src);
    if Res.IsCompliant then
      Memo1.Lines.Add('PDF/R-1 conformant')
    else
    begin
      if pvriFontForbidden in Res.Issues then
        Memo1.Lines.Add('A page names a font resource; a raster page carries no text');
      if pvriPageImageMismatch in Res.Issues then
        Memo1.Lines.Add('Image count does not match page count');
      if pvriForbiddenImageFilter in Res.Issues then
        Memo1.Lines.Add('A strip image uses an encoding outside the white list');
    end;
  finally
    Src.Free;
  end;
end;

Hangi görsel kodlamalarına izin verilir?

Dört tane ve beyaz liste bir nedenden dolayı kısadır. §6.6 /CCITTFaxDecode, /DCTDecode, /JPXDecode ve /FlateDecode'e izin verir; çift düzeyli faks, JPEG, JPEG 2000 ve kayıpsız deflate; bunlar önem taşıyan her tarayıcı çıktısını kapsar. Başka her şey pvriForbiddenImageFilter olarak rapor edilir; /LZWDecode, /RunLengthDecode, /ASCII85Decode, /ASCIIHexDecode, /JBIG2Decode ve /Crypt dahil

O reddin ikisi ezbere yerine anlamaya değer. /JBIG2Decode çift düzeyli taramaları son derece iyi sıkıştırır ve PDF/A'da tamamen yasaldır, ama sembol sözlüğü yeniden inşası görsel olarak benzer glyph'leri yerine koyabilir; taranan basamaklar için belgelenmiş bir başarısızlık kipi ve tüm amacı güvenilir raster üretimi olan bir profil o riski kabul edemez. ASCII süzgeçleri ters nedenden dolayı dışlanır: bir raster profile hiçbir şey katmadan dosyayı şişirirler

Herhangi bir sayfa okunmadan önce ateşlenen yapı kuralları

PDF/R kapsayıcıyı da kısıtlar. pvriObjStmPresent proflinin dümdüz yasakladığı bir /Type /ObjStm akışını raporlar; nesne akışları bir raster okuyucunun yapabilmesi amaçlanan basit, sıralı ayrıştırmayı karmaşıklaştırır. pvriBadHeader %PDF-1.4 ile 1.7 dışında ve %PDF-2.0 dışında bir başlık raporlar ve pvriEncryptVersionMismatch, başlığı %PDF-2.0 olmayan şifreli bir dosyayı raporlar, §6.2.3'e göre

Katalog ve Info sözlüğü yalnızca denetlenmek yerine beyaz listeye alınır. pvriProhibitedCatalogEntry ve pvriProhibitedInfoEntry, izin verilen küme dışındaki girdiler için ateşlenir ve pvriInfoXmpMismatch, bir Info girdisi XMP karşılığıyla ayrıştığında ateşlenir. Eksik bir katalog /Metadata akışı, eksik bir trailer /ID ve eksik bir %PDF-raster-1.0 alt bilgi işaretçisinin her birinin kendi sorunu da vardır

Kayıt seçenekleri kaydı neden Title ve Author'ı dışlar?

TPdfRSaveOptions, Creator, Producer, CreationDate, ModDate, DocumentId ve InstanceId'i taşır ve bilinçli olarak Title, Author, Subject veya Keywords için bir alanı yoktur. O dördü §6.4.3'ün yasakladığı girdilerdir, dolayısıyla onları ortaya çıkaran bir kayıt, çağıranları uyumlu bir API üzerinden uyumlu olmayan bir dosya yazmaya davet ederdi

Var olan bir PDF'i dönüştürürken temizlemeyi denetleyen iki boolean seçenek vardır. StripInfoOptionalEntries öntanımlı olarak True'dur ve kaynak Info sözlüğünden Title, Author, Subject, Keywords ve Trapped'i kaldırır. StripCatalogOptionalEntries da öntanımlı olarak True'dur ve Names, Outlines, StructTreeRoot, OutputIntents, Lang ve geri kalanını kaldırıp yalnızca §6.3 beyaz listesini bırakır. Herhangi birini False yapın ve girdileri tutarsınız; uyumluluğu da kaybedersiniz ki bu ara sıra çağıranın bir iç dosya için gerçekten istediği bir şeydir

var
  Opts: TPdfRSaveOptions;
  Src, Dest: TFileStream;
begin
  Opts := TPdfRSaveOptions.Default;
  Opts.Creator := 'Capture Station 4';
  Opts.Producer := 'PDFium Component';
  Src := TFileStream.Create('scan-in.pdf', fmOpenRead or fmShareDenyWrite);
  try
    Dest := TFileStream.Create('scan-pdfr.pdf', fmCreate);
    try
      InjectPdfRMarkers(Src, Dest, Opts);   // markers + metadata, not page content
    finally
      Dest.Free;
    end;
  finally
    Src.Free;
  end;
end;

İşaretçi enjeksiyonunun yapmadığına dikkat edin: üst veri ve tanımlama ekler ve sayfa içeriği sağlayamaz. Şerit görseli taşımayan bir kaynak sayfa, eneksiyondan sonra yine de pvriPageImageMismatch'te başarısız olur, çünkü eksik görsel hiçbir zaman bir üst veri sorunu değildi

PDF/R bir yakalama akışında nereye oturur?

Çıktının taramanın kendisi olduğu ve doğruluğun tüm sözleşme olduğu yerde kullanın; kanıtsal görüntüleme, çek ve ödeme yakalama, geniş formatlı bir tarayıcıdan mühendislik çizim arşivleri. Belge aranabilir metin, etiketleme, gömülü ekler veya raster profilin soymadığı başka herhangi bir şey gerektirdiği an PDF/A kullanın

Yaygın ve uygulanabilir bir düzenleme ikisini de üretmektir: asla değişmeyen bir PDF/R özgün hâli ve alma için bir OCR katmanına sahip bir PDF/A türevi. Doğrulayıcılar bağımsızdır, dolayısıyla aynı toplu iş her yapıtı fiilden iddia ettiği profile göre denetleyebilir. O çiftin arşiv tarafı için PDF/A arşiv uyumluluğu ve PDF/A preflight doğrulaması notlarına ve baskı yönelimli çıktı için baskıya hazır PDF/X belgelerini doğrulama yazısına bakın

PDFium Component, PDFium motorunu Delphi, C++Builder ve Lazarus'a bir VCL API'si ve PDF/A, PDF/X, PDF/E, PDF/UA ve PDF/R için uyumluluk doğrulayıcılarıyla getirir; PDFium Component ürün sayfası desteklenen standartları ve IDE sürümlerini listeler