Форматы файлов OCR для исторических и рукописных документов

Сохранение культурного наследия посредством оцифровки вступило в эпоху возрождения. В то время как ранние системы оптического распознавания символов (OCR) были разработаны для обработки безупречных, машинно напечатанных документов двадцатого века, современные учреждения, занимающиеся культурным наследием, сталкиваются с гораздо более сложной и богатой задачей: средневековыми манускриптами, рукописной корреспонденцией XIX века, хрупкими иллюминированными листами и столетними реестрами.

Транскрибирование исторических документов больше не ограничивается извлечением простого ASCII‑текста. Оно требует захвата контекста — физической геометрии страницы, кривых базовых линий, коррекции просвечивания, маргиналий, аббревиатур и палеографической неопределённости. Эта специализированная область, часто относимая к распознаванию рукописного текста (Handwritten Text Recognition, HTR), сильно зависит от формата файлов, используемых для хранения и обмена как координатами изображений, так и текстовыми слоями.

Выбор неправильной схемы может удалить важные данные базовой линии, нарушить согласование с манифестами IIIF (International Image Interoperability Framework) или препятствовать долгосрочному цифровому сохранению. Ниже представлено окончательное руководство по ведущим форматам файлов OCR и HTR для исторических документов, их структурным преимуществам и тому, как определить правильный выбор для вашего архивного конвейера.

Историческая дилемма: почему Простой текст и стандартные PDF не работают

Машинный OCR часто выводит простые файлы .txt или “сэндвич‑PDF” с скрытыми текстовыми слоями под сканированием. Для исторических рукописей и курсивного почерка такие результаты не подходят по трем основным причинам:

1. Нелинейный текст и сложные макеты: Исторические писцы не придерживались аккуратных прямоугольных сеток. Текст стекает в поля, обтекает иллюминированные инициалы, переплетается с вставленными межстрочными исправлениями или проходит вертикально вдоль корешка.
2. Изогнутые и наклонные базовые линии: Курсивное письмо редко следует жёсткой горизонтальной оси. HTR‑движки, такие как Transkribus, Kraken и eScriptorium, полагаются на полилинейные базовые линии вместо ограничивающих рамок для интерпретации скриптов с большим количеством лигатур.
3. Палеографическая сложность и метаданные: Архивные исследования требуют отслеживания аббревиатур, исторических вариантов написания, повреждённых чтений и оценок уверенности на уровне строк. Стандартные форматы документов отбрасывают эту детализацию.

Чтобы сохранить достоверность оригинального артефакта, архивное сообщество опирается на структурированные схемы XML, разработанные для сохранения топологии макета вместе с транскрибированным текстом.

1. PAGE XML: Золотой стандарт для распознавания рукописного текста (HTR)

Разработанный исследовательской лабораторией PRImA (Pattern Recognition & Image Analysis), 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).
• Широкая программная экосистема: Она служит основной внутренней и экспортной схемой для флагманских HTR‑платформ, таких как Transkribus, eScriptorium, и Kraken.

2. ALTO XML: Сила библиотек и архивов

ALTO (Analyzed Layout and Text Object) — открытый стандарт XML, поддерживаемый Библиотекой Конгресса и широко используемый национальными библиотеками, включая Bibliothèque nationale de France (BnF) и Британскую библиотеку.

Основная архитектура

ALTO структурирует макет иерархически от Page до PrintSpace, далее TextBlock, TextLine и String (отдельные слова или токены). Часто он упаковывается в обёртку METS (Metadata Encoding and Transmission Standard) для связывания структурных метаданных с высокоразрешёнными оригинальными изображениями.

Ключевые преимущества и варианты использования

• Массовые рабочие процессы оцифровки: ALTO был разработан с учётом промышленного масштабирования оцифровки газет и книг. Он чисто кодирует атрибуты шрифтов, координаты на уровне слов, уверенность символов и пробелы.
• Современная поддержка HTR (ALTO 4): Ранние версии ALTO сильно опирались на прямоугольные координаты (HPOS, VPOS, WIDTH, HEIGHT). Однако, начиная с ALTO версии 4, схема ввела полигоны <Shape> и полилинейные базовые линии, закрывая функциональный разрыв с PAGE XML для рукописных материалов.
• Долгосрочное сохранение: Поскольку это официальный стандарт, поддерживаемый международными библиотечными консорциумами, ALTO гарантирует долгосрочную стабильность и совместимость архивного уровня.

3. hOCR: Веб-ориентированный, лёгкий стандарт

Созданный Томасом Бройелем, hOCR использует прагматичный подход: вместо создания полностью новой XML‑схемы он встраивает метаданные разметки и транскрипции непосредственно в семантический HTML/XHTML, используя микроформаты и атрибуты классов.

Пример типичного синтаксиса

<div class="ocr_page" id="page_1" title="bbox 0 0 2480 3508">
  <div class="ocr_carea" id="block_1_1">
    <p class="ocr_par" id="par_1_1">
      <span class=\"ocr_line\" id=\"line_1_1\" title=\"bbox 150 320 2200 410; baseline 0 -5\">\n        <span class=\"ocrx_word\" id=\"word_1_1\" title=\"bbox 150 325 380 405; x_wconf 92\">Incipit</span>\n      </span>
    </p>
  </div>
</div>

Плюсы и минусы для исторических материалов

• Плюсы: Браузеры могут отображать его нативно. Его легко преобразовать с помощью обычного CSS и JavaScript, и это формат экспорта по умолчанию для движков, таких как Tesseract.
• Минусы: Нативная поддержка сложных, свободных многоточечных базовых кривых ограничена. Хотя это практично для ранних печатных изданий (инкунабула или чистые листовки), hOCR сталкивается с проблемами при работе с хаотичными макетами рукописей и многослойными маргиналиями.

4. TEI-XML: Академический и цифровой гуманитарный эталон

Формат Text Encoding Initiative (TEI) не является строго форматом вывода OCR‑движка; скорее, это ведущий стандарт для критических цифровых изданий и научного представления литературных и исторических текстов.

Связывание OCR/HTR с TEI

Современные конвейеры редко останавливаются на простом распознавании символов. Учёные используют инструменты, такие как Transkribus TEI Exporter, или автоматизированные XSLT‑конвейеры для преобразования PAGE XML или файлов ALTO в TEI‑совместимый XML:

• Сокращения раскрываются (<choice><abbr>...</abbr><expan>...</expan></choice>).
• Удаления, вставки и почерки писцов формально классифицируются (<add>, <del>, <handShift>).
• Данные о макете сохраняются вместе с литературным анализом с помощью элементов <facsimile> и <surface>.

Если ваш исторический проект направлен на создание интерактивного критического издания или семантически поискового научного архива, преобразование ваших OCR/HTR‑данных в TEI‑XML часто является необходимым завершающим шагом.

Сравнительная матрица: форматы OCR/HTR в одном взгляде

Практические рекомендации: выбор вашего архивного конвейера

Для создания эффективного, устойчивого к будущим изменениям конвейера оцифровки:

1. Для чистых рукописных манускриптов и архивов: Стандартизируйте вашу транскрипцию и извлечение макета с помощью PAGE XML. Его расчёт базовой линии и построение полигональных контуров обрабатывают нестандартные почерки с минимальными потерями данных.
2. Для крупномасштабных библиотек и смешанных коллекций: Выберите ALTO XML (v4.2 или выше) в сочетании с METS. Это гарантирует бесшовную интеграцию в стандартные архитектуры цифровых репозиториев и системы управления цифровыми активами (DAMS).
3. Для веб‑представления и полнотекстовых поисковых индексов: Используйте hOCR или получайте лёгкие структуры GeoJSON/Web Annotation из PAGE XML для управления интерактивными IIIF‑просмотрщиками (например, Mirador или Universal Viewer) с живыми текстовыми наложениями в браузере.
4. Для научных изданий и палеографических исследований: Создайте ваш эталонный набор данных в формате PAGE XML, выполните распознавание и пропустите вывод через автоматический конвертер, чтобы сгенерировать TEI-XML для редакционной разметки.

Сопоставляя структурные возможности этих форматов с палеографическими требованиями вашего исходного материала, вы гарантируете, что каждый штрих, аббревиатура и исторический нюанс остаются читаемыми на протяжении веков.

Часто задаваемые вопросы (FAQ)

Q1. В чём фундаментальное различие между стандартным OCR и HTR? OCR распознаёт последовательную машинно напечатанную типографику, тогда как HTR (распознавание рукописного текста) использует глубокие нейронные сети для декодирования непрерывного, изменчивого человеческого почерка и изогнутых базовых линий.

Q2. Может ли Tesseract OCR создавать PAGE XML или ALTO‑вывод для исторических документов? Да, Tesseract может генерировать нативный ALTO XML и hOCR‑вывод, а сторонние обёртки могут преобразовать эти результаты в PAGE XML.

Q3. Почему базовые линии важнее ограничивающих рамок при транскрипции рукописного текста? Базовые линии отслеживают естественную, волнообразную линию человеческого почерка, позволяя программному обеспечению разделять перекрывающиеся восходящие и нисходящие элементы, которые сталкиваются внутри жёстких ограничивающих рамок.

Вопрос 4. Как стандарт IIIF взаимодействует с этими форматами OCR‑файлов? IIIF предоставляет изображения высокого разрешения через открытые веб‑API, в то время как такие форматы, как ALTO или PAGE XML, предоставляют координатные данные, которые можно преобразовать в аннотации поиска контента IIIF.

Вопрос 5. Какой формат файла проще всего напрямую преобразовать в поисковый PDF? Как hOCR, так и ALTO XML можно сочетать с оригинальными изображениями страниц для создания поисковых PDF‑файлов с двойным слоем с помощью таких инструментов, как OCRmyPDF.

См. также

• PDF/A-3 - Гибридный монстр? Встраивание оригинальных данных в ваш OCR
• Понимание форматов OCR‑файлов — объяснение HOCR vs ALTO vs PDF/A
• В чём разница между PDF и FDF?
• Для чего используется FDF? Понимание назначения формата данных форм
• PDF против Word: какой использовать и когда?