Aspose.PDFからの撤退：Hubbleが選んだPDF-Word変換の最適解

これは Hubble Advent Calendar 2024 の13日目¹の記事です。

はじめに

株式会社Hubbleでバックエンドを担当している @ktrk-wks です。

Hubbleではドキュメントの変換や差分取得などに、Asposeシリーズを利用しています。今回も、Wordファイルの上にPDFファイルを重ねてバージョン管理ができるようにする機能をリリースするためAspose.PDFを利用しようとしましたが、それを諦めた経緯を書いてみようと思います。

Aspose.PDF for Javaの利用で、何が起きたのか

Aspose.PDFの利用は非常に簡単で、以下のソースコードで簡単にPDFからdocxへ変換することができます。

var document = new Document("/foo/bar.pdf");
var saveOptions = new DocSaveOptions();
saveOptions.setFormat(DocFormat.DocX);
saveOptions.setMemorySaveModePath("/tmp/aspose");
// デフォルト値はRecognitionMode.Textbox
saveOptions.setMode(RecognitionMode.Flow);
document.save("/foo/bar.docx", saveOptions);

ただし、以下の書式のせいでHubbleにおいては実用に耐えられませんでした。²

1. フッターヘッダーを再現せず、本文に組み込まれてしまう
2. RecognitionMode.Textbox³の場合、段落が全てテキストボックスで表現されて文章構造を再現しない
3. RecognitionMode.Flowの場合、1行1行の末尾に改行が挿入され文章構造を再現しない

通常Wordを利用してドキュメントを作成し、それをPDFに直していることからWordと大きく変わる文章構造の場合、再度全体的に整形を行わなくてはいけなくなります。

このように、テキストレイアウトや文書構造の再現性が低いことは、Hubbleの品質要件(ドキュメントの整合性、差分取得の容易さ、ユーザビリティ)を満たすには不十分でした。

リリースブロックの判断と代替案

HubbleではPdM・CS・QA・開発エンジニアの各目線から、お客様へ最適なソリューションを届けようと努力しています。
お客様が一番ご利用されているPDFからdocxへの変換ツールとしてAdobe Acrobatがあります。このツールにおいても完璧ではありませんが、少なくとも

1. ヘッダーフッターは再現される
2. 文章構造を一定程度、理解する

そこで新たな候補としてPDF Services APIを検証しました。
PDF Services APIは、Adobe社が提供しているPDF変換・操作のためのAPI群であり、特にAcrobatと同等の変換精度を期待できます。
Hubbleが目指す「高品質かつ実用的なPDF-Word変換」を実現する道筋できました。

おわりに

Hubbleは常に、「お客様にとってより良い体験は何か？」を問い続けています。
あるライブラリが簡単に導入できても、結果的にユーザー体験や運用効率を損ねるのであれば、それは最良の選択ではありません。

今回はAspose.PDFの採用を見送り、PDF Services APIへの切り替えを決断しましたが、この判断は「ユーザーが求める品質」に立ち返った結果です。引き続き、Hubbleは契約書管理クラウドサービスとして、より快適で確かなサービスを提供していきます。

明日はフロントエンドを担当している @KOHETs さんです。

1. 平日のみの投稿なので18日ですが、13日目の記事としています。 ↩

2. 利用ライブラリは、Aspose.PDF for Java 24.7 ↩

3. for Javaにドキュメントには存在せず、Aspose.PDF for .NETの方にドキュメントがあります。 ↩