Mammoth.js vs Pandoc WASM：Word から Markdown への変換はどちらが優れているか？

二つのパイプライン、二つの哲学

Mammoth は docx ファイル内の OOXML を読み取り、一つの目標――外観ではなくセマンティックな内容――を掲げてそれをたどります。認識した段落スタイルは HTML 要素になり、装飾と判断したもの――ほとんどの色、フォント、間隔、テキストボックス、図形――はすべて破棄されます。その結果、CMS に入れる前の後処理がほとんど要らない、評判のクリーンな HTML が得られます。

Pandoc は同じファイルをネイティブの docx リーダーで分解しますが、HTML を直接出力する代わりに、型付きの抽象構文木（AST）を構築します。docx、odt、epub、LaTeX など、すべてのリーダーが同じ木を生成し、すべてのライターがそれを消費します。この間接層があるからこそ、一度のパースから Markdown、HTML、reStructuredText、LaTeX、さらには新しい docx まで出力できるのです。

Mammoth の style map の仕組み

Mammoth の拡張ポイントは style map です。Word のスタイルを HTML 要素に対応づけるルールのリストで、たとえば特定のスタイルを持つ段落を h1 にする、カスタム文字スタイルの太字ランを strong にする、といった指定ができます。style map を使えば、コードに触れずに Mammoth を自社テンプレートに合わせられます。統制の取れた単一のソーステンプレートを持つチームが優れた結果を得られる主な理由は、ここにあります。

その代償として、map の外側、そして Mammoth のサポート対象外の機能は、問答無用で消えます。メモやブログ記事ならそれは利点です――出力はクリーンなままです。しかし脚注や数式の多い高密度なレポートでは、沈黙は金ならずです。

表、脚注、数式

最初の壁は表です。Mammoth は単純な表を素朴な HTML テーブルに変換しますが、入れ子の表はモデルの範囲外で、結合セルが無事に残ることもほとんどありません。Pandoc はファイルの表構造をすべて解析するため、行もセルもパースを生き残ります。その先はライター次第です。Markdown の pipe テーブルは結合セルをまったく表現できません――これは変換器ではなくフォーマット側の制限です――一方、HTML ライターはすべてのセルを含む表全体を保持します。

脚注も似た話です。Mammoth は注を文末に集め、そこへリンクで戻る形にします。Web で読む分には十分です。Pandoc は脚注を第一級のノードとしてモデル化し、本物の Markdown 脚注構文やネイティブの LaTeX 脚注を出力します。数式で差が最もはっきりします。Mammoth は Word の OMML 数式を変換しませんが、Pandoc は標準的な LaTeX 記法に変換します。

画像、リスト、変更履歴

画像は両方で扱えます。Mammoth はブラウザではデフォルトで data URI としてインライン化し、カスタムハンドラーへの差し替えも可能です。Pandoc はメディアを Markdown と並ぶフォルダーに展開するか、自己完結の単一ファイルが必要なときは base64 として埋め込みます。日常的な箇条書き・番号付きリストは、複数レベルの入れ子を含め、どちらのエンジンでも安定しています。

微妙なのが変更履歴です。Pandoc には accept、reject、all を選べる明示的な trackChanges オプションがあり、どの改訂状態を出力に載せるかを自分で決められます。Mammoth には改訂モデルがなく、すべての変更が承認されたかのようなテキストが出てきて、何が承認されたかの記録は残りません。法的レビューで Word の代わりになるツールはありませんが、選択肢をくれるのは片方だけです。

バンドルサイズと配信

サイズ差は忠実度の正直な代償です。Mammoth のブラウザバンドルは数百 KB 程度で、ページと一緒に読み込まれます。WebAssembly にコンパイルされた Pandoc は約 58 MB。初回利用時には確かなダウンロードになります。ただし Web Worker の中では、このコストは一度だけ支払えば済みます。当サイトはブラウザの Cache API にエンジンをキャッシュするため、初回以降の変換では Network パネルが空のままになり、オフラインでも動き続けます。

キャッシュは計算を変えます。ブラウザごとに一度だけダウンロードされ、その後はローカルバイナリのように振る舞うエンジンと、セッションごとに再ダウンロードするのとでは、まったく話が違います。毎日変換するチームにとって、一度きりのコストは、壊れた表を直し続ける時間に比べれば些細なものです。

出力の広さと引用

Mammoth が出力できるのは HTML と、少し手を加えれば Markdown――それだけです。Pandoc のライター群こそ AST の存在意義で、Markdown を生む同じパースから、Sphinx ドキュメント用の reStructuredText、学術誌投稿用の LaTeX、参照テンプレート経由でスタイルを整え直した docx を出力できます。引用で輪は閉じます。Pandoc は citeproc を文献目録と CSL スタイルに対して実行し、cite key をインラインの整形済み参照に解決します。Mammoth に相当するものはありません。

広さは入力形式にも及びます。Pandoc は odt、epub、HTML、LaTeX、Org などを読めるため、一つのエンジンでコンテンツパイプライン全体をカバーできます。Mammoth は設計上 docx の専門家であり、しかもとても優秀です。ただ、ハブの役目を期待してはいけません。

どちらを選ぶか

この二つは本当の競合ではありません。答える問いが違うのです。ドキュメントが単純で、バンドルの予算が厳しく、ターゲットが HTML か Markdown だけなら、Mammoth は優秀です。小さく、速く、予測可能で、テンプレートに合わせて調整した style map と組み合わせればなおさらです。

ソースファイルに脚注、数式、複雑な表、引用が含まれる場合、あるいは出力形式が三つ以上必要な場合は、Pandoc が正直な選択です。WebAssembly として実行すれば、両者が共有するゼロアップロードのプライバシーも保たれます。当サイトが Pandoc ルートを選んだのはまさにそのためです。忠実度を優先し、ダウンロードは一度だけ支払ってキャッシュする。いちばん手強いドキュメントを両方に投げて、出力に決めてもらいましょう。

続きを読む

• ブラウザ変換のプライバシー
• クラウド変換 vs ローカル変換