Minden geometriai szövegkinyerő találgat. Kiolvassa a glífákat, amelyeket egy oldal rajzol, alapvonal és vízszintes pozíció szerint rendezi őket, és reméli, hogy a vizuális elrendezés egyezik azzal a sorrenddel, ahogyan egy ember olvasna. Egy egyhasábos jelentésnél az a találgatás helyes. Két hasábos folyóiratcikknél, egy oldalsávval rendelkező űrlapnál vagy egy olyan táblázatnál, amelynek celláit hasábonként bocsátották ki, téves olyan módokon, amelyeket nehéz észrevenni, és drága lemenetben felfedezni. A HotPDF erre a ExtractLoadedPageStructureText metódussal válaszol, amely a geometriát teljesen figyelmen kívül hagy: a dokumentum szerkezetfáját járja be szerzői sorrendben, ahogyan azt az ISO 32000-1 §14.8.4 definiálja, majd az oldal glífáit a megjelölt-tartalom azonosítójuk szerint rakja újra össze. Címkézett PDF esetén ez nem heurisztika, hanem az a sorrend, amelyet az előállító alkalmazás kinyilvánított
A függvény False értéket ad vissza, amikor az oldalnak nincs használható szerkezetfája, ami az a jelzés, hogy vissza kell esni a geometriai kinyerőre, nem elbukni. A két utas kialakítás fontosabb, mint az algoritmus: a valós dokumentumbevétel ugyanabban a mappában lát címkézett kormányzati űrlapokat és szkennelő kimenetet, és egy vezeték, amely csak az egyiket kezeli, nem vezeték
Miért téveszti el a geometriai kinyerés az olvasási sorrendet?
Mert egy PDF tartalomfolyam egyáltalán nem hordoz olvasási sorrendet. Rajzoló operátorok sorozata, és egy előállító szabadon bocsátja ki őket abban a sorrendben, amely a saját elrendezési motorjának megfelel. A szövegszerkesztők általában folyam-sorrendben bocsátanak ki, és a geometriai rendezés jól néz ki. Az elrendezési eszközök, űrlaptervezők és jelentésgenerátorok gyakran nem: egy lábléc a törzs előtt kibocsátható, egy táblázat oszlop-fő sorrendben tölthető be, és egy két hasábos oldal mindkét hasábból sorokat fonhat össze, mert a szerkesztő együtt oldotta meg őket
A hibamód csendes. Egy geometriai kinyerő soha nem jelent hibát, csak olyan prózát ad vissza, amelynek mondatai két hasábból vannak összevágva. Bármi, amely ezt a szöveget fogyasztja — egy keresési index, egy e-számla mezőleképező, egy nyelvi modellt tápláló visszakeresési vezeték — örökli a kárt figyelmeztetés nélkül. A HotPDF szállítja a geometriai kinyerőket is betöltött dokumentumokhoz, és ezek maradnak a helyes eszköz címkézetlen fájlokhoz; a szerkezetsorrendű út lényege, hogy abbahagyja a találgatást, amikor a dokumentum már hordozza a választ
Mit tárol valójában a szerkezetfa
Egy címkézett PDF az oldal második, párhuzamos leírását tartja. A katalógus egy /StructTreeRoot elemre mutat, amelynek /K gyermekei a szerkezetek fáját alkotják: /Document, /Sect, /P, /Table, /TR, /TD és így tovább. Ennek a fának a levelei megjelölt-tartalom hivatkozások, egész számok, amelyek az oldal tartalomfolyamának egy szakaszát nevezik meg. A tartalomoldalon azok a szakaszok egy /MCID-t hordozó BDC operátorral nyílnak, és EMC-vel zárnak. Minden szerkezetelem hordoz egy /Pg bejegyzést is, amely megnevezi, melyik oldalhoz tartozik, és ez teszi lehetővé az oldalankénti bejárást egy olyan dokumentumban, amelynek szerkezetfája százszámra terjedő oldalakon átível
A HotPDF 128 szint mélységi korláttal járja be azt a fát, és a /Pg-re szűr, hogy csak az aktuális oldal járuljon hozzá. A bejárás kimenete nem szöveg, hanem MCID értékek rendezett listája: a megjelölt-tartalom szakaszok szerzői sorrendje ezen az oldalon. A szöveg újraösszerakása ezután annyit jelent, hogy a glífákat abban a sorrendben játssza vissza
Az MCID a glífa kinyerése közben rögzítődik, nem utána keresendő
Ez az implementációs részlet, amely a funkciót olcsóvá teszi. A HotPDF már most is rögzíti az aktív megjelölt-tartalom azonosítót minden általa kinyert glífán, a THPDFGlyphRecord MCID mezőjében, mert a tartalomfolyam-értelmező tudja, melyik BDC hatókör van nyitva abban a pillanatban, amikor minden Tj vagy TJ operátort feldolgoz. A szerkezetsorrendű kinyerésnek ezért nincs szüksége második menetre a tartalomfolyamon. Összegyűjti az MCID sorozatot a szerkezetfából, majd a már kinyert glífákat MCID szerint vödrözi, és abban a sorrendben bocsátja ki őket
var
Pdf: THotPDF;
PageCount, I, Untagged: Integer;
PageText, AllText: UnicodeString;
Report: TStrings; // hívó tulajdonában lévő diagnosztikai fogadó
begin
Pdf := THotPDF.Create(nil);
try
PageCount := Pdf.LoadFromFile('accessible-form.pdf');
AllText := '';
for I := 0 to PageCount - 1 do
begin
if Pdf.ExtractLoadedPageStructureText(I, PageText, Untagged) then
begin
// Szerzői sorrend egyenesen a szerkezetfából
if Untagged > 0 then
Report.Add(Format('page %d: %d glyphs outside the structure tree',
[I, Untagged]));
end
else
// Nincs használható szerkezetfa ezen az oldalon: geometriai tartalék
Pdf.ExtractLoadedPageText(I, PageText);
AllText := AllText + PageText + #13#10;
end;
finally
Pdf.Free;
end;
end;A címkézetlen glífákat megszámoljuk, soha nem dobjuk el csendben
Egy oldal lehet részben címkézett. Az előállítók dekoratív vonalat, oldalszámot vagy késői vízjelet adnak hozzá bármilyen BDC hatókörön kívül, és azok a glífák egyetlen MCID-hez sem tartoznak. Eldobásuk a rendezett implementáció és egyben a téves lenne, mert ugyanaz a rés akkor is megjelenik, amikor egy előállító a törzset címkézi, de elfelejti a táblázatot, és Ön észrevétlenül veszítené el a táblázatot
A HotPDF a meg nem igényelt glífákat geometriai farokként csatolja a szerkezetsorrendű szöveg után, és számukat a UntaggedGlyphCount kimeneti paraméteren keresztül jelenti. Az a szám minőségi jelzés, amelyen cselekedni lehet. Néhány glífa egy kétezeres oldalon oldalszerelvény, és figyelmen kívül hagyható. Az oldal negyven százaléka a szerkezetfán kívül azt jelenti, hogy a címkézés dekoratív, és a geometriai kinyerő az őszintébb válasz arra a fájlra
function ExtractPageBestEffort(Pdf: THotPDF; PageIndex: Integer;
out AText: UnicodeString; out UsedStructure: Boolean): Boolean;
var
Untagged, TotalGlyphs: Integer;
Glyphs: THPDFGlyphArray;
begin
UsedStructure := False;
if Pdf.ExtractLoadedPageStructureText(PageIndex, AText, Untagged) then
begin
TotalGlyphs := 0;
if Pdf.ExtractLoadedPageGlyphs(PageIndex, Glyphs) then
TotalGlyphs := Length(Glyphs);
// Bízzon a szerkezetfában csak akkor, amikor az az oldal nagyobb részét igényli
if (TotalGlyphs = 0) or (Untagged * 4 <= TotalGlyphs) then
begin
UsedStructure := True;
Result := True;
Exit;
end;
end;
Result := Pdf.ExtractLoadedPageText(PageIndex, AText);
end;Mitől ad vissza a függvény False-t
Három eset, és érdemes megkülönböztetni őket, mert csak egyikük hiba a dokumentumban. Az első egy hétköznapi címkézetlen PDF: nincs /StructTreeRoot, nincs mit bejárni, és a False egyszerűen az igazság. A második egy szkennelt oldal, amelynek szövege egy soha nem címkézett OCR rétegből jön. A harmadik az érdekes: olyan tartalom, amely BDC operátorokat hordoz /MCID értékekkel, de amelynek oldalán nincs /StructParents bejegyzés, és amelynek szerkezetfája soha nem hivatkozik azokra az azonosítókra. A megjelölt tartalom létezik, a szerkezetoldal nem, és nincs helyreállítandó sorrend. A HotPDF False-t jelent, nem kitalál egyet
Az utolsó eset kézzel szerkesztett fájlokban és olyan eszközök kimenetében mutatkozik meg, amelyek opcionális tartalom vagy artefakt céljából bocsátanak ki megjelölt tartalmat anélkül, hogy szerkezetfát építenének. Ha Ön maga állít elő címkézett PDF-eket, ugyanaz az aszimmetria az, amit a PDF/UA validáció ellenőriz, és az íróoldali megfelelőjét a címkézett, lapozott kimenetet bocsátó layout DOM tárgyalja
Hol térül meg a szerkezetsorrend
Az akadálymentesítési audit a kézenfekvő: ha PDF/UA szerint tanúsít egy dokumentumot, azt az olvasási sorrendet, amelyet egy képernyőolvasó be fog jelenteni, pontosan a szerkezetsorrend adja, tehát annak kinyerése az a mód, ahogyan képernyőolvasó nélkül nézheti át. Az adatbefogás a nagyobb kereskedelmi eset. A címkézett kormányzati űrlapok, szabályozott közlések és e-számla mellékletek mezőcímkéket és értékeket hordoznak kinyilvánított sorrendben, és azoknak abban a sorrendben való olvasása eltávolít egy egész hibaleképezési osztályt, amelyet a geometriai kinyerés a többhasábos elrendezéseken létrehoz
A legújabb fogyasztó a nyelvi modellek visszakeresése. Egy dokumentum darabolása beágyazáshoz csak annyira jó, mint a szövegsorrend, és egy darab, amely két hasábot vág össze, soha nem létezett mondatokat állít elő. A szerkezetsorrendű kinyerés a legolcsóbb elérhető javítás erre, mert címkézett dokumentumok esetén a helyes sorrend már a fájlban van, és csak ki kell olvasni
A HotPDF natív VCL komponens Delphi és C++Builder rendszerekhez, tehát a szerkezetfa-bejárás és a glífavisszajátszás is a saját folyamatában fut egy betöltött dokumentumon, külső renderelő nélkül. A betöltött dokumentum kinyerőcsalád teljes API részletei a HotPDF Delphi PDF component terméklapon találhatók