PDF/R, standardiseret som ISO 23504-1, er PDF-profilen til scannede dokumenter: hver side bærer præcis ét stribebillede og intet andet. PDFium Component validerer den fra Delphi, Lazarus og C++Builder gennem ValidatePdfRCompliance, som læser en strøm og returnerer conformance-niveauet plus et sæt konkrete issues
Profilen eksisterer, fordi scannere og dokument-capture-systemer havde brug for et mål smallere end PDF/A. En arkiv-PDF må indeholde hvad som helst, delen tillader; en raster-PDF er bevidst fattig, så enhver overholdende læser kan vise den identisk, og enhver overholdende forfatter kan producere den fra et scan uden en forfatter-motor
Hvad forbyder PDF/R, som PDF/A tillader?
Tekst, i praksis. En raster-side bærer det scannede billede og intet andet, så en skrifttype-ressource på en side er en overtrædelse — rapporteret som pvriFontForbidden under ISO 23504-1 §6.5.2. Det overrasker folk, der tilføjer et usynligt OCR-tekst-lag for søgbarhed, hvilket er en normal og nyttig ting at gøre i en PDF/A-arbejdsgang og simpelthen ikke er PDF/R
Forholdet mellem side og billede er lige så strengt. §6.5.1 gør hver side til præcis ét stribebillede, så pvriPageImageMismatch affyres, når billed-tællingen ikke matcher side-tællingen — en side uden billede og en side med to er begge ikke-overholdende. Og pvriBadMediaBox rapporterer en side, hvis MediaBox ikke har formen [0 0 w h] (§6.5.3), fordi et scan ikke har nogen grund til at sidde ved en offset-origine
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;Hvilke billed-kodninger er tilladte?
Fire, og den hvide liste er kort af en grund. §6.6 admit-ter /CCITTFaxDecode, /DCTDecode, /JPXDecode og /FlateDecode — bilevel-fax, JPEG, JPEG 2000 og tabsfri deflate, der imellem dækker hvert scanner-output, der betyder noget. Alt andet rapporteres som pvriForbiddenImageFilter, herunder /LZWDecode, /RunLengthDecode, /ASCII85Decode, /ASCIIHexDecode, /JBIG2Decode og /Crypt
To af disse afvisninger er værd at forstå frem for at memorere. /JBIG2Decode komprimerer bilevel-scans ekstremt godt og er fuldt ud lovlig i PDF/A, men dens symbol-dictionary-rekonstruktion kan substituere visuelt lignende glyffer — en dokumenteret fejl-tilstand for scannede cifre — og en profil, hvis hele formål er trofast raster-reproduktion, kan ikke admit-tere den risiko. ASCII-filtrene udelukkes af den modsatte grund: de inflater filen uden at tilføje noget, en raster-profil har brug for
Struktur-regler der affyres før nogen side læses
PDF/R begrænser også containeren. pvriObjStmPresent rapporterer en /Type /ObjStm-strøm, som profilen forbyder outright — objekt-strømme komplicerer den simple, sekventielle parse, en raster-læser er meningen at skulle kunne udføre. pvriBadHeader rapporterer en header uden for %PDF-1.4 til 1.7 og %PDF-2.0, og pvriEncryptVersionMismatch rapporterer en krypteret fil, hvis header ikke er %PDF-2.0, per §6.2.3
Katalog- og Info-dictionary'en er hvid-listet, ikke blot tjekket. pvriProhibitedCatalogEntry og pvriProhibitedInfoEntry affyres for poster uden for det tilladte sæt, og pvriInfoXmpMismatch affyres, når en Info-post er uenig med dens XMP-modstykke. En manglende katalog-/Metadata-strøm, en manglende trailer-/ID og en fraværende %PDF-raster-1.0-bund-markør har hver sit eget issue ligeledes
Hvorfor udelader save-options-record'en Title og Author?
TPdfRSaveOptions bærer Creator, Producer, CreationDate, ModDate, DocumentId og InstanceId, og har bevidst intet felt for Title, Author, Subject eller Keywords. Disse fire er de poster, §6.4.3 forbyder, så en record, der udstillede dem, ville invitere kaldere til at skrive en ikke-overholdende fil gennem en overholdende API
To booleske tilvalg styrer oprydning ved konvertering af en eksisterende PDF. StripInfoOptionalEntries er som standard True og fjerner Title, Author, Subject, Keywords og Trapped fra kilde-Info-dictionary'en. StripCatalogOptionalEntries er også som standard True og fjerner Names, Outlines, StructTreeRoot, OutputIntents, Lang og resten, så kun §6.3-hvid-listen forbliver. Sæt enten til False, og du beholder posterne — og mister conformance, hvilket lejlighedsvist er det, en kalder reelt ønsker for en intern fil
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;Bemærk hvad markør-injektion ikke gør: den tilføjer metadata og identifikation, og den kan ikke levere side-indhold. En kilde-side, der bærer intet stribebillede, vil stadig fejle pvriPageImageMismatch efter injektion, fordi det manglende billede aldrig var et metadata-problem
Hvor passer PDF/R i en capture-pipeline?
Brug den hvor leverancen er selve scannedet og fideltiet er hele kontrakten — bevis-fotografering, check- og remittance-capture, ingeniør-tegnings-arkiver fra en storformat-scanner. Brug PDF/A i stedet det øjeblik, dokumentet har brug for søgbar tekst, mærkning, indlejrede vedhæftninger eller noget som helst andet, raster-profilen fjerner
En almindelig og brugbar arrangement er at producere begge: et PDF/R-original, der aldrig ændres, og en PDF/A-derivat med et OCR-lag til retrieval. Validatorerne er uafhængige, så det samme batch-job kan tjekke hvert artefakt mod den profil, det reelt giver sig ud for. For arkiv-siden af det par, se noterne om PDF/A-arkiv-compliance og PDF/A-preflight-validering, og for tryk-orienteret output gennemgangen af validering af tryk-klare PDF/X-dokumenter
PDFium Component bringer PDFium-motoren til Delphi, C++Builder og Lazarus med en VCL-API og conformance-validatorer for PDF/A, PDF/X, PDF/E, PDF/UA og PDF/R — PDFium Component-produktsiden opfører de understøttede standarder og IDE-versioner