Pandoc-basierter Konverter für Hangeul Word Processor – Vorstellung eines Open-Source-Tools, das `md`, `html` und `docx` in `hwpx` umwandelt.

 (github.com/msjang)
26 Punkte von shuggie 2025-12-19 | 7 Kommentare | Auf WhatsApp teilen

Ich arbeite seit 9 Jahren an einem staatlichen Forschungsinstitut und habe dieses Tool entwickelt, um die Unbequemlichkeiten bei der Arbeit mit HWP-Dokumenten zu lösen.

Entwicklungshintergrund

  • 2018: Als Python-Anfänger habe ich einen auf regulären Ausdrücken basierenden HML/HWPML-Konverter versucht – https://github.com/msjang/md2hml
  • Januar 2025: Entwicklung von hwpfy
    • Zusammenführung der wöchentlichen Arbeitsberichte von rund 20 Personen auf Basis eines Wikis mit Echtzeit-Kollaboration
    • Wiki → Export nach DOCX → Umwandlung in ein DOCX mit Verwaltungsformular (hwpfy) → in der Hangeul-App öffnen und als HWPX speichern → als HWPX mit der übergeordneten internen Abteilung teilen
  • Dezember 2025: pypandoc-hwpx
    • Ich hatte das Gefühl, inzwischen genug Erfahrung gesammelt zu haben, und habe mir daher bewusst Zeit genommen, um es ernsthaft zu entwickeln.

Entwicklungsmethode

  1. Ich habe ein DOCX im gewünschten Format erstellt und als HWPX gespeichert.
  2. Ich habe das erzeugte DOCX und HWPX entpackt, die XML-Dateien untersucht, unnötige Attribute entfernt und alles bereinigt. Anschließend habe ich geprüft, ob sich die Dateien sowohl in Word als auch in der Hangeul-App korrekt öffnen lassen.
  3. Ich habe ein Dokument erstellt, das die Formate md, html, docx und hwpx vergleicht. – https://github.com/msjang/pypandoc-hwpx/…
  4. Ursprünglich wollte ich das oben genannte format_comparison.md verwenden, um ein LLM den Code schreiben zu lassen, aber dann wurde mir klar, dass ich mit der vorhandenen HWPX bereits so etwas wie einen Lösungsschlüssel hatte.
  5. Ich habe es mit wiederholtem Feedback in Antigravity (Gemini Pro 3) erstellt. Da das gewünschte Format zunächst nicht korrekt herauskam, habe ich die XML-Dateien bis ins Detail untersucht und gezieltes Feedback gegeben. Das Vergleichsdokument der Formate habe ich nicht direkt erwähnt, aber dass ich seinen Inhalt verstanden hatte, war bei der Überprüfung sehr hilfreich.

Was als Nächstes ansteht

Ich möchte Python aus Pypandoc herauslösen, in Haskell implementieren und einen HWPX-Writer zu Pandoc beitragen.

Verwandte Beiträge

7 Kommentare

 
roxie 2025-12-25

https://velog.io/@wjsdj2009/…

Es gibt so einen Artikel — vielleicht sollten Sie mal versuchen, Politiker zu kontaktieren ...?
 
aer0700 2025-12-20

Es wirkt wie etwas, das Hancom eigentlich selbst zuerst hätte entwickeln sollen ... sofern Hancom überhaupt den Willen hat, ins Ausland zu expandieren.
 
vpark45 2025-12-19

Ich unterstütze Haskell-Beiträge!
 
shuggie 2025-12-19

Ich wollte das ursprünglich über ein bis zwei Monate hinweg in Ruhe entwickeln, aber gestern kam die Meldung https://youtu.be/8cSqPRsM_Yg heraus, sodass ich es hastig fertiggestellt habe.
 
mse9000 2025-12-19

Großartig.
Wenn ich mir die Frage erlauben darf: Ist die vom Präsidenten gewünschte Konvertierungsrichtung nicht eher
hwp* -> .md, docs, pdf plain text ...? Unterstützt das Projekt auch die umgekehrte Konvertierung?
 
shuggie 2025-12-19

Es gibt seit Langem viele Bibliotheken zum Parsen von hwp oder hwpx. Im Java-Bereich ist diese hier bekannt.
https://github.com/neolord0/hwplib
https://github.com/neolord0/hwpxlib

Es gibt auch einen Wrapper für die Hancom-Win32-API in Python. Das ist das Ding, das in frühen Kursen zur HWP-Automatisierung auftaucht. Dabei steuert man im Backend die HWP-App für Windows.
https://pypi.org/project/pyhwpx/

Um HWPX in Python ohne separates Programm standalone zu verarbeiten, gibt es das hier. Man kann damit lesen oder ersetzen und auch Absätze oder Tabellen hinzufügen. https://github.com/airmang/python-hwpx

Wenn man darüber nachdenkt, kommunizieren wir meistens mit LLM-Apps. Wir greifen über den Webbrowser auf ChatGPT, Claude und Gemini zu und kommunizieren im Chat. Selbst wenn man mit OpenWebUI ein lokales Modell betreibt, nutzt man es über den Webbrowser. Auch die Ergebnisse aus dem Sprachmodus der ChatGPT-App auf dem Smartphone lassen sich im Webbrowser im Chatverlauf nachsehen. Und wenn man beim Output eines LLM auf Kopieren klickt und ihn in einen Texteditor einfügt, sieht man, dass es Markdown ist.

LLMs geben Markdown oder HTML aus, aber gibt es eine Bibliothek, die das direkt in hwpx umwandelt und speichert? Nein, gibt es nicht.

Wenn man mit GEMINI Pro über Patentideen nachdenkt, fragt es manchmal: „Soll ich daraus ein Dokument machen?“ Und wenn man auf den Button klickt, liegt schon ein Google-Docs-Dokument mit einem Entwurf der Patentschrift vor. Im Grunde wurde einfach Markdown konvertiert und als Dokument erstellt, aber das Ergebnis ist durchaus ansehnlich.

Südkorea hat HWP, ob man will oder nicht, zum Standard für Arbeitsabläufe und Kommunikation gemacht. Und innerhalb unseres Workflows ist das Erzeugen von HWP in gewisser Weise selbstverständlich.

Wenn man etwa nach dem vollständigen Anhören eines Meetings im Sprachmodus von ChatGPT sagt: „Fass das als Sitzungsprotokoll zusammen und schick es per E-Mail an die Teilnehmer“ oder „Mach aus dem Brainstorming einen Entwurf für eine Patentschrift“, dann sollte das Ergebnis HWP sein.

Bisher lief es so, dass Menschen die Ergebnisse des LLM aus dem Webbrowser in die Hancom-Textverarbeitung kopieren, das Format anpassen und dann mühsam Zeichenbreite, Zeichenabstand und Satz einstellen.

In einer Zeit, in der GEMINI Google Docs erzeugt, sollten LLM-Modelle und -Dienste, die mit südkoreanischen Steuergeldern entwickelt wurden, nicht eigentlich auch HWPX ohne menschliches Eingreifen erzeugen können?

Ich hatte diesen Bedarf für die Automatisierung meiner Arbeit und habe es deshalb gebaut.
 
shuggie 2025-12-19

Abschweifung.

HWP selbst lässt sich relativ leicht parsen und in Text umwandeln. Google hatte dafür bereits seit den 2000er-Jahren etwas entwickelt und intern eingesetzt, um koreanische Dokumente zu indizieren, und mit den oben erwähnten Open-Source-Projekten ist das völlig ausreichend möglich.

Wenn man die den h1 bis h6 in HTML entsprechenden Stile für Gliederungsebene 1 bis 6 anwendet, kann man Dokumente erstellen und dabei auch ihre Hierarchie bewahren.

Allerdings hat HWP im Editor zu viele Funktionen, und die Nutzer konzentrieren sich darauf, Formatierungen so anzuwenden, dass Ausdrucke auf Papier gut aussehen, statt sich die Mühe zu machen, Gliederungsebenen anzuwenden.

Das zeigt sich besonders deutlich daran, dass bei einem 300-seitigen HWP-Dokument aus einem Forschungsinstitut beim Speichern als PDF überhaupt keine Lesezeicheninformationen erzeugt werden. Deshalb muss man selbst bei einem elektronischen Dokument per Scrollen nach den Inhalten suchen. Das ist extrem unpraktisch. Und bei großen PDFs ruckelt selbst ein sehr guter Computer stark, wenn man zum schnellen Durchsehen rasch scrollt.

Weil man das bei einer Institutionsevaluierung nicht machen kann, werden Berichte mit mehreren hundert Seiten in der Anzahl der Gutachter ausgedruckt, stapelweise aufgeschichtet und so für die Evaluierung verwendet. Und direkt nach Abschluss der Bewertung werden sie weggeworfen.

Bei ausländischen Berichten bekommt man bei einem 400-seitigen PDF-Bericht allein 16 Seiten Inhaltsverzeichnis, und das Inhaltsverzeichnis ist verlinkt, sodass man per Klick direkt zur jeweiligen Seite springt. Wenn man die Gliederungsansicht öffnet, sind die Lesezeichen sehr fein unterteilt und gut aufgebaut. Das bedeutet, dass diese Informationen im Werkzeug leicht eingegeben werden konnten und automatisch erzeugt wurden, ohne dass Menschen sich dessen besonders bewusst sein mussten.

Wie auch immer, zurück zum eigentlichen Punkt: Aus HWP-Dateien, die aufgrund der nach wie vor von der Mehrheit genutzten Gewohnheit mit Hancom Hangul erstellt wurden, lässt sich zwar Text gewinnen, aber es ist schwierig, Informationen über die Dokumenthierarchie zu erhalten.

Wenn HWP jedoch mit einem LLM ohne menschliches Eingreifen erzeugt wird, kann man solche Punkte berücksichtigen und es automatisch entsprechend erstellen.