Eine informelle Einführung in DOCX

Mit etwa einer Milliarde Menschen, die Microsoft Office verwenden, ist das DOCX-Format der beliebteste De-facto-Standard für den Austausch von Dokumentdateien zwischen Büros. Sein engster Konkurrent – ​​das ODT-Format – wird nur von Open/LibreOffice und einigen Open-Source-Produkten unterstützt und ist damit weit vom Standard entfernt. Das PDF-Format ist kein Konkurrent, da PDFs nicht bearbeitet werden können und keine vollständige Dokumentstruktur enthalten, sodass sie nur begrenzte lokale Änderungen wie Wasserzeichen, Signaturen und dergleichen vornehmen können. Aus diesem Grund werden die meisten Geschäftsdokumente im DOCX-Format erstellt; Es gibt keine gute Alternative, um es zu ersetzen.

Obwohl DOCX ein komplexes Format ist, möchten Sie es möglicherweise für einfachere Aufgaben wie Indizierung, Konvertierung in TXT und andere kleine Änderungen manuell analysieren. Ich möchte Ihnen genügend Informationen über die Interna von DOCX geben, damit Sie nicht auf die ECMA-Spezifikationen verweisen müssen, ein riesiges 5.000-seitiges Handbuch.

Der beste Weg, das Format zu verstehen, besteht darin, ein einfaches Ein-Wort-Dokument mit MSWord zu erstellen und zu beobachten, wie die Bearbeitung des Dokuments das zugrunde liegende XML ändert. Sie werden mit einigen Fällen konfrontiert, in denen das DOCX in MS Word nicht richtig formatiert wird und Sie nicht wissen warum, oder auf Fälle stoßen, in denen es nicht offensichtlich ist, wie die gewünschte Formatierung generiert wird. Dabei hilft es, genau zu sehen und zu verstehen, was im XML vor sich geht.

Ich habe ungefähr ein Jahr lang an CollabOffice, einem kollaborativen DOCX-Editor, gearbeitet und möchte etwas von diesem Wissen mit der Entwickler-Community teilen. In diesem Artikel werde ich die DOCX-Dateistruktur erklären und Informationen zusammenfassen, die über das Internet verstreut sind. Dieser Artikel ist ein Vermittler zwischen der riesigen, komplexen ECMA-Spezifikation und den einfachen Internet-Tutorials, die derzeit verfügbar sind. Sie finden die Dateien zu diesem Artikel im toptal-docx Projekt auf meinem Github-Konto.

Eine einfache DOCX-Datei

Eine DOCX-Datei ist ein ZIP-Archiv von XML-Dateien. Wenn Sie ein neues, leeres Microsoft Word-Dokument erstellen, ein einzelnes Wort „Test“ hineinschreiben und den Inhalt entpacken, sehen Sie die folgende Dateistruktur:

Obwohl wir ein einfaches Dokument erstellt haben, hat der Speichervorgang in Microsoft Word Standarddesigns, Dokumenteigenschaften, Schriftarttabellen usw. im XML-Format generiert.

Lassen Sie uns zunächst das nicht verwendete Zeug entfernen und uns auf document.xml konzentrieren, das die Haupttextelemente enthält. Wenn Sie eine Datei löschen, stellen Sie sicher, dass Sie alle Beziehungsreferenzen darauf aus anderen XML-Dateien gelöscht haben. Hier ist ein Code-Diff-Beispiel, wie ich Abhängigkeiten von app.xml und core.xml gelöscht habe. Wenn Sie ungelöste/fehlende Verweise haben, betrachtet MSWord die Datei als defekt.

Hier ist die Struktur unseres vereinfachten, minimalen DOCX-Dokuments (und hier ist das Projekt auf Github):

Lassen Sie es uns von hier aus von oben nach Dateien aufschlüsseln:

_rels/.rels

Dies definiert die Referenz, die MS Word mitteilt, wo nach dem Inhalt des Dokuments gesucht werden soll. In diesem Fall verweist es auf word/document.xml :

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> <Relationship Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/> </Relationships>

_rels/document.xml.rels

Diese Datei definiert Verweise auf Ressourcen wie Bilder, die in den Dokumentinhalt eingebettet sind. Unser einfaches Dokument hat keine eingebetteten Ressourcen, daher ist das Beziehungs-Tag leer:

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> </Relationships>

[Content_Types].xml

[Content_Types].xml enthält Informationen zu den Medientypen im Dokument. Da wir nur Textinhalte haben, ist es ziemlich einfach:

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types"> <Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/> <Default Extension="xml" ContentType="application/xml"/> <Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/> </Types>

document.xml

Schließlich ist hier das Haupt-XML mit dem Textinhalt des Dokuments. Ich habe der Übersichtlichkeit halber einige Namespace-Deklarationen entfernt, aber Sie finden die vollständige Version der Datei im Github-Projekt. In dieser Datei werden Sie feststellen, dass einige der Namespace-Referenzen im Dokument nicht verwendet werden, aber Sie sollten sie nicht löschen, da MS Word sie benötigt.

Hier ist unser vereinfachtes Beispiel:

 <w:document> <w:body> <w:pw:rsidR="005F670F" w:rsidRDefault="005F79F5"> <w:r><w:t>Test</w:t></w:r> </w:p> <w:sectPr w:rsidR="005F670F"> <w:pgSz w:w="12240" w:h="15840"/> <w:pgMar w:top="1440" w:right="1440" w:bottom="1440" w:left="1440" w:header="720" w:footer="720" w:gutter="0"/> <w:cols w:space="720"/> <w:docGrid w:linePitch="360"/> </w:sectPr> </w:body> </w:document>

Der Hauptknoten <w:document> stellt das Dokument selbst dar, <w:body> enthält Absätze und innerhalb von <w:body> sind Seitenabmessungen verschachtelt, die durch <w:sectPr> definiert werden.

<w:rsidR> ist ein Attribut, das Sie ignorieren können; Es wird von MS Word-Interna verwendet.

Schauen wir uns ein komplexeres Dokument mit drei Absätzen an. Ich habe das XML auf dem Screenshot von Microsoft Word mit denselben Farben hervorgehoben, damit Sie die Korrelation sehen können:

<w:pw:rsidR="0081206C" w:rsidRDefault="00E10CAE">
<w:r> <w:t xml:space="preserve">Dies ist der erste Absatz unseres Beispiels. Es ist standardmäßig linksbündig, und jetzt möchte ich </w:t> </w:r> vorstellen
    <w:r> <w:rPr>
    <w:rFonts w:ascii="Arial" w:hAnsi="Arial" w:cs="Arial"/>
    <w:color w:val="000000"/>
    </w:rPr> <w:t>etwas Fett</w:t>
    </w:r>
    <w:r> <w:rPr>
    <w:rFonts w:ascii="Arial" w:hAnsi="Arial" w:cs="Arial"/>
    <w:b/> <w:color w:val="000000"/>
    </w:rPr> <w:t xml:space="preserve">Text</w:t>
    </w:r>
    <w:r> <w:rPr> <w:rFonts w:ascii="Arial"
w:hAnsi="Arial" w:cs="Arial"/> <w:color w:val="000000"/> </w:rPr>
    <w:t xml:space="preserve">, </w:t>
    </w:r>
    <w:proofErr w:type="gramStart"/>
    <w:r> <w:t xml:space="preserve">und auch die</w:t> </w:r> ändern
    <w:rw:rsidRPr="00E10CAE"> <w:rPr><w:rFonts w:ascii="Impact" w:hAnsi="Impact"/>
    </w:rPr> <w:t>Schriftstil</w:t> </w:r>
    <w:r>
    <w:rPr> <w:rFonts w:ascii="Impact" w:hAnsi="Impact"/> </w:rPr> <w:t xml:space="preserve"> </w:t>
    </w:r>
    <w:r> <w:t>zu 'Auswirkung'.</w:t></w:r>
    </w:p>
    <w:pw:rsidR="00E10CAE" w:rsidRDefault="00E10CAE"> <w:r> <w:t>Dies ist ein neuer Absatz.</w:t> </w:r></w:p >
    <w:pw:rsidR="00E10CAE" w:rsidRPr="00E10CAE" w:rsidRDefault="00E10CAE">
    <w:r> <w:t>Das ist ein weiterer Absatz, etwas länger.</w:t> </w:r>
    </w:p>

Absatzstruktur

Ein einfaches Dokument besteht aus Absätzen, ein Absatz besteht aus Läufen (eine Reihe von Texten mit derselben Schriftart, Farbe usw.) und Läufe bestehen aus Zeichen (z. B. <w:t> ). <w:t> -Tags können mehrere Zeichen enthalten, und es können einige im selben Durchlauf vorkommen.

Auch hier können wir <w:rsidR> ignorieren.

Texteigenschaften

Grundlegende Texteigenschaften sind Schriftart, Größe, Farbe, Stil usw. Es gibt ungefähr 40 Tags, die das Aussehen des Textes angeben. Wie Sie in unserem Beispiel mit drei Absätzen sehen können, hat jeder Lauf seine eigenen Eigenschaften innerhalb von <w:rPr> , wobei <w:color> , <w:rFonts> und boldness <w:b> angegeben werden.

Es ist wichtig zu beachten, dass Eigenschaften zwischen den beiden Zeichengruppen, normaler und komplexer Schrift (z. B. Arabisch), unterscheiden und dass die Eigenschaften je nach betroffenem Zeichentyp ein anderes Tag haben.

Die meisten normalen Skript-Eigenschafts-Tags haben ein passendes komplexes Skript-Tag mit einem hinzugefügten „C“, das angibt, dass die Eigenschaft für komplexe Skripts gilt. Beispiel: <w:i> (kursiv) wird zu <w:iCs> , und das fette Tag für normale Schrift, <w:b> , wird zu <w:bCs> für komplexe Schrift.

Stile

Es gibt eine ganze Symbolleiste in Microsoft Word, die Stilen gewidmet ist: normal, kein Abstand, Überschrift 1, Überschrift 2, Titel und so weiter. Diese Stile werden in /word/styles.xml gespeichert (Hinweis: Im ersten Schritt in unserem einfachen Beispiel haben wir dieses XML aus DOCX entfernt. Erstellen Sie ein neues DOCX, um dies anzuzeigen).

Sobald Sie Text als Stil definiert haben, finden Sie im Absatzeigenschaften-Tag <w:pPr> einen Verweis auf diesen Stil. Hier ist ein Beispiel, wo ich meinen Text mit dem Stil Überschrift 1 definiert habe:

 <w:p> <w:pPr> <w:pStyle w:val="Heading1"/> </w:pPr> <w:r> <w:t>My heading 1</w:t> </w:r> </w:p>

und hier ist der Stil selbst aus styles.xml :

 <w:style w:type="paragraph" w:style> <w:name w:val="heading 1"/> <w:basedOn w:val="Normal"/> <w:next w:val="Normal"/> <w:link w:val="Heading1Char"/> <w:uiPriority w:val="9"/> <w:qFormat/> <w:rsid w:val="002F7F18"/> <w:pPr> <w:keepNext/> <w:keepLines/> <w:spacing w:before="480" w:after="0"/> <w:outlineLvl w:val="0"/> </w:pPr> <w:rPr> <w:rFonts w:asciiTheme="majorHAnsi" w:eastAsiaTheme="majorEastAsia" w:hAnsiTheme="majorHAnsi" w:cstheme="majorBidi"/> <w:b/> <w:bCs/> <w:color w:val="365F91" w:themeColor="accent1" w:themeShade="BF"/> <w:sz w:val="28"/> <w:szCs w:val="28"/> </w:rPr> </w:style>

Der xpath <w:style/w:rPr/w:b> gibt an, dass die Schriftart fett ist, und <w:style/w:rPr/w:color> gibt die Schriftfarbe an. <w:basedOn> weist MSWord an, den Stil „Normal“ für alle fehlenden Eigenschaften zu verwenden.

Eigentumsvererbung

Texteigenschaften werden vererbt. Ein Lauf hat seine eigenen Eigenschaften ( w:p/w:r/w:rPr/* ), aber er erbt auch Eigenschaften von Absatz ( w:r/w:pPr/* ), und beide können Stileigenschaften aus dem /word/styles.xml .

 <w:r> <w:rPr> <w:rStyle w:val="DefaultParagraphFont"/> <w:sz w:val="16"/> </w:rPr> <w:tab/> </w:r>

Absätze und Läufe beginnen mit Standardeigenschaften: w:styles/w:docDefaults/w:rPrDefault/* und w:styles/w:docDefaults/w:pPrDefault/* . Um das Endergebnis der Eigenschaften eines Charakters zu erhalten, sollten Sie:

1. Verwenden Sie standardmäßige Lauf-/Absatzeigenschaften
2. Lauf-/Absatzstileigenschaften anfügen
3. Hängen Sie lokale Lauf-/Absatzeigenschaften an
4. Hängen Sie Ergebnislaufeigenschaften über Absatzeigenschaften an

Wenn ich B an A „anhängen“ sage, meine ich damit, alle Eigenschaften von B zu durchlaufen und alle Eigenschaften von A zu überschreiben, wobei alle sich nicht überschneidenden Eigenschaften unverändert bleiben.

Eine weitere Stelle, an der sich Standardeigenschaften befinden können, ist das Tag <w:style> mit w:type="paragraph" und w:default="1" . Beachten Sie, dass Zeichen selbst innerhalb eines Laufs niemals einen Standardstil haben, also beeinflusst <w:style w:type="character" w:default="1"> keinen Text.

1554402290400-dbb29eef3ba6035df7ad726dfc99b2af.png)

Eigenschaften umschalten

Einige der Eigenschaften sind „Umschalt“-Eigenschaften, wie z. B. <w:b> (fett) oder <w:i> (kursiv); diese Attribute verhalten sich wie ein XOR-Operator.

Das heißt, wenn der übergeordnete Stil fett und ein untergeordneter Lauf fett ist, ist das Ergebnis normaler, nicht fetter Text.

Sie müssen viele Tests und Reverse-Engineering durchführen, um Toggle-Attribute korrekt zu handhaben. Werfen Sie einen Blick auf Abschnitt 17.7.3 der ECMA-376 Open XML-Spezifikation, um die formalen, detaillierten Regeln für Umschalteigenschaften zu erhalten.

Schriftarten

Schriftarten folgen denselben allgemeinen Regeln wie andere Textattribute, aber Standardwerte für Schriftarteigenschaften werden in einer separaten Themendatei angegeben, auf die unter word/_rels/document.xml.rels wie folgt verwiesen wird:

 <Relationship Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/theme" Target="theme/theme1.xml"/>

Basierend auf der obigen Referenz befindet sich der Name der Standardschriftart in word/theme/themes1.xml , innerhalb eines <a:theme> -Tags, a:themeElements/a:fontScheme/a:majorFont oder a:minorFont -Tags.

Die Standardschriftgröße ist 10, es sei denn, das w:docDefaults/w:rPrDefault -Tag fehlt, dann ist es Größe 11.

Textausrichtung

Die Textausrichtung wird durch ein <w:jc> -Tag angegeben, wobei vier w:val -Modi verfügbar sind: "left" , "center" , "right" und "both" .

"left" ist der Standardmodus; Text beginnt links vom Absatzrechteck (normalerweise Seitenbreite). (Dieser Absatz ist standardmäßig linksbündig ausgerichtet.)

Der "center" -Modus zentriert erwartungsgemäß alle Zeichen innerhalb der Seitenbreite. (Auch dieser Absatz veranschaulicht die zentrierte Ausrichtung.)

Im "right" -Modus wird Absatztext am rechten Rand ausgerichtet. (Beachten Sie, wie dieser Text an der rechten Seite ausgerichtet ist.)

Der Modus "both" setzt zusätzlichen Abstand zwischen Wörter, sodass die Zeilen breiter werden und die gesamte Absatzbreite einnehmen, mit Ausnahme der letzten Zeile, die linksbündig ausgerichtet ist. (Dieser Absatz ist eine Demonstration dessen.)

Bilder

DOCX unterstützt zwei Arten von Bildern: Inline und Floating.

Inline-Bilder erscheinen innerhalb eines Absatzes zusammen mit den anderen Zeichen, <w:drawing> wird anstelle von <w:t> (Text) verwendet. Sie können die Bild-ID mit der folgenden xpath-Syntax finden:

w:drawing/wp:inline/a:graphic/a:graphicData/pic:pic/pic:blipFill/a:blip/@r:embed

Die Bild-ID wird verwendet, um den Dateinamen in der Datei word/_rels/document.xml.rels , und sie sollte auf die gif/jpeg-Datei im Unterordner word/media verweisen. (Siehe die Datei word/_rels/document.xml.rels des Github-Projekts, in der Sie die Bild-ID sehen können.)

Schwebende Bilder werden relativ zu Absätzen platziert, um die herum Text fließt. (Hier ist das Beispieldokument des GitHub-Projekts mit einem schwebenden Bild.)

Schwebende Bilder verwenden <wp:anchor> anstelle von <w:drawing> . Wenn Sie also Text innerhalb von <w:p> löschen, seien Sie vorsichtig mit den Ankern, wenn Sie nicht möchten, dass die Bilder entfernt werden.

Tische

XML-Tags für Tabellen ähneln HTML-Tabellen-Markup– ist dasselbe wie <table>, Übereinstimmungen mit <tr> usw.

<w:tbl> , die Tabelle selbst, hat Tabelleneigenschaften <w:tblPr> , und jede Spalteneigenschaft wird durch <w:gridCol> innerhalb von <w:tblGrid> . Zeilen folgen nacheinander als <w:tr> -Tags und jede Zeile sollte dieselbe Anzahl von Spalten haben, wie in <w:tblGrid> angegeben:

 <w:tbl> <w:tblPr> <w:tblW w:w="5000" w:type="pct" /> </w:tblPr> <w:tblGrid><w:gridCol/><w:gridCol/></w:tblGrid> <w:tr> <w:tc><w:p><w:r><w:t>left</w:t></w:r></w:p></w:tc> <w:tc><w:p><w:r><w:t>right</w:t></w:r></w:p></w:tc> </w:tr> </w:tbl>

Die Breite für Tabellenspalten kann im Tag <w:tblW> angegeben werden, aber wenn Sie sie nicht definieren, verwendet MS Word seine internen Algorithmen, um die optimale Spaltenbreite für die kleinste effektive Tabellengröße zu finden.

Einheiten

Viele XML-Attribute in DOCX geben Größen oder Entfernungen an. Obwohl es sich innerhalb des XML um ganze Zahlen handelt, haben sie alle unterschiedliche Einheiten, sodass eine Konvertierung erforderlich ist. Das Thema ist kompliziert, daher würde ich diesen Artikel von Lars Corneliussen über Einheiten in DOCX-Dateien empfehlen. Die Tabelle, die er präsentiert, ist nützlich, allerdings mit einem kleinen Druckfehler: Zoll sollte pt/72 sein, nicht pt*72.

Hier ist ein Spickzettel:

Tipps zur Implementierung eines Layouters

Wenn Sie eine DOCX-Datei (z. B. in PDF) konvertieren, auf Leinwand zeichnen oder die Anzahl der Seiten zählen möchten, müssen Sie einen Layouter implementieren. Ein Layouter ist ein Algorithmus zum Berechnen von Zeichenpositionen aus einer DOCX-Datei.

Dies ist eine komplexe Aufgabe, wenn Sie ein Rendering mit 100-prozentiger Wiedergabetreue benötigen. Die Zeit, die benötigt wird, um einen guten Layouter zu implementieren, wird in Mannjahren gemessen, aber wenn Sie nur einen einfachen, begrenzten benötigen, ist dies relativ schnell erledigt.

Ein Layouter füllt ein übergeordnetes Rechteck, das normalerweise ein Rechteck der Seite ist. Es fügt Wörter aus einem Lauf einzeln hinzu. Wenn die aktuelle Zeile überläuft, beginnt sie eine neue. Wenn der Absatz für das übergeordnete Rechteck zu hoch ist, wird er auf die nächste Seite umgebrochen.

Hier sind einige wichtige Dinge, die Sie beachten sollten, wenn Sie sich für die Implementierung eines Layouters entscheiden:

• Der Layouter sollte sich um die Textausrichtung und den über Bildern schwebenden Text kümmern
• Es sollte in der Lage sein, verschachtelte Objekte, wie etwa verschachtelte Tabellen, zu handhaben
• Wenn Sie solche Bilder vollständig unterstützen möchten, müssen Sie einen Layouter mit mindestens zwei Durchgängen implementieren, der erste Schritt sammelt die Positionen schwebender Bilder und der zweite füllt den leeren Raum mit Textzeichen.
• Achten Sie auf Einrückungen und Abstände. Vor und nach jedem Absatz sind Abstände vorhanden, und diese Zahlen werden durch das w:spacing -Tag angegeben. Der vertikale Abstand wird durch w:after und w:before -Tags angegeben. Beachten Sie, dass der Zeilenabstand durch w:line angegeben wird, aber dies ist nicht die Größe der Zeile, wie man erwarten könnte. Um die Größe der Zeile zu erhalten, nehmen Sie die aktuelle Schrifthöhe, multiplizieren Sie sie mit w:line und dividieren Sie sie durch 12.
• DOCX-Dateien enthalten keine Informationen zur Paginierung. Sie werden die Anzahl der Seiten im Dokument nicht finden, es sei denn, Sie berechnen, wie viel Platz Sie für jede Zeile benötigen, um die Anzahl der Seiten zu ermitteln. Wenn Sie die genauen Koordinaten jedes Zeichens auf der Seite finden müssen, achten Sie darauf, alle Abstände, Einrückungen und Größen zu berücksichtigen.
• Wenn Sie einen voll funktionsfähigen DOCX-Layouter implementieren, der Tabellen verarbeitet, beachten Sie die Sonderfälle, wenn sich Tabellen über mehrere Seiten erstrecken. Eine Zelle, die einen Seitenüberlauf verursacht, wirkt sich auch auf andere Zellen aus.
• Das Erstellen eines optimalen Algorithmus zum Berechnen der Breite einer Tabellenspalte ist ein herausforderndes mathematisches Problem, und Textverarbeitungsprogramme und Layouter verwenden normalerweise einige suboptimale Implementierungen. Ich schlage vor, den Algorithmus aus der HTML-Tabellendokumentation des W3C als erste Annäherung zu verwenden. Ich habe keine Beschreibung des von MS Word verwendeten Algorithmus gefunden, und Microsoft hat den Algorithmus im Laufe der Zeit verfeinert, sodass verschiedene Versionen von Word Tabellen möglicherweise etwas anders anordnen.

Bei Unklarheiten: XML nachbauen!

Wenn es nicht offensichtlich ist, wie dieses oder jenes XML-Tag in MS Word funktioniert, gibt es zwei Hauptansätze, um es herauszufinden:

• Erstellen Sie Schritt für Schritt die gewünschten Inhalte. Beginnen Sie mit einer einfachen docx-Datei. Speichern Sie jeden Schritt in einer eigenen Datei, wie beispielsweise in 1.docx , 2.docx . Entpacken Sie jeden von ihnen und verwenden Sie ein visuelles Diff-Tool für den Ordnervergleich, um zu sehen, welche Tags nach Ihren Änderungen angezeigt werden. (Probieren Sie für eine kommerzielle Option Araxis Merge oder für eine kostenlose Option WinMerge aus.)

• Wenn Sie eine DOCX-Datei generieren, die MS Word nicht mag, arbeiten Sie rückwärts. Vereinfachen Sie Ihr XML Schritt für Schritt. Irgendwann erfahren Sie, welche Änderung MS Word für falsch befunden hat.

DOCX ist ziemlich komplex, oder?

Es ist komplex, und die Lizenz von Microsoft verbietet die Verwendung von MS Word auf der Serverseite zur Verarbeitung von DOCX – dies ist ziemlich Standard für kommerzielle Produkte. Microsoft hat jedoch die XSLT-Datei bereitgestellt, um die meisten DOCX-Tags zu handhaben, aber sie wird Ihnen keine 100-prozentige oder sogar 99-prozentige Wiedergabetreue geben. Prozesse wie Textumbruch über Bilder werden nicht unterstützt, aber Sie können die meisten Dokumente unterstützen. (Wenn Sie keine Komplexität benötigen, sollten Sie Markdown als Alternative verwenden.)

Wenn Sie über ein ausreichendes Budget verfügen (es gibt keine kostenlose DOCX-Rendering-Engine), können Sie kommerzielle Produkte wie Aspose oder docx4j verwenden. Die beliebteste kostenlose Lösung ist LibreOffice zum Konvertieren zwischen DOCX und anderen Formaten, einschließlich PDF. Leider enthält LibreOffice während der Konvertierung viele kleine Fehler, und da es sich um ein ausgeklügeltes Open-Source-C++-Produkt handelt, ist es langsam und schwierig, Probleme mit der Wiedergabetreue zu beheben.

Wenn Sie DOCX-Layout zu kompliziert finden, um es selbst zu implementieren, können Sie es alternativ auch in HTML konvertieren und einen Browser zum Rendern verwenden. Sie können auch einen der freiberuflichen XML-Entwickler von Toptal in Betracht ziehen.

DOCX-Ressourcen zum Weiterlesen

• ECMA DOCX-Spezifikation
• OpenXML-Bibliothek für DOCX-Manipulation von C#. Es enthält keine Informationen zum Layout oder Rendering von Code, bietet jedoch eine Klassenhierarchie, die jedem möglichen XML-Knoten in DOCX entspricht.
• Sie können Stackoverflow jederzeit mit Schlüsselwörtern wie docx4j, OpenXML und docx suchen oder fragen; Es gibt Leute in der Community, die sich auskennen.