Как OCR чете сканиран PDF и защо този инструмент връща Markdown

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

Сканът си остава снимка

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

Класическият PDF OCR записва втори, невидим текстов слой, подравнен под изображението, така че маркирането и търсенето да попадат на правилните думи. Това показва диаграмата и така още работят много настолни инструменти.

Какво всъщност връща тази крайна точка

Маршрутът 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 с търсене (изображение плюс текстов слой), тази крайна точка не може да ви го даде. Тя ви дава текст, който агент или конвейер за данни може да използва директно.

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 като „enabled“, без реално да проверява дали PDFium, ONNX Runtime и моделът PP-OCRv6 са инсталирани. Реалната проверка се случва едва когато заявка задейства разпознаване: ако нещо от изброеното липсва, крайната точка връща 503, а не деградирал Markdown, който тихо се връща само към нативен текст. Самият модел PP-OCRv6 Small тежи около 31 MB; освен ако не е предварително зареден в локалния кеш при разгръщането, той се изтегля по мрежата при първата реална нужда от разпознаване. Офлайн машина без предварително зареден модел най-вероятно ще се провали още на първата Force заявка, вместо просто да работи по-бавно.

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

Машините съпоставят шаблони от пиксели с модели на букви и думи. Справят се добре при чист, висококонтрастен печат със стандартен шрифт и по-лошо при:

• Сканирания с ниска резолюция или нисък контраст (качество на факс срещу оригинал при 300 DPI)
• Ръкопис, декоративни шрифтове, необичайни оформления (таблици с много колони, завъртян текст, гъсто попълнени формуляри)
• Изкривени страници, които деформират формите на глифовете достатъчно, за да объркат съпоставянето

Размазан факс няма да се разчете като чист скан, независимо дали е Auto, или Force. Това е ограничение на самия модел, а не нещо, което параметър може да поправи.

Какво OCR не прави

OCR ви дава текст. Той не възстановява параграфи, заглавия, таблици или пренареждаем Word документ. Редактируемото оформление е проблем на преобразуване върху грешката от разпознаването, а не същата задача като разчитането на скан.

OCR a PDF работи от страната на сървъра без акаунт. Изтеглянето е Markdown. Ако съществуващ текстов слой изглежда грешен, използвайте Force OCR, за да не му се доверява Auto; а за да проверите дали дадена машина наистина има инсталирани PDFium и модела, изпращането на реална заявка е по-надеждно от четенето на сондата за възможности, тъй като тя само потвърждава, че крайната точка съществува, а не че средата ѝ за изпълнение е готова. За ключове за автоматизация и OpenAPI вижте Разработчици.