Як 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 (той самий відкритий рендерер, який використовує всередині Chrome) растеризує сторінку, а ONNX Runtime запускає модель PP-OCRv6 Small, щоб її прочитати. Обидва типи сторінок зшиваються по порядку в один документ Markdown, тому відповідь має тип text/markdown, а завантажуваний файл закінчується на .md.

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

Якщо вам потрібен PDF із пошуком по тексту (зображення плюс текстовий шар), цей endpoint такого не дасть. Він дає текст, який агент або конвеєр даних може використати напряму.

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. Справжня перевірка відбувається в момент, коли запит запускає розпізнавання: якщо чогось із цього бракує, endpoint повертає 503, а не деградований Markdown, який тихо відкочується до самого лише нативного тексту. Сама модель PP-OCRv6 Small важить близько 31 МБ; якщо її заздалегідь не завантажили в локальний кеш під час розгортання, вона довантажується мережею при першій реальній потребі в розпізнаванні. Офлайн-машина без попередньо завантаженої моделі, найімовірніше, впаде саме на першому запиті з Force, а не просто працюватиме повільніше.

Розпізнавання має ймовірнісний характер

Рушії зіставляють візерунки пікселів із моделями літер і слів. Вони добре працюють на чистому, контрастному друці стандартним шрифтом і гірше на:

• сканах низької роздільності чи низького контрасту (якість факсу проти оригіналу на 300 DPI);
• рукописі, декоративних шрифтах, незвичній верстці (багатоколонкові таблиці, повернутий текст, щільні форми);
• перекошених сторінках, які спотворюють форми гліфів рівно настільки, щоб збити зіставлення.

Розмитий факс не розпізнається так, як чистий скан, незалежно від Auto чи Force. Це обмеження самої моделі, а не те, що можна виправити якимось параметром.

Чого OCR не робить

OCR дає вам текст. Він не відбудовує абзаци, заголовки, таблиці чи Word-документ, що переверстується. Редагована верстка — це задача конвертації поверх помилки розпізнавання, а не те саме, що прочитати скан.

Розпізнати PDF працює на сервері без облікового запису. Звантаження — Markdown. Якщо наявний текстовий шар виглядає неправильно, скористайтеся Force OCR, щоб Auto не довіряв цьому шару; а щоб перевірити, чи справді на конкретній машині встановлено PDFium і модель, надійніше надіслати справжній запит, ніж дивитися на перевірку можливостей — вона лише підтверджує, що endpoint існує, а не що його середовище виконання готове. Для ключів автоматизації та OpenAPI див. Розробникам.