Wat mensen verbaast over het converteren van een document, is dat er geen pagina in het bestand is om te converteren. Een .docx bevat alinea's, stijlen en een opmerking over het papierformaat, en de pagina die u op het scherm ziet, wordt geproduceerd door een lay-out van een woord op het moment dat u het opent. Elk ander programma moet die lay-out opnieuw doen, met zijn eigen lettertypen en zijn eigen regelafbreking, en daarom geven twee converters twee verschillende paginatellingen van één bestand. Als u begrijpt dat één feit elke verrassing in de uitvoer verklaart, inclusief die waar een bijgehouden deletie waarvan u dacht dat deze verdwenen was, in de PDF verschijnt.
tl;dr: Een .docx is een zip van XML met echte structuur, dus koppen, alinea's en lijsten komen correct aan in plaats van afgeleid te worden. Wat niet komt, is het uiterlijk: lettertypen, kolommen, tabellen, tabstops, nummering en exacte afstand live in delen die een converter moet implementeren om een tekstverwerker te eren ter ere. Gemeten op echte invoer, worden bijgehouden deleties verwijderd, dus een bewerkt document leest als de laatste bewoording, een genummerde lijst komt terug met opsommingstekens, een tabel wordt zijn cellen in leesvolgorde en een tabblad wordt een spatie. West-Europese tekst geeft renders; Cyrillisch, Grieks, CJK en emoji niet, omdat de ingebouwde PDF-lettertypen Winansi zijn. de Word naar PDF-converter doet de zetwerk in uw browser.
Wat zit er in een .docx?
Een zip van XML-onderdelen, en een daarvan bevat alles wat hier telt.
Open een .docx met een archieftool en je zult vinden word/document.xml Naast een manifest, een relatiegedeelte, en meestal stijlen, lettertypen, thema's, nummeringsdefinities en instellingen. Het formaat is ECMA-376, met Microsoft Implementatie- notitie omschrijven wat er bovenop staat.
Het documentgedeelte is een opeenvolging van <w:p> elementen. Elk is een alinea, met optionele eigenschappen die zeggen welke stijl het gebruikt en of het bij een lijst hoort, en daarbinnen een reeks runs met de eigenlijke tekst in <w:t>.
Dat is echt beter dan wat een PDF biedt. In een PDF moet een alinea worden afgeleid uit de verticale opening tussen de regels, dat is waar de conversie in de andere richting Verliest kolommen en tabellen. Hier is een alinea een alinea omdat het bestand dat zegt, en een kop is een kop omdat de alinea een kopstijl noemt.
De vangst zit in de delen die een converter niet leest.
Waarom ziet het resultaat er niet uit zoals het in Word?
Omdat het uiterlijk is verspreid over delen die een tekstverwerker vormen, en de converter zet de tekst in plaats daarvan opnieuw.
De tekst staat in het documentgedeelte. De reden waarom uw tekst in Calibri verschijnt op 11 punt met 1.08 regelafstand is in styles.xml. de reden dat uw lijst "1., 2., 3." leest in plaats van "a., b., c." is in numbering.xml. Het thema dat de kopkleur levert, is in een ander deel opnieuw, en sectieeigenschappen bepalen marges, kolommen en paginagrootte per sectie.
Het eren van alles is het bouwen van een lay-outmotor met de semantiek van Word. Wat deze tool in plaats daarvan doet, is de structuur lezen en netjes uitleggen: Times Roman for Body Text, Times Roman Bold voor koppen, een marge van 56 punten, 1,4 regelafstand, in de paginagrootte die u kiest.
Dus de uitvoer is een leesbaar, correct geordend document dat niet op het origineel lijkt. Dat is een echte beperking en het is de moeite waard om duidelijk te zeggen in plaats van te begraven, omdat de mensen die op zoek zijn naar deze bekering in twee groepen vallen en er slechts één van hen wordt gediend. Als je de tekst als pdf wilt die iedereen kan openen, is dit juist. Als je wilt die pagina, met zijn lettertypen en zijn afstand, lees verder naar de sectie over de eigen export van Word.
Wat overleeft de conversie?
Structuur en leesvolgorde, betrouwbaar. Hier is de volledige lijst, afgemeten aan de code in plaats van aangenomen.
| grondstof | Resultaat |
|---|---|
| alinea | bewaard, in documentvolgorde |
| kopjes | bewaard, formaat op niveau, set vetgedrukt |
| Lijstitems | Tekst bewaard gebleven, markering vervangen door een kogel |
| Tafelcellen | bewaard als afzonderlijke alinea's in leesvolgorde |
| Bijgehouden verwijderingen | gedropt, zoals Word ze weergeeft |
| Tabbladen en regeleinden | een enkele ruimte worden |
| vet, cursief, kleur, lettertype | NIET GEVOERD |
| Images | NIET GEVOERD |
| Kopteksten, voetteksten, paginanummers | NIET GEVOERD |
| Voetnoten en eindnoten | NIET GEVOERD |
De bovenste helft van die tabel is waarom deze conversie nog steeds de moeite waard is om te doen: er hoefde niets in te worden geraden. De onderste helft is de prijs van het niet implementeren van Word.
Wat gebeurt er met bijgehouden veranderingen?
De verwijderingen verdwijnen, wat correct is, en het feit dat het moet worden gezegd, is het interessante deel.
Een document dat is bewerkt met wijzigingsvolging aan, houdt de verwijderde tekst in het bestand binnen <w:delText> binnen de <w:del> element. Word weet het niet als huidige tekst te laten zien. Een converter die elk tekstknooppunt bewandelt, doet dat niet, tenzij iemand erover nadenkt.
Gemeten op een paragraaf die oorspronkelijk "de deadline" las: 31 maart" en werd bewerkt tot "30 april":
with the rule: The deadline is 30 April.
without the rule: The deadline is 31 March30 April.
Elke versie van die zin die iemand ooit heeft getypt, rent samen, zonder ruimte ertussen. Op een contract of een aanbiedingsbrief is dit geen cosmetische bug: het publiceert de onderhandelingsgeschiedenis van het document aan degene die de PDF ontvangt.
Het is de moeite waard om te weten omwille van zichzelf, welk hulpmiddel je ook gebruikt. Als u een geconverteerd document naar buiten verzendt, controleer dan of een datum of een cijfer dat u hebt gewijzigd één keer wordt weergegeven in plaats van twee keer.
Wat gebeurt er met een genummerde lijst?
Het komt terug met een opsommingsteken, omdat de cijfers niet in de alinea staan.
Een lijstparagraaf draagt <w:numPr>, die wijst op een nummeringsdefinitie in een ander deel. Die definitie bevat het formaat, de startwaarde, de inspringingsniveaus en of deze lijst een vorige voortzet. De alinea zelf bevat de tekst en niets anders.
Dus een converter die alleen het documentgedeelte leest, weet dat de alinea een lijstitem is en niet welke markering het zou moeten bevatten. Een kogel renderen is de eerlijke standaard:
• First point
• Second point
Ordinary paragraph
Dit is van belang wanneer de cijfers betekenis hebben. "Zie stap 4" in een procedure, of een genummerde clausule in een overeenkomst, verliest zijn referentie. Als uw document afhankelijk is van de nummering, is deze conversie de verkeerde en is de eigen export van Word de juiste.
Wat gebeurt er met een tafel?
De cellen overleven, het raster niet.
Een tabelcel bevat <w:p> Elementen zoals al het andere, dus de tekst komt als gewone alinea's in leesvolgorde aan. Een tabel met twee kolommen met regio's en cijfers komt uit als:
Region | Q2 | EMEA | 412
Vier alinea's, de een na de ander, zonder dat er niets werd vastgelegd dat de eerste twee een koprij waren. Het dragen van de tabel betekent dat u kolombreedtes, rijstructuur, samengevoegde cellen en randen draagt, en vervolgens een raster aanlegt dat pagineert, wat een ander en veel groter gereedschap is.
Dit is dezelfde handel in beide richtingen. PDF naar Word maakt een tabel plat omdat de PDF er nooit een heeft gehad; Word naar PDF maakt het plat omdat het opnieuw opbouwen ervan een lay-out engine is. Het eerlijke advies in beide gevallen: als de tabel het punt is, screenshot het of houd het origineel.
Waarom is mijn tab-uitgelijnde lay-out ingestort?
Omdat een tabblad een positie-instructie is, en zonder tabstops, is er nergens om het te sturen.
<w:tab/> betekent "vooruitgang naar het volgende tabblad" en de stops worden gedefinieerd in de eigenschappen van de paragraaf of zijn geërfd van zijn stijl. Een converter die tekst met zijn eigen marges uiteenzet, heeft geen zinvolle stop om naar toe te springen, dus het tabblad wordt een enkele ruimte. Hetzelfde geldt voor <w:br/>piepsel
input: Name <tab> Value <br> Next line
output: "Name Value Next line"
Iedereen die een lijst met twee kolommen, een handtekeningblok of een eenvoudige inhoudsopgave met tabbladen heeft gemaakt, verliest de uitlijning volledig. Het is een van de meest voorkomende manieren waarop een geconverteerd document er verkeerd uitziet, en het is onzichtbaar in de bron: het bestand ziet eruit als gewone alinea's, want dat is het.
Als afstemming er toe doet, kan een echte tabel in het brondocument niet beter converteren, maar het mislukt in ieder geval duidelijker.
Welke tekens kunnen de ingebouwde PDF-lettertypen niet weergeven?
Alles buiten het West-Europese Latijn, en de mislukking zweeg vroeger over welk karakter de schuld had.
De PDF-norm definieert veertien basislettertypen die elke lezer heeft, en ze zijn gecodeerd met WinansiEncoding, een 256 tekensset gedocumenteerd in bijlage D van de PDF-specificatie. Het gebruik ervan betekent dat er geen lettertype hoeft te worden ingesloten, wat de uitvoer klein houdt, en het betekent dat het alfabet vast is.
getest met PDF-lib, de bibliotheek doet de tekening:
| Tekst | Resultaat |
|---|---|
Quarterly report |
blaver |
"Revenue" rose, he'd said met gekrulde citaten |
blaver |
| Een zin met em streepjes, u+2014 | blaver |
Chiffre d'affaires réalisé en Août |
blaver |
Total: €1,249.50 |
blaver |
Отчёт за квартал |
mislukt: WinAnsi cannot encode "О" (0x041e) |
Αποτελέσματα |
mislukt: WinAnsi cannot encode "Α" (0x0391) |
季度报告 |
mislukt: WinAnsi cannot encode "季" (0x5b63) |
四半期報告 |
mislukt: WinAnsi cannot encode "四" (0x56db) |
Revenue up 🚀 |
mislukt: WinAnsi cannot encode "🚀" (0x1f680) |
Frans, Duits, Spaans, Portugees, Italiaans en de Scandinavische talen zijn prima, net als het euroteken, krullende offertes en een em streepje. Russisch, Grieks, Chinees, Japans, Koreaans, Arabisch, Hebreeuws, Hindi en elke emoji niet.
De tool noemt nu het karakter in de fout in plaats van te zeggen dat het document niet kon worden geconverteerd, omdat "verwijder dit personage" advies is en "iets is misgegaan" is niet. Een document in een van die scripts heeft een converter nodig die een lettertype insluit dat het dekt, wat een grotere PDF en een andere tool betekent.
Waarom wordt een .doc-bestand geweigerd?
Omdat .doc en .docx verschillende formaten zijn die drie letters delen.
Een .docx is een zip van XML, geïntroduceerd in 2007. Een .doc is een samengesteld binair bestand in een lay-out die dateert uit het begin van de jaren negentig, waarbij de tekst tussen de structuren door een parser moet lopen. Het ene lezen is geen variatie op het lezen van de ander, het is een aparte implementatie.
Dus de converter controleert de extensie en zegt dat, in plaats van te falen op een onleesbare zip:
| File | wat het zegt |
|---|---|
.doc |
Dat is het oudere formaat. Open het en sla eerst op als .docx |
.rtf, .odt, .pages |
Geen Word-document. Exporteren als .docx |
.pdf |
al een pdf; gebruik de andere richting voor een bewerkbaar bestand |
Het openen van een .doc in Word, LibreOffice of Google Docs en opslaan als .docx duurt een paar seconden en is een conversie die de programma's goed doen.
Hoe worden de koppen gedimensioneerd en hoe diep gaan ze?
Op niveau, vet, met alles voorbij het derde niveau behandeld als het derde.
De stijlnaam wordt uit de alinea gelezen en genormaliseerd, omdat beide spellingen in het wild bestaan. Woord schrijft Heading1; verschillende documentgeneratoren schrijven heading 1. Beiden gaan op hetzelfde niveau en Title wordt behandeld als niveau één.
| Stijl in het bestand | Gebruikt niveau |
|---|---|
Title, Heading1, heading 1 |
1 |
Heading2 |
2 |
Heading3 |
3 |
Heading4 doorgaand Heading9 |
3 |
ListParagraph, BodyText, al het andere |
hoofdtekst |
Drie visuele niveaus is een opzettelijk stoppunt. Een vierde niveau dat zich onderscheidt van het derde, heeft ofwel een andere maatstap nodig, die begint te botsen met hoofdtekst, of een gewicht of stijlwijziging De basislettertypen leveren niet.
Hoeveel pagina's zal de pdf zijn?
Niet het getallenwoord liet je zien, en het verschil is geen bug.
Lijn breken is afhankelijk van het lettertype, dus dezelfde alinea in Times Roman op 12 punt beslaat een ander aantal regels dan in Calibri op 11. marges verschillen. Lijnafstand verschilt. Alles wat beslist waar een lijn eindigt, is veranderd, dus paginering verandert mee.
In een gemeten run, een document van één kop en tien alinea's van ongeveer veertig woorden elk uiteengezet als twee A4-pagina's: 39 regels op de eerste en 2 op de tweede, met de kop ingesteld op 20,4 punt vet tegen 12 punts hoofdtekst.
Het praktische gevolg is dat paginaverwijzingen breken. "Zoals beschreven op pagina 7" in een geconverteerd document kan nu pagina 6 of pagina 8 zijn. Een document dat zijn eigen pagina's kruist, moet worden geëxporteerd vanuit Word, waarbij de lay-out degene is waartegen de verwijzingen zijn geschreven.
Wanneer moet u in plaats daarvan de eigen export van Word gebruiken?
Wanneer het uiterlijk of de paginering deel uitmaakt van de inhoud. Dat is een kortere lijst dan het klinkt, maar de items erop zijn belangrijk.
| Gebruik Word's Export | Gebruik een omvormer |
|---|---|
| Een ontworpen document: briefhoofd, CV, rapport met branding | Een platte tekstdocument dat u als PDF nodig heeft |
| Alles met tabellen, afbeeldingen, kop- of voetteksten | notities, een artikel, een concept, een transcript |
| genummerde clausules of kruisverwijzingen pagina's | Elk document waar de leesvolgorde alles is wat u nodig heeft |
| Een document in een niet-Latijns script | Een document dat u liever nergens uploadt |
Word's-bestand, Opslaan als, PDF is een echte export: dezelfde lay-out-engine die de pagina tekende, schrijft de PDF, dus wat je ziet is wat je krijgt. Niets in een browser komt daar overeen, want niets in een browser heeft de lay-out van Word's lay-out.
Het pleidooi voor het converteren is de laatste rij van die tabel, plus geen woord bij de hand.
Waarom wordt dit uitgevoerd in de browser?
Omdat documenten de meest persoonlijke bestanden zijn die mensen converteren, en deze conversie heeft niets nodig dat een server heeft.
Het lezen van een zip, het ontleden van XML en het tekenen van tekst zijn allemaal dingen die een browser native doet. Het bestand wordt vanaf uw schijf in het tabblad gelezen, daar uitgepakt, daar neergelegd, daar in een PDF geschreven en als download teruggegeven. Geen enkel verzoek draagt het document en er wordt nergens een exemplaar achtergelaten.
De documenten in kwestie zijn contracten, CV's, medische brieven, juridische concepten en proefschriften. Het conventionele alternatief uploadt ze naar een service, converteert ze op een machine waar je niets vanaf weet, en bewaart ze voor een periode beschreven in een beleid dat niemand leest.
De limieten zijn eerlijk: alleen West-Europese tekst, geen afbeeldingen, geen opmaak buiten koppen en kogels. Ze zijn zichtbaar voordat je begint in plaats van achteraf ontdekt, wat de transactie waard is als het alternatief een mooier uitziende pdf is van een document dat je niet langer bedient.
