A PDF/R, amelyet ISO 23504-1-ként szabványosítottak, a szkennelt dokumentumok PDF-profilja: minden oldal pontosan egy sávképet hordoz, és semmi mást. A PDFium Component Delphiből, Lazarusból és C++Builderből validálja a ValidatePdfRCompliance-szel, amely beolvas egy folyamatot, és visszaadja a megfelelőségi szintet egy konkrét problémák halmazával együtt
A profil azért létezik, mert a szkennernek és a dokumentum-rögzítő rendszereknek egy szűkebb célra volt szükségük, mint a PDF/A. Egy archív PDF tartalmazhat bármit, amit a rész megenged; egy raszter PDF szándékosan szegényes, így minden megfelelő olvasó azonosan tudja megjeleníteni, és minden megfelelő író elő tudja állítani egy szkennből szerzői motor nélkül
Mit tilt a PDF/R, amit a PDF/A enged?
A gyakorlatban szöveget. Egy raszter oldal a szkennelt képet hordozza és semmi mást, így egy betűtípus-erőforrás egy oldalon szabálysértés — pvriFontForbidden-ként jelentve az ISO 23504-1 §6.5.2 alatt. Ez meglepi azokat, akik hozzáadnak egy láthatatlan OCR-szövegréteget a kereshetőség miatt, ami egy PDF/A-workflow-ban normális és hasznos dolog, és egyszerűen nem PDF/R
Az oldal-kép kapcsolat ugyanilyen szigorú. §6.5.1 minden oldalt pontosan egy sávképpé tesz, így a pvriPageImageMismatch akkor sül ki, amikor a képszám nem egyezik az oldalszámmal — egy kép nélküli oldal és egy két képpel rendelkező oldal egyaránt nem megfelelő. És a pvriBadMediaBox egy olyan oldalt jelent, amelynek MediaBox-ja nem [0 0 w h] alakú (§6.5.3), mert egy szkennnek nincs oka eltolási origón lenni
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;Mely képkódolások engedélyezettek
Négy, és a fehérlista rövid, okkal. A §6.6 engedélyezi a /CCITTFaxDecode, /DCTDecode, /JPXDecode és /FlateDecode kódolásokat — kétértékű fax, JPEG, JPEG 2000 és veszteségmentes deflate, amelyek együtt lefednek minden szkenner-kimenetet, ami számít. Minden más pvriForbiddenImageFilter-ként kerül jelentésre, beleértve a /LZWDecode, /RunLengthDecode, /ASCII85Decode, /ASCIIHexDecode, /JBIG2Decode és /Crypt kódolásokat
Ezek közül az elutasítások kettőjét érdemes megérteni, mintsem memorizálni. A /JBIG2Decode rendkívül jól tömöríti a kétértékű szkenneket és teljesen legális a PDF/A-ban, de a szimbólum-szótár rekonstrukciója vizuálisan hasonló glypheket helyettesíthet — egy dokumentált hibaüzemmód a szkennelt számjegyeknél —, és egy olyan profil, amelynek egész célja a hű raszter-reprodukció, nem engedheti be ezt a kockázatot. Az ASCII-szűrőket az ellenkező okból zárják ki: a fájlt felfújják anélkül, hogy bármit hozzáadnának, amire egy raszter-profilnak szüksége van
Struktúraszabályok, amelyek minden oldal beolvasása előtt sülnek
A PDF/R a tárolót is korlátozza. A pvriObjStmPresent egy /Type /ObjStm folyamatot jelent, amelyet a profil egyenesen tilt — az objektumfolyamok bonyolítják azt az egyszerű, szekvenciális elemzést, amelyet egy raszter-olvasónak képesnek kell lennie végrehajtania. A pvriBadHeader egy %PDF-1.4 és 1.7 közti, valamint %PDF-2.0-n kívüli fejlécet jelent, és a pvriEncryptVersionMismatch egy olyan titkosított fájlt jelent, amelynek fejléce nem %PDF-2.0, a §6.2.3 szerint
A katalógus és az Info-szótár fehérlistás, nem csak ellenőrzött. A pvriProhibitedCatalogEntry és pvriProhibitedInfoEntry az engedélyezett halmazon kívüli bejegyzésekre sülnek ki, és a pvriInfoXmpMismatch akkor, amikor egy Info-bejegyzés ellentmond az XMP-megfelelőjének. Egy hiányzó katalógus /Metadata folyamat, egy hiányzó trailer /ID és egy hiányzó %PDF-raster-1.0 lábléc-jelölő mindegyike saját problémával rendelkezik
Miért hagyja el a mentési beállítás-rekord a Title és Author mezőket?
A TPdfRSaveOptions hordozza a Creator, Producer, CreationDate, ModDate, DocumentId és InstanceId mezőket, és szándékosan nincs mezője a Title, Author, Subject vagy Keywords számára. Ez a négy az a bejegyzés, amelyet a §6.4.3 tilt, így egy rekord, amely kitenné őket, arra hívna fel hívókat, hogy megfelelő API-n keresztül írjanak nem megfelelő fájlt
Két boolean opció vezérli a takarítást egy meglévő PDF konvertálásakor. A StripInfoOptionalEntries alapértelmezés szerint True, és eltávolítja a Title, Author, Subject, Keywords és Trapped bejegyzéseket a forrás Info-szótárból. A StripCatalogOptionalEntries szintén alapértelmezés szerint True, és eltávolítja a Names, Outlines, StructTreeRoot, OutputIntents, Lang és a többit, csak a §6.3 fehérlistát hagyva. Állítsuk bármelyiket False-ra, és megtartjuk a bejegyzéseket — és elvesztjük a megfelelőséget, ami olykor az, amit egy hívó egy belső fájlnál valóban akar
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;Vegyük észre, mit nem tesz a jelölő-injektálás: metaadatot és azonosítást ad hozzá, és nem tud oldaltartalmat szolgáltatni. Egy olyan forrásoldal, amely nem hordoz sávképet, injektálás után is elbukik a pvriPageImageMismatch-en, mert a hiányzó kép sosem volt metaadat-probléma
Hova illeszkedik a PDF/R egy rögzítő futószalagba?
Ott használjuk, ahol a szállítmány maga a szkenn, és a hűség az egész szerződés — bizonyító erejű képalkotás, csekk- és utalás-rögzítés, műszaki rajz-archívumok nagyméretű szkennerből. Használjunk PDF/A-t inkább abban a pillanatban, amikor a dokumentumnak kereshető szövegre, címkézésre, beágyazott mellékletekre vagy bármi másra van szüksége, amelyet a raszter-profil lecsupaszít
Egy gyakori és működőképes elrendezés mindkettőt előállítja: egy PDF/R-eredetit, amely sosem változik, és egy PDF/R-származékot OCR-réteggel a visszakereséshez. A validátorok függetlenek, így ugyanaz a köteg-feladat mindegyik műterméket a profilhoz mérheti, amelyet ténylegesen hivatkozik. A párosítás archív oldalához lásd a PDF/A archív megfelelőség és a PDF/A preflight-validáció jegyzeteit, a nyomda-orientált kimenethez pedig a nyomdakész PDF/X dokumentumok validálása átjárását
A PDFium Component a PDFium motort Delphihez, C++Builderhez és Lazarushoz hozza egy VCL API-val és PDF/A, PDF/X, PDF/E, PDF/UA és PDF/R megfelelőség-ellenőrzőkkel — a támogatott szabványokat és IDE-verziókat a PDFium Component termékoldal sorolja fel