meerdere pdf's in 1 keer doorzoekbaar maken

[Anoniem: 874293]

Mijn vraag
ik krijg per maand +/-70 pdf's doorgestuurd. Om dit in een bepaald programma te kunnen gebruiken moeten het doorzoekbare pdf's zijn. Nu kan ik elke pdf 1 voor 1 open doen en converteren met PDf architect. maar ik vroeg me af of er een programmatje (website) bestaat waarbij ik die pdf's allemaal tegelijk kan selecteren en allemaal tegelijk kan omzetten.

Relevante software en hardware die ik gebruik
momenteel PDF architect maar dat is stuk per stuk te converteren
ik heb windows 8.1

[efan]

alle pdf's samenvoegen met http://www.pdfsam.org/ , dan heb je nog maar 1 document door te zoeken

[m3gA]

Ik weet niet hoe gevoelig de documenten zijn maar als je ze uploadt in Google Drive worden ze automatisch doorzoekbaar

https://support.google.com/drive/answer/3145835?hl=nl

Drive slaat gescande documenten als doorzoekbare pdf-bestanden op, zodat je ze later makkelijk kunt terugvinden.

En anders lokaal kun je Adobe Standard / Professional gebruiken. Kosten wel een aardige cent.

[ Voor 57% gewijzigd door m3gA op 18-04-2017 12:50 ]

[F_J_K]

Een PDF is standaard al doorzoekbaar. Of bedoel je OCR'en? (Karakterherkenning).

Ik ken PDF architect niet maar hun website zegt dat ze een batch functie hebben. Die kan je dan gebruiken. Hoe en wat weet ik niet maar dat zal misschien in de handleiding zijn te vinden.

[RiDo78]

Wat zit er in die PDF'jes? Zijn dat scans, foto's of zijn ze meer tekst-gebaseerd? En waar converteer je ze naar?

Het PDF-formaat zit namelijk vrij simpel in elkaar, maar de content kan erg wissellen. Als er plain-text in zit, dan is dat er vaak wel uit te halen. Bij een unicode-tekst is het wat lastiger, maar valt vaak wel iets voor te bouwen als de PDFjes telkens uit dezelfde bron komen (en hetzelfde font gebruiken). Wanneer het een afbeelding is wordt het lastiger, dan zul je met OCR aan de slag moeten.

[Anoniem: 874293]

RiDo78 schreef op dinsdag 18 april 2017 @ 17:19:
Wat zit er in die PDF'jes? Zijn dat scans, foto's of zijn ze meer tekst-gebaseerd? En waar converteer je ze naar?

Het PDF-formaat zit namelijk vrij simpel in elkaar, maar de content kan erg wissellen. Als er plain-text in zit, dan is dat er vaak wel uit te halen. Bij een unicode-tekst is het wat lastiger, maar valt vaak wel iets voor te bouwen als de PDFjes telkens uit dezelfde bron komen (en hetzelfde font gebruiken). Wanneer het een afbeelding is wordt het lastiger, dan zul je met OCR aan de slag moeten.

het zijn facturen en komen zo uit een facturatieprogramma. het is dus hoofdzakelijk tekst.

[DukeBox]

@ido @Anoniem: 874293 Dit is denk ik makkelijker:
Voor windows 8.x:
http://supportdownloads.adobe.com/detail.jsp?ftpID=5542
Daarna kan desktop search door PDF's heen zoeken (uiteraard wel includen in de indexer).

Persoonlijk vind ik google drive (zoals eerder door @m3gA gemeld) een betere optie.

[ Voor 11% gewijzigd door DukeBox op 18-04-2017 23:23 ]

[RiDo78]

Anoniem: 874293 schreef op dinsdag 18 april 2017 @ 22:23:
het zijn facturen en komen zo uit een facturatieprogramma. het is dus hoofdzakelijk tekst.

Het lijkt mij dat de oplossingen van @m3gA en @DukeBox wel kunnen wat jij zoekt. Mocht dat niet zo zijn, dan kun je overwegen om zelf een stukje software te bouwen. Zoals ik al zei, een PDF'je zit niet zo heel ingewikkeld in elkaar.

Om je een idee te geven... Een PDF-document bestaat ruwweg uit een verzameling objecten en een of meer indextabellen (xref). De Indextabellen kun je gebruiken, maar hoeft niet, je kunt ook zelf op objectheaders scannen. Minder efficient, maar voor kleine documenten prima te doen.

Een Indextabel heeft een header bestaande uit 2 nummers die het eerste indexnummer en het aantal entries aangeven. Elke entry bestaat uit 2 nummers, gevolgd door 'f' or 'n'. Een entry eindigend op 'f' is vrij/bestaat niet. Bij een entry eindigend op 'n' is het eerste nummer de lokatie in de file (bytewise vanaf de PDF-header) en het tweede de revisienummer van het object.
Elk object heeft een header, een body eventueel een stream en een trailer.
- de header bestaat uit 2 nummers en de tekst 'obj', bijvoorbeeld "23 0 obj".
- de body kan van alles zijn maar is meestal een dictionary met parameters.
- als er een stream in zit, dan begint die met 'stream', eindigt met 'endstream'. De lengte en encoding van de stream zit in de array van de body.
- de trailer is altijd 'endobj'
Referenties naar objecten kun je altijd herkennen aan 2 cijfers, gevolgd door de hoofdletter R. Dus '23 0 R" refereert naar '23 0 obj'.

Met de bovenstaande structuur in gedachten, kun je de PDF beginnen te ontcijferen. Zoek in de trailers naar de '/Root' entry, die wordt gevolgd door een referentie. Zoek dat object op en je krijgt een object met "/Type /Catalog" in de body. Ook vind je in de body een "/Pages" met een referentie. Daarmee kom je in de root van de pagina-btree. Je kunt hier referenties naar losse pagina's aantreffen (die hebben een "/Type/Page" in de body) en/of referenties naar andere btree-nodes (die hebben een "/Type/Pages" entry in de body). Elke pagina heeft een "/Contents" object of array en refereert naar een of meerdere objecten met de daadwerkelijke content.

Meestal is die content ingepakt met zlib (in PHP te decoderen met zlib_decode()). Als dat zo is, dan staat er in de body van het object een '/Filter /Deflate' entry. Maar soms heb je geluk en is het al plain text. Wanneer je de content kunt zien (eventueel na het decoderen) tref je de instructies aan die de pagina opbouwen. Die bestaan uit 0 tot 6 parameters gevolgd door een operator. De tekst-operators zijn TJ, Tj, ' en ". De laatste 3 zijn enkelvoudige strings, de eerste (TJ) is een array bestaande uit strings en spacing-correcties.

Strings heb je in 2 vormen: plain en encoded. Een plain-string herken je snel genoeg, dat is platte tekst tussen ( en ), of in geval van TJ: [ (dit)3( is)-5( een )1(string.)]. Een encoded string is lastiger. Die string bestaat overigens niet uit ASCII-hexcodes maar uit Glyph-ID's. Dus heb je informatie nodig uit de fontdescriptor om de mapping van GID naar Unicode te kunnen maken. Zoek dan de laatst gebruikte font-operator (Tf) en kijk naar de 1ste parameter. Dat is een die begint met /. Zoek die naam in de resources-dictionary van de pagina op en je vind het Font. Zoek in het font en alle gerefereerde objecten naar de 'ToUnicode' entry. Als die er is, kun je in dat object uitvinden hoeveel bytes 1 karakter heeft en welk Unicode teken die vertegenwoordigd. Wanneer de 'ToUnicode' entry ontbreekt, zul je het font moeten inlezen in een tool als http://www.glyphrstudio.com/online/ en zelf je ToUnicode moeten maken. Een encoded string herken je aan de < en > markering, of in het geval van TJ: [ <0003>-8<02d34f1a73> ].

Dat is dus het onttrekken van strings uit een PDF in een vogelvlucht. Voor meer informatie over het PDF-formaat, kun je ook het 1300 pagina's tellend PDF-reference gebruiken: http://www.adobe.com/cont...dfs/pdf_reference_1-7.pdf

[Anoniem: 874293]

Google drive is inderdaad een optie, al sta ik wel wat wantrouwig hiertegen over. Dus als iemand nog een andere oplossing weet hoor ik het graag :-)

dat van dukebox heb ik gedownload maar maakt geen verschil aan mijn pdf zelf.

[DukeBox]

Anoniem: 874293 schreef op dinsdag 18 april 2017 @ 23:46:
Google drive is inderdaad een optie, al sta ik wel wat wantrouwig hiertegen over. Dus als iemand nog een dat van dukebox heb ik gedownload maar maakt geen verschil aan mijn pdf zelf.

Dat is ook het hele idee.. je gebruikt dan de native search tools van windows. Uiteraard moeten de applicaties die je gebruikt wel overweg kunnen met de windows api's.

[ Voor 10% gewijzigd door DukeBox op 18-04-2017 23:50 ]

[DaCoTa]

RiDo78 schreef op dinsdag 18 april 2017 @ 23:42:
[...]

Het lijkt mij dat de oplossingen van @m3gA en @DukeBox wel kunnen wat jij zoekt. Mocht dat niet zo zijn, dan kun je overwegen om zelf een stukje software te bouwen. Zoals ik al zei, een PDF'je zit niet zo heel ingewikkeld in elkaar.

...

Dat is dus het onttrekken van strings uit een PDF in een vogelvlucht. Voor meer informatie over het PDF-formaat, kun je ook het 1300 pagina's tellend PDF-reference gebruiken: http://www.adobe.com/cont...dfs/pdf_reference_1-7.pdf

Not sure if serious, or...?

Voor dit soort taken zijn er al legio bibliotheken en applicaties beschikbaar. Op linux, bijvoorbeeld pdftotext, voor windows zijn er ongetwijfeld ook tools. Maar wat nog onduidelijk is, is hoe ze doorzoekbaar moeten zijn. Wil je gewoon een hit op een file als er een bepaalde tekst in voorkomt, of wil je meteen de PDF en inhoud zien?

En verder, wat voor ervaring heb je? Kun je een powershell script maken, heb je misschien linux ervaring, of kun je wat python, bijvoorbeeld? Hoe geautomatiseerd wil je het, want ik kan me voorstellen dat 70 attachments opslaan ook gaat vervelen.

[Anoniem: 874293]

ik heb geen ervaring met programmeren dus ondanks de uitgebreide uitleg van RiDo78 ga ik me daar niet aan wagen.
wat ik concreet wil doen: ik heb een programmatje gevonden op internet om facturen in pdf formaat om te zetten naar ubl zodat dit automatisch ingelezen kan worden in het boekhoudprogramma.
als ik de pdf'en gebruik zoals ik ze ontvang dan kan dat programmatje die pdf niet uitlezen.
De maker van het programmatje zegt "Wellicht kan de PDF converter op uw computer dit PDF bestand niet goed omzetten." dus ik zoek nu dus iets wat die pdf wel goed kan omzetten.
Als ik de pdf'en eerst upgeload heb naar google drive, lukt het wel, dus ik ben geneigd om die man te geloven dat het aan de pdf'en ligt.

[F_J_K]

Dan is PDF een zware onhandige omweg. Vraag de afzender om een factuur in (ook) een machine-leesbaar formaat. Zoals UBL of andere XML

[Anoniem: 874293]

het is een op maat geschreven pakket en jammer genoeg wordt er veel geld gevraagd om de factuur naar ubl of xml te exporteren.

[F_J_K]

Als ze willen dat je betaalt, dan kunnen ze toch een poging wagen aan te leveren cf. jouw verzoek? Of wil je als dienstverlener de facturen verwerken? Dan kan je misschien ipv. de factuur, de onderliggende database een export laten draaien. PDF is IMHO sowieso een omweg.

-

Er zijn diverse opties genoemd waar ik niet van zie waar je vastloopt - waarom voldeed het niet? Ga er van uit dat je in alle gevallen de configuratie zelf moet doen. Waarom werkt bijv. gebruik van (de trial van) een van de betere OCR-pakketten niet? Gebruik ik hier regelmatig, werkt vaak prima. Zeker als de PDF een voorspelbaar formaat heeft, dan kan je misschien ook direct in batchvorm de juiste info extracten.

Er is zwart/wit gesproken geen sprake van OCR, maar dezelfde tool is goed te gebruiken. Wikipedia: Data scraping dus.

[Jorgen]

Wat @F_J_K zegt: jij moet nu gaan converteren en/of OCR'en. Dan is het vele malen eenvoudiger als de verstuurder al meteen het juiste formaat aanlevert. Nu kan ik me voorstellen dat een bedrijf dat honderden of duizenden facturen per jaar verzendt, die facturen niet alleen voor jullie gaat aanpassen, maar wellicht hebben ze die optie gewoon. Dan kan jij het meteen inlezen en is er geen probleem meer.

[F_J_K]

Aanvulling op mijn post: er zijn naast trials van Finereader o.i.d. ook gratis alternatieven zoals inderdaad pdftotext te proberen. Sowieso goed om er verschillende te proberen, voor toevallig deze input.

Jorgen schreef op dinsdag 25 april 2017 @ 10:34:
Nu kan ik me voorstellen dat een bedrijf dat honderden of duizenden facturen per jaar verzendt, die facturen niet alleen voor jullie gaat aanpassen, maar wellicht hebben ze die optie gewoon. Dan kan jij het meteen inlezen en is er geen probleem meer.

Ik durf zelfs te stellen: als ze duizenden facturen sturen dan is het juist een goed idee om facturen ook in een gestructureerd formaat te kunnen sturen. Minder kans op fouten, sneller betaald krijgen, iedereen blij.

[Jorgen]

F_J_K schreef op dinsdag 25 april 2017 @ 10:38:
[...]

Ik durf zelfs te stellen: als ze duizenden facturen sturen dan is het juist een goed idee om facturen ook in een gestructureerd formaat te kunnen sturen. Minder kans op fouten, sneller betaald krijgen, iedereen blij.

Lijkt mij eigenlijk ook en dus geheel eens.