最終更新日: 2026年8月20日
歴史的および手書き文書のためのOCRファイル形式 デジタル化による文化遺産の保存はルネサンスに突入しています。初期の光学文字認識（OCR）システムは、清潔で機械印刷された20世紀の書類を解析するよう設計されていましたが、現代の文化遺産機関ははるかに混沌として豊かな課題に直面しています：中世の写本、19世紀の筆記体の書簡、脆い装飾写本、そして何世紀も前のレジストリです。
歴史的文書の転写は、もはや単にプレーンな ASCII テキストを抽出するだけではありません。コンテキスト—ページの物理的ジオメトリ、ベースライン曲線、裏写り補正、余白注、略語、そして古文字学的な不確実性—を捉える必要があります。この専門分野は、しばしば手書き文字認識（HTR）に分類され、画像座標とテキスト層の両方を保存・交換するために使用されるファイル形式に大きく依存しています。
誤ったスキーマを選択すると、重要なベースラインデータが失われ、IIIF（International Image Interoperability Framework）マニフェストとの整合性が崩れ、長期的なデジタル保存が妨げられる可能性があります。ここでは、歴史的文書向けの主要な OCR および HTR ファイル形式、その構造的な強み、そしてアーカイブパイプラインに最適な選択を判断する方法についての決定的なガイドを紹介します。
歴史的ジレンマ：なぜプレーンテキストと標準的なPDFが失敗するのか 機械印刷された OCR は、シンプルな .txt ファイルやスキャンの下に隠しテキスト層を持つ “sandwich” PDF を出力することが多いです。歴史的写本や筆記体の手書きに対しては、これらの出力は次の 3 つの根本的な理由で失敗します：
非線形テキストと複雑なレイアウト: 歴史的な写本家は整然とした長方形のグリッドに従わなかった。テキストは余白に流れ込み、装飾されたイニシャルの周りを回り、挿入された行間訂正の間を織り交ぜ、または背表紙に沿って垂直に走る。 曲線的かつ斜めのベースライン: 手書き文字は硬直した水平軸に従うことはほとんどない。Transkribus、Kraken、eScriptorium などの HTR エンジンは、リガチャが多いスクリプトを解釈するために、バウンディングボックスではなくポリラインベースラインに依存している。 古文字学的複雑性とメタデータ: アーカイブ研究では、略語、歴史的な綴りの変化、損傷した読取、行レベルの信頼度スコアを追跡する必要がある。標準的な文書フォーマットはこの粒度を破棄してしまう。 元の遺物への忠実性を保つために、アーカイブコミュニティは転写テキストと共にレイアウトトポロジーを保存するよう設計された構造化 XML スキーマに依存している。
1. PAGE XML: 手書き文字認識（HTR）のゴールドスタンダード PRImA（パターン認識＆画像解析）研究所が開発した PAGE XML（Page Analysis and Groundtruth Elements）は、手書き文字認識と高度なレイアウト分析のための最先端フォーマットとして広く認識されている。
コアアーキテクチャ PAGE XML は物理文書を階層構造として扱う：
PcGts（ルート） Page (画像の寸法と全体の読順) TextRegion (段落、見出し、余白注、キャッチワード) TextLine Coords (ライン周囲のポリゴン座標) Baseline (文字の実際のベースラインに沿った点の列) TextEquiv (認識されたテキスト、オプションで信頼度メトリクス付き) 歴史的写本において優れている理由 ポリゴンとポリラインの精度: 文字を矩形のバウンディングボックスに強制的に入れる代わりに、PAGE XML は複数点のポリゴン境界と連続したベースラインを使用します。これにより、重なり合う筆記体の上昇部や下降部がセグメンテーションの妨げになるのを防ぎます。 細分化された構造タイプ: 領域は正確に分類できます（例：marginalia、drop-capital、signature-mark、header、editorial-note）。 広範なソフトウェアエコシステム: これは、Transkribus、eScriptorium、Kraken のような主要な HTR プラットフォーム向けの、内部およびエクスポート用の主要スキーマとして機能します。 2.