Ik heb een rapport van twee pagina's naar Word geconverteerd om iets te controleren, en de tweede alinea kwam terug als volgt:
De omzet steeg in het derde personeelsbestand met vier, kwart op de rug van twee allemaal ter ondersteuning. De inhuur van grote verlengingen ondertekend in plan voor het vierde kwartaal augustus. marge plat gehouden. is ongewijzigd in zes rollen.
Twee kolommen volkomen gewoon proza, lees regel voor regel over de goot, dus elke zin wordt samengevoegd tot degene ernaast. Er was niets kapot. De converter deed precies wat een converter kan doen, en de kloof tussen dat en wat de zin "pdf naar woord" belooft, is het hele onderwerp van deze gids. Elke onderstaande output die hieronder werd geciteerd, kwam van het uitvoeren van de conversie, niet van het beschrijven ervan.
tl;dr: Een PDF slaat glyphs op coördinaten. Het slaat geen alinea's, kolommen, tabellen of koppen op, dus een converter moet ze afleiden uit posities, en sommige van die gevolgtrekkingen zijn verkeerd op een manier die u kunt voorspellen. Gemeten op een testrapport: twee kolommen die regel voor regel zijn doorgespitst, een tabel met vier rijen afgeplat tot één regel: "Regio Q2 Q3 EMEA 412 455 Amer 388 401 APAC 120 166", een kop samengevoegd in de paragraaf eronder, en een pagina zonder tekstlaag produceerde helemaal niets. Wat u betrouwbaar terugkrijgt, is bewerkbaar proza in paginavolgorde, wat voor de meeste banen is wat u wilde. de PDF naar Word-converter Doet het in de browser, dus het document wordt niet geüpload.
Wat staat er in een PDF?
Instructies voor het schilderen van een pagina, geen document.
Een inhoudsstroom van PDF's zegt dat dingen zoals "dit lettertype op dit formaat zetten, naar x 60, y 720, deze glyphs laten zien. de Specificatie zelf is een beschrijving van een schildermodel en de tekstoperators zitten naast die voor het tekenen van lijnen en het vullen van vormen. Er is geen object in het bestand dat "paragraaf" betekent, geen object dat "dit is een tabel" en niets dat vastlegt dat twee blokken tekst kolommen zijn in plaats van één breed. Het formaat is zo ontworpen dat een pagina overal identiek afdrukt, en het bereikt dat door de pagina te beschrijven als tekens in plaats van als inhoud.
Dus een converter ontvangt een lijst met gepositioneerde runs. pdf.js, de parser die dit loopt, geeft ze precies terug zoals de pagina ze tekent. In het testbestand produceerde pagina één er 34 van en pagina twee produceerde 4. Elke run is een tekenreeks met een x, een y, een breedte en een letterhoogte, en de volgorde waarin ze aankomen is de volgorde waarin de pagina is getekend, wat niet noodzakelijkerwijs de volgorde is die je zou lezen.
Alles wat een Word-document nodig heeft dat een PDF niet heeft, moet de converter uit die vier nummers reconstrueren. Die wederopbouw is het geheel van wat volgt, ook overal waar het fout gaat.
Hoe bouwt een converter alinea's opnieuw op van coördinaten?
In twee passen, met een drempel op elk.
De eerste doorgangsgroepen lopen in lijnen per basislijn: runs waarvan de Y-waarden binnen een halve lettertypehoogte van elkaar liggen, zijn één regel. De tweede groepeert lijnen in alinea's door de verticale opening ertussen. Een opening groter dan ongeveer 1,45 keer de gebruikelijke regelafstand begint een nieuwe alinea, waarbij "usual" de mediaanopening op die pagina is in plaats van een vast getal, dus de regel past zich aan een document aan dat is ingesteld in 9 punten of 14 punten.
Binnen een lijn is er een derde drempel. pdf.js splitst vaak een enkel woord over verschillende runs zonder opening tussen hen, dus het samenvoegen van runs op een spatie verandert "bestandsnaam" in "f i l e n a m e". De oplossing is om een spatie alleen in te voegen wanneer de horizontale opening een kwart van de letterhoogte overschrijdt, wat ongeveer de breedte van een echte woordruimte is.
Deze drie getallen bepalen bijna alles over de output. Als het resultaat goed is, hadden ze gelijk. Wanneer een kop zich aan de alinea eronder houdt, was het gat minder dan 1,45 keer de mediaan en de regel zei één alinea.
Waarom komen er twee kolommen uit elkaar?
Omdat het enige bewijs voor een kolom een horizontale opening is, en de lijngroepering kijkt eerst naar de verticale positie.
De twee blokken op mijn testpagina stonden op x 60 en x 320, met hun lijnen op gedeelde basislijnen. De groepering zag zes basislijnen, die elk tekst van beide kanten droegen en ze allemaal over de overkant aflezen. Het resultaat is de alinea bovenaan deze handleiding: elke regel van de linkerkolom direct gevolgd door de lijn ernaast.
Dit is hetzelfde mislukking als vervormde kolommen in OCR, en het heeft dezelfde hoofdmap: het lezen van volgorde is een oordeel over een lay-out, gemaakt van geometrie, door iets dat niet kan lezen.
Converters die kolommen goed verwerken, doen eerst een paginasegmentatiestap, op zoek naar een consistente verticale band van witruimte die de hoogte van de pagina loopt en de pagina daar splitst voordat een lijngroepering wordt uitgevoerd. Dat werkt op een krant of een dagboekblad, waar de goot breed en regelmatig is. Het is minder betrouwbaar in de veelvoorkomende gevallen, waarbij een zijbalk, een pull-aanhalingsteken of een tabel met twee kolommen de band breekt.
Als uw document kolommen heeft, is het praktische antwoord om de uitvoer te controleren en de eerste alinea van elke pagina te corrigeren, of om een kolom tegelijk te converteren als het document lang genoeg is om het waard te zijn.
Wat gebeurt er met een tafel?
Het wordt een zin.
Mijn testbestand had een tabel met vier rijen met drie kolommen. Hier is het geheel na conversie:
Region Q2 Q3 EMEA 412 455 AMER 388 401 APAC 120 166
Elke waarde overleefde. De structuur niet. Je kunt niet aan die regel zien dat 412 EMEA's Q2-figuur is zonder posities te tellen en de vorm van het origineel te kennen.
De reden is dat de meeste PDF's ook geen tabellen bevatten. Een tabel in een PDF is meestal tekst die op coördinaten wordt getekend met enkele lijnen eromheen, en de lijnen zijn grafische bewerkingen die niets in het bestand hebben dat ze verbindt met de tekst die ze insluiten. Een converter zou de uitlijning van de getallen moeten detecteren, een raster moeten afleiden en beslissen welke runs bij welke cel horen, wat een onderzoeksprobleem is in plaats van een te parseren.
Sommige PDF's hebben een echte structuur, via tags die zijn toegevoegd voor toegankelijkheid, en die converteren veel beter. Ze zijn een minderheid: getagde PDF's komen van een zorgvuldige export uit Word of InDesign, niet van een printdriver.
Als de tabel het gewenste ding is, kopieer het dan met de hand naar een spreadsheet, of converteer de PDF naar tekst en hervorm deze daar. Een geconverteerd Word-bestand geeft u geen cellen.
Waarom is mijn kop samengevoegd in de alinea?
Omdat de ruimte eronder niet groot genoeg was om de alinearegel te laten struikelen.
Op pagina twee van het testbestand, de kop "notes" zat 40 punten boven de hoofdtekst terwijl de lichaamslijnen 18 punten uit elkaar lagen. Die kloof is 2,2 keer de regelafstand, die ze had moeten splitsen, en dat deed het niet, omdat de mediaankloof op een pagina met slechts vier runs geen betrouwbare schatting van wat dan ook is. De output was:
Notes Note 14 covers intercompany revenue and the treatment of
deferred items carried over from the prior year.
Dit is de eerlijke vorm van het hele probleem. Drempelregels werken goed op een pagina met voldoende tekst om een basislijnritme vast te stellen en slecht op een schaarse. Een titelpagina, een kort briefje, een voorblad of een formulier komen vaak terug als één doorlopende alinea.
Het is ook het gemakkelijkste om achteraf op te lossen. Koppen zijn duidelijk voor een menselijke lezer, en het persen op de juiste plaats duurt een seconde, wat minder tijd is dan een hulpmiddel zou zijn om het goed te krijgen.
Wat gebeurt er met een gescande pagina?
Er komt niets uit, en dat is het juiste gedrag.
De derde pagina van mijn testbestand had helemaal geen tekstlaag, alleen een grijze rechthoek die voor een scan stond. PDF.js leverde nul runs op en de converter produceerde er nul alinea's voor.
De pagina wordt nog steeds geteld. Het verschijnt in het Word-bestand als een lege pagina, dus de pagina breekt nadat deze is uitgelijnd met het origineel, wat ertoe doet wanneer iemand werkt vanaf paginanummers. Een converter die het stilletjes liet vallen, zou elke latere pagina met één verschuiven.
Een PDF waarvan de pagina's alle afbeeldingen zijn, is een scan, en geen enkele converter kan er tekst uit halen omdat er geen tekst uit te halen is. Wat dat nodig heeft, is OCR, dat de afbeelding van de letters leest en gissingen naar de personages, en dat zijn eigen foutenpercentage oplevert. De gemeten versie van die handel is in De gids over wat OCR breekt: Tilt voorbij drie graden is wat een scan verpest, geen resolutie.
Een handige vuistregel: open de PDF en probeer een zin te selecteren met uw cursor. Als de tekst wordt gemarkeerd, kan een converter deze lezen. Als u een selectierechthoek over een afbeelding krijgt, heeft u eerst OCR nodig.
Wat zit er in de .docx die naar buiten komt?
Drie bestanden in een zip, en dat is echt alles wat nodig is.
A.Docx is een open verpakkingsarchief, gestandaardiseerd als ECMA-376: een zip met xml-onderdelen plus een manifest dat zegt wat elk onderdeel is. Microsoft's eigen Overzicht van het formaat loopt dezelfde drie delen. Het minimum dat als een Word-document wordt geopend, is drie vermeldingen:
| Part | voornemen |
|---|---|
[Content_Types].xml |
Verklaart het mediatype van elk onderdeel in het pakket |
_rels/.rels |
Punten bij het hoofddocumentgedeelte |
word/document.xml |
de inhoud zelf |
Al het andere dat een Word-bestand meestal bevat, is optioneel, stijlen, lettertypen, thema's, instellingen, nummeringsdefinities. Laat ze weg en de lezer past de standaardinstellingen toe.
Het testdocument, 83 woorden over drie pagina's, kwam tot een 1.305 byte .docx waarvan word/document.xml is 1.169 bytes. Ik opende het met de eigen documentlezer van Apple, wat tekstbewerking en pagina's gebruiken, en het maakte elke alinea in volgorde met de pagina-breuk intact. Een minimaal pakket is geen vernederd pakket.
Een detail in die XML is belangrijker dan het lijkt. Elke run is geschreven met xml:space="preserve". Zonder dit verliest een run dat begint of eindigt met een spatie het, en elke regel die in het origineel was gewikkeld, komt terug met zijn laatste woord dat is verbonden met het volgende.
Wat gebeurt er met de beelden?
Ze worden verwijderd en het Word-bestand vermeldt het niet.
Het hier geschreven pakket bestaat uit drie delen en geen van hen is een media-onderdeel. Een logo, een grafiek, een gescande handtekening, een screenshot ingesloten in het rapport: allemaal weg, zonder tijdelijke aanduiding waar ze waren. De tekst die hen omringde, sluit zich af alsof ze er nooit waren geweest.
Dit is een gevolg van hetzelfde ontwerp dat de output klein en betrouwbaar maakt. Het dragen van een afbeelding betekent het uit de PDF halen, het formaat bepalen, het schrijven in word/media/, een inhoudstype toevoegen, een relatieonderdeel toevoegen en een tekenelement op het juiste punt in de stroom plaatsen. Elk van deze is een plek voor een lezer om het bestand af te wijzen, en een .docx die een tekstverwerker weigert te openen, is erger dan dat een logo mist.
Het is het belangrijkst voor de documenten waar een afbeelding de inhoud is in plaats van decoratie. Een grafiek in een rapport converteert naar niets, en een lezer van het Word-bestand heeft geen manier om te weten dat er ooit een grafiek was. Controleer het origineel naast de conversie wanneer er naar een figuur wordt verwezen in het proza.
Waarom weigert het bestand soms überhaupt te openen?
Controletekens, die XML verbiedt en PDF's bevatten.
Een tekstlaag van een PDF pikt tekens op van alles wat het heeft geproduceerd: Form Feeds van een afdrukpijplijn, null bytes van een verbroken codering, andere C0-besturingscodes die niets betekenen in een document. XML 1.0 Staat de meeste van hen niet toe, zelfs niet ontsnapt: het karakterbereik dat de specificaties toestaan begint bij tab, newline en carriage return en slaat de rest van het C0-blok over.
De mislukking is niet sierlijk. Word waarschuwt of laat het personage niet vallen; het weigert het bestand te openen en zegt dat de inhoud onleesbaar is. Dus de converter stript die karakters voordat ze schrijft, in plaats van te proberen te ontsnappen. Ze hadden geen betekenis in de bron en ze zouden je het hele document kosten.
Als u ooit een .docx ontvangt die een tekstverwerker als onleesbaar afwijst, is dit het eerste dat u moet vermoeden, en daarom moet een converter die XML met de hand schrijft er überhaupt over nadenken.
Moet je converteren naar woord of naar platte tekst?
Word Als u het gaat bewerken, tekst als u het gaat verwerken.
Ze delen dezelfde extractie. Het verschil is alleen wat er aan het einde wordt geschreven: de ene schrijft alinea's in een zip van XML, de andere schrijft ze in een .txt-bestand.
| Je wilt | goed doen | aangezien |
|---|---|---|
| bewerk het proza en stuur het door | pdf naar woord | alineastructuur, pagina-einden, iets wat een collega kan openen |
| Zoek, grep of feed het naar een script | pdf naar tekst | Geen markering in de weg |
| Houd de lay-out precies | Noch | Bewerk de PDF of ontvang het originele bestand |
| Een scan lezen | OCR eerst | Er is geen tekstlaag om uit te extraheren |
De derde rij is degene die het waard is om mee te zitten. Als de lay-out het belangrijkste is, is converteren naar Word de verkeerde richting, omdat de conversie is waar de lay-out verloren gaat. Vraag degene die de pdf heeft gestuurd voor het bestand waaruit het is geëxporteerd. Er is één bericht voor nodig en het is de enige benadering die de opmaak behoudt.
Hoe lang duurt de conversie?
lang genoeg om het bestand te lezen, en niet meer.
Er is geen coderingsstap en geen beeldverwerking. Het werk is het ontleden van de PDF-structuur, het ophalen van de tekstinhoud van elke pagina, het groeperen van runs en het serialiseren van XML in een zip. Het testbestand duurde enkele milliseconden, wat geen nuttig getal is omdat het drie pagina's was. Een rapport van tweehonderd pagina's wordt begrensd door pdf.js die het parseren, wat ruwweg lineair is in het aantal pagina's en snel.
Wat je wel opvalt op een groot document is geheugen, omdat het hele bestand samen met de geparseerde structuur op het tabblad Browser wordt bewaard. Dat is het echte plafond hier in plaats van snelheid.
Wat moet je in de output controleren?
Vier dingen, in de volgorde waarin ze waarschijnlijk verkeerd zijn.
- De eerste alinea van elke pagina. Dit is waar kolomverlening en kopsamenvoegingen verschijnen.
- elke tafel. Bevestig dat de nummers aanwezig zijn, accepteer dan dat het raster weg is en bouw het opnieuw op als je het nodig hebt.
- Woorden die aan de lijneinden worden afgebroken. Een woord dat over een regel in de PDF wordt gebroken, komt terug met het koppelteken in het midden ervan.
- Paginatelling. Het moet overeenkomen met het origineel, inclusief eventuele lege of gescande pagina's.
Die lijst duurt even op een document van tien pagina's en is het verschil tussen een bestand dat je kunt verzenden en een die stilletjes een gesplitste zin bevat.
Waarom wordt dit uitgevoerd in de browser?
Omdat de documenten die mensen converteren contracten, verklaringen, brieven, medische resultaten en dingen onder embargo zijn.
De conversie is een parse en een zip, die een browser het beide perfect doet. Het bestand wordt van uw schijf in de pagina gelezen, daar geparseerd met pdf.js gecompileerd voor het web, samengevoegd tot een .docx in het geheugen en teruggegeven als download. Geen enkel verzoek draagt het document, er wordt niets opgeslagen op een server en er is niets dat iemand later kan verwijderen.
Het gebruikelijke alternatief is een site die uw PDF gebruikt, deze converteert op een machine waar u niets vanaf weet en u een link e-mailt. Voor een openbare folder is dat prima. Voor een arbeidsovereenkomst is het een beslissing die u niet bewust werd gevraagd.
De kosten zijn het geheugen van de tab op zeer grote bestanden en geen OCR aan de serverzijde voor gescande pagina's. Beide zijn zichtbare grenzen in plaats van stille, wat de handel waard is.
