Как OCR читает сканированный PDF — и почему этот инструмент возвращает Markdown

Сканированный PDF хранит страницы как растровые изображения: это фотографии текста, а не выбираемые символы. OCR (optical character recognition, оптическое распознавание символов) смотрит на эти пиксели, угадывает, какие фигуры являются символами, и выдаёт настоящий текст. В PDF123 это работает как бесплатный инструмент в браузере и как POST /api/v1/misc/ocr-pdf; ответ — Markdown, а не перезаписанный PDF.

Скан остаётся картинкой

OCR не чистит, не повышает резкость и не заменяет растровое изображение. Чёткий скан, который OCR распознал неверно, всё равно выглядит чётким. Изображение никогда не было узким местом по качеству — им было распознавание: замените движок распознавания на той же партии сканов, и точность может резко измениться, хотя сами пиксели останутся прежними.

Классический OCR для PDF записывает второй, невидимый текстовый слой, выровненный под изображением, чтобы выделение и поиск попадали в нужные слова. Именно это показано на схеме, и именно так до сих пор работают многие настольные программы.

Что на самом деле возвращает этот эндпоинт

Маршрут OCR вызывает /api/v1/misc/ocr-pdf, который работает на отдельном Rust-крейте pdf-inspector (собранном с функцией ocr). Он не отдаёт модели распознавания весь PDF целиком. Сначала pdf-inspector классифицирует каждую страницу: на ней либо уже есть извлекаемый нативный текст, либо она представляет собой только изображение. Страницы с нативным текстом сохраняют этот текст как есть и никогда не попадают в модель распознавания; страницы-изображения проходят через конвейер распознавания — PDFium (тот же open-source рендерер, который использует внутри Chrome) растеризует страницу, а ONNX Runtime запускает модель PP-OCRv6 Small, чтобы её прочитать. Оба вида страниц сшиваются по порядку в один документ Markdown, поэтому ответ имеет тип text/markdown, а скачиваемый файл заканчивается на .md.

Этот контракт появился только в этой переработке. Раньше проект работал на бэкенде Java/Spring Boot, который вызывал OCRmyPDF — классический подход «изображение плюс скрытый текстовый слой» — и возвращал PDF. Переписав бэкенд на Rust, этот путь заменили целиком на выборочный OCR от pdf-inspector, и вместе с этим вывод сменился с PDF на Markdown. Старый Java-бэкенд с тех пор полностью удалён из репозитория — это не переключатель, который можно включить обратно.

Если нужен PDF с возможностью поиска (изображение плюс текстовый слой), этот эндпоинт такого не даст. Он даёт текст, который агент или конвейер данных может использовать напрямую.

Auto и Force OCR

В форме есть поле ocrType:

• Normal (всё, кроме force-ocr) отображается на Auto: использовать существующий текст там, где он уже есть в файле; запускать OCR на страницах только с изображениями. На чистом цифровом PDF Auto не загружает среду выполнения OCR.
• Force OCR (ocrType=force-ocr) заново запускает распознавание на каждой странице, включая страницы, где текстовый слой уже есть. На настоящих страницах только с изображениями вы платите временем, а не получаете дополнительную точность; зато проход игнорирует сломанный или неполный существующий слой.

По умолчанию в портале выбран Force OCR. Управления языком нет: оставшиеся коды tessdata от старого пути на Java игнорируются.

Разделение Auto/Force происходит внутри самого запроса, и ни портал, ни проверка возможностей API не выясняют это заранее. GET /api/v1/settings/get-endpoints-status всегда сообщает, что ocr-pdf включён, не проверяя на самом деле, установлены ли PDFium, ONNX Runtime и модель PP-OCRv6. Настоящая проверка происходит в момент, когда запрос запускает распознавание: если чего-то из этого не хватает, эндпоинт возвращает 503, а не деградировавший Markdown, который тихо откатывается к одному лишь нативному тексту. Сама модель PP-OCRv6 Small весит около 31 МБ; если она не была заранее загружена в локальный кэш при развёртывании, она скачивается по сети при первой реальной потребности в распознавании. Офлайн-машина без предзагруженной модели, скорее всего, упадёт прямо на первом запросе с Force, а не просто будет работать медленнее.

Распознавание вероятностно

Движки сопоставляют пиксельные шаблоны с моделями букв и слов. Они хорошо справляются с чёткой, контрастной печатью стандартным шрифтом и хуже — с таким:

• Сканы низкого разрешения или низкой контрастности (качество факса против исходника 300 DPI)
• Рукописный текст, декоративные шрифты, необычные макеты (многоколоночные таблицы, повёрнутый текст, плотные формы)
• Перекошенные страницы, которые искажают формы глифов ровно настолько, чтобы сбить сопоставление

Размытый факс распознаётся не так, как чёткий скан, независимо от Auto или Force. Это ограничение самой модели, а не то, что можно исправить каким-либо параметром.

Что OCR не делает

OCR даёт текст. Он не восстанавливает абзацы, заголовки, таблицы или переформатируемый документ Word. Редактируемая вёрстка — это задача конвертации поверх ошибки распознавания, а не та же работа, что чтение скана.

OCR для PDF работает на сервере без аккаунта. Скачивается Markdown. Если существующий текстовый слой выглядит неверно, используйте Force OCR, чтобы Auto не доверял этому слою; а чтобы проверить, действительно ли на конкретной машине установлены PDFium и модель, надёжнее отправить настоящий запрос, чем смотреть на проверку возможностей — она лишь подтверждает, что эндпоинт существует, а не что его среда выполнения готова. О ключах автоматизации и OpenAPI см. Разработчикам.