Convertisseur HWPX basé sur Pandoc - présentation d’un outil open source qui convertit md, html et docx en hwpx.

Développé après 9 ans dans un institut public de recherche pour résoudre les contraintes du travail sur les documents HWP.

Contexte de développement

• 2018 : à mes débuts en Python, tentative d’un convertisseur HML/HWPML basé sur des expressions régulières - https://github.com/msjang/md2hml
• Janvier 2025 : développement de hwpfy
  • compilation des rapports hebdomadaires d’environ 20 personnes à partir d’un wiki avec édition collaborative en temps réel
  • Wiki → export en DOCX → conversion en DOCX avec mise en forme de formulaire administratif (hwpfy) → ouverture dans l’application Hancom Hangul puis enregistrement en HWPX → partage en HWPX avec le service hiérarchiquement supérieur au sein de l’institut
• Décembre 2025 : pypandoc-hwpx
  • J’ai estimé avoir acquis assez d’expérience, alors j’ai pris le temps de le développer sérieusement.

Méthode de développement

1. J’ai créé un DOCX avec la mise en forme souhaitée, puis je l’ai enregistré en HWPX.
2. J’ai décompressé le DOCX et le HWPX générés pour examiner les fichiers XML, supprimer les attributs inutiles et les affiner. J’ai aussi vérifié qu’ils s’ouvraient correctement dans Word et dans l’application Hangul.
3. J’ai créé un document comparant les formats md, html, docx et hwpx. - https://github.com/msjang/pypandoc-hwpx/…
4. Au départ, je comptais demander à un LLM de coder à partir de format_comparison.md ci-dessus, mais j’ai réalisé que j’avais déjà un HWPX de référence contenant la bonne réponse.
5. Je l’ai construit en itérant plusieurs fois avec les retours d’Antigravity (Gemini Pro 3). Comme la sortie n’avait pas le format souhaité, j’ai inspecté le XML en détail pour fournir des retours précis. Je n’ai pas mentionné directement le document de comparaison des formats, mais le fait d’en avoir assimilé le contenu m’a beaucoup aidé pour la revue.

Travaux à venir

Je souhaite retirer Python de Pypandoc, coder cela en Haskell et contribuer un writer HWPX à Pandoc.

[roxie]

https://velog.io/@wjsdj2009/Lee Jun-seok et l’histoire d’un projet parallèle pour la présidentielle feat. Haksikmeokja-tc85y4ok

Il y a un article comme celui-ci ; vous pourriez peut-être essayer de contacter des responsables politiques… ?

[aer0700]

On dirait le genre d’outil que Hancom aurait dû développer en premier… du moins s’il a vraiment l’intention de se développer à l’international.

[vpark45]

J’encourage les contributions en Haskell !

[shuggie]

À l’origine, je comptais le développer tranquillement sur un ou deux mois, mais la vidéo d’actualité d’hier est sortie : https://youtu.be/8cSqPRsM_Yg, alors je l’ai créé en urgence.

[mse9000]

C’est super
Mais, sauf votre respect, le sens de conversion souhaité par le président ne serait-il pas plutôt
hwp* -> .md, docs, pdf plain text ... ? Le projet prend-il aussi en charge la conversion dans le sens inverse ?

[shuggie]

Il existe depuis longtemps de nombreuses bibliothèques pour parser hwp ou hwpx. Côté Java, celles-ci sont bien connues.
https://github.com/neolord0/hwplib
https://github.com/neolord0/hwpxlib

Il existe aussi un wrapper en Python de l’API win32 de Hancom. C’est celui qu’on voyait dans les premiers cours sur l’automatisation de HWP. En clair, on pilote l’application HWP pour Windows depuis le backend.
https://pypi.org/project/pyhwpx/

En Python, pour manipuler HWPX de façon autonome sans programme séparé, il y a aussi ceci. On peut lire ou remplacer du contenu, et même ajouter des paragraphes ou des tableaux. https://github.com/airmang/python-hwpx

Mais quand on y pense, aujourd’hui nous communiquons surtout avec des applications LLM. Nous accédons à ChatGPT, Claude et Gemini via un navigateur web et échangeons par chat. Même lorsqu’on exécute un modèle local avec OpenWebUI, on l’utilise via le navigateur. Et les résultats obtenus avec le mode vocal de l’application ChatGPT sur smartphone peuvent aussi être consultés sous forme d’historique de chat dans le navigateur. En outre, si l’on clique sur le bouton de copie d’une sortie de LLM puis qu’on la colle dans le Bloc-notes, on constate qu’il s’agit de markdown.

Les LLM produisent du markdown ou du HTML, mais existe-t-il une bibliothèque qui permette de convertir cela directement en hwpx pour l’enregistrer ? Non.

Quand on réfléchit à une idée de brevet avec GEMINI Pro, il demande parfois : « Voulez-vous que je vous en fasse un document ? ». Et lorsqu’on clique sur le bouton, un brouillon de descriptif de brevet est déjà créé dans Google Docs. Au fond, il s’agit simplement d’une conversion de markdown en document, mais le résultat est tout à fait présentable.

Qu’on le veuille ou non, la Corée du Sud a fait de HWP un standard pour la conduite des activités professionnelles et la communication. Et dans notre workflow, générer du HWP est, d’une certaine manière, une évidence.

Après avoir laissé le mode vocal de ChatGPT écouter tout le contenu d’une réunion, lorsqu’on lui demande par exemple « résume-le sous forme de compte rendu et envoie-le par e-mail aux participants » ou « transforme le brainstorming en brouillon de descriptif de brevet », l’idée est que la sortie devrait être en HWP.

Jusqu’à présent, il fallait que quelqu’un récupère le résultat du LLM depuis le navigateur, le copie dans l’application Hancom, ajuste soigneusement la mise en forme, l’espacement et la composition, puis finalise la mise en page.

À l’époque où GEMINI génère des documents Google Docs, ne devrait-on pas attendre des modèles et services LLM financés par l’argent public en Corée du Sud qu’ils produisent aussi du HWPX sans intervention humaine ?

J’avais ce besoin dans le cadre de l’automatisation de mon travail, et c’est pour cela que je l’ai créé.

[shuggie]

Une remarque en passant.

Le format HWP lui-même est assez facile à parser pour le convertir en texte. Google avait déjà créé dès les années 2000 un système en interne pour indexer des documents en coréen, et les projets open source mentionnés plus haut suffisent largement pour cela.

Si l’on applique aux h1 à h6 de HTML les styles de niveaux de plan 1 à 6 correspondants, on peut aussi préserver la hiérarchie du document lors de sa création.

Cela dit, HWP offre tellement de fonctionnalités dans l’éditeur, et ses utilisateurs se concentrent tellement sur l’apparence à l’impression papier, qu’ils n’ont pas fait l’effort d’appliquer des niveaux de plan (outline level) lorsqu’ils mettaient en forme leurs documents.

Un exemple très parlant : lorsqu’un institut enregistre en PDF un document HWP de 300 pages, aucun signet n’est généré. Même s’il s’agit d’un document électronique, il faut donc chercher en faisant défiler les pages. C’est extrêmement peu pratique. Et avec un PDF volumineux, même sur un très bon ordinateur, faire défiler rapidement le document pour le parcourir provoque de gros ralentissements.

Comme on ne peut pas se permettre ça lors d’une évaluation institutionnelle, on imprime alors des piles de rapports de plusieurs centaines de pages, en autant d’exemplaires que de membres du jury, puis on procède à l’évaluation. Et une fois celle-ci terminée, tout est immédiatement jeté.

Dans les rapports étrangers, lorsqu’on reçoit un PDF de 400 pages, la table des matières fait à elle seule 16 pages et contient des liens permettant d’aller directement à la page correspondante d’un clic. En affichage du plan, les signets sont extrêmement détaillés et bien structurés. Cela signifie que ces informations ont été saisies facilement et générées automatiquement par l’outil, sans que l’utilisateur ait besoin d’y penser consciemment.

Bref, pour en revenir au sujet : à partir des fichiers HWP produits selon l’usage encore majoritaire d’Hangul Word Processor, on peut extraire le texte, mais il est difficile d’en tirer les informations de hiérarchie du document.

En revanche, si l’on génère du HWP avec un LLM sans intervention humaine, on peut tenir compte de ces éléments et les produire automatiquement.