CuneiForm для DjVu

[monday2000]

Я сумел скомпилировать под Windows CuneiForm-Linux v1.0.0 http://launchpad.net/cuneiform-linux

Посредством компилятора MS VC++ 6.0. Всё делал по инструкции: скачал и установил инсталлятор СMake, сгенерировал им dsp-файлы для MS VC++ 6.0, потом скомпилировал.

Скомпилировался консольный файл плюс dll-файлы для него. Добавил туда также готовые dat-словари из линуксового дистрибутива. Кстати, эти словари - как раз та вещь, которая не даёт CuneiForm'у считаться по-настоящему программой с открытыми исходниками - никто пока не знает ни внутреннюю структуру этих словарей, ни как сделать новый словарь (скажем, для какого-нибудь нового языка). Жаль.  То есть, новый язык распознавания в CuneiForm не добавишь. 

Вот что получилось:

http://djvu-soft0001.nxt.ru/cuneiform_hocr_v1_0_0.rar (23,3 МБ)

Зеркало:
http://ifolder.ru/20085782

Я продублировал это сообщение на форуме OpenOCR: http://openocr.org/forum/viewtopic.php?f=2&t=3175 .

Программа поддерживает только BMP на входе. Это потому, что я пока не стал компилировать исходники вместе с ImageMagick++ (тогда была бы поддержка всех форматов). Просто ImageMagick++ может не скомпилироваться в MS VC++ 6.0 (почти наверняка).

Всё остальное в полученной программе - как у Линукс-версии. Попутно я нашёл 3 бага и одну проблему - но смог из них выкрутиться:

Bug #669844 in Cuneiform for Linux: “Start folder cuneiform.dll not found - VC6 build”

Bug #669908 in Cuneiform for Linux: “Bug found (Bool vs Bool 32)”

Bug #669880 in Cuneiform for Linux: “_stdMallocCounter == _stdFreeCounter”

Качайте, пробуйте. Не исключено даже, что всё это будет работать даже под Windows 98 (!)

В пакете есть готовый пример - BMP-файл. Запускаете прилагаемый bat-файл - и через секунду генерируется файл-результат распознавания - в формате hOCR.

Всё это я затеял ради генерации hOCR-файла. Дело в том, что официальные Windows-версии CuneiForm не поддерживают вывод hOCR-файлов - ни одна! Поддержку hOCR создали и прикрутили уже в Linux-версии.

hOCR - это формат распознанного OCR-слоя от OCRopus: http://code.google.com/p/hocr-tools/

hOCR is a format for representing OCR output, including layout information, character confidences, bounding boxes, and style information. It embeds this information invisibly in standard HTML. By building on standard HTML, it automatically inherits well-defined support for most scripts, languages, and common layout options. Furthermore, unlike previous OCR formats, the recognized text and OCR-related information co-exist in the same file and survives editing and manipulation. hOCR markup is independent of the presentation.

Вот спецификация hOCR: http://docs.google.com/View?docid=dfxcv4vc_67g844kf

Вообще, сейчас, как я понял, развивается бурными темпами Linux-порт CuneiForm'а. Официальные релизы заглохли намертво, никакой активности там не наблюдается. Жаль. Спасибо хоть линуксоидам, что хоть как-то развивают программу.

Вот интересные ссылки по теме CuneiForm:

LXF118:Компьютер слушает http://tinyurl.com/37dspzr
Статья проводит сравнение открытых OCR-продуктов Tesseract и CuneiForm.

Новости CuneiForm-Linux
http://www.linux.org.ru/view-news.jsp?tag=cuneiform

Распознавание текста в Linux при помощи CuneiForm
http://www.kv.by/index2009091108.htm

[monday2000]

Синтаксис командной строки этого CuneiForm:

Syntax:

cuneiform [-l language -o result_file -f [outputformat] extra_options ] <image_file>

Optional arguments are the following.

--dotmatrix uses a recognition mode optimised for text printed with a
dot matrix printer.

--fax uses a recognition mode optimised for text that has been faxed.

--singlecolumn disables page layout analysis and assumes that your
image consists of only one column of text.

If you do not define an output file with the -o switch, Cuneiform
writes the result to a file "cuneiform-out.[format]". The file extension
depends on your output format.

By default Cuneiform recognizes English text. To change the language use the
command line switch -l followed by your language string. To get a list of
supported languages type "cuneiform -l".

By default Cuneiform outputs plain text. There are several other output formats.
To get a list run the command "cuneiform -f".

Перевод:

Синтаксис:

cuneiform [-l language -o result_file -f [outputformat] extra_options ] <image_file>

Дополнительные аргументы:

--dotmatrix использует режим распознавания, оптимизированный для текста, напечатанного на матричном принтере.

--fax использует режим распознавания, оптимизированный для текста, присланного по факсу.

--singlecolumn отключает режим анализа структуры страницы и предполагает, что Ваша страница состоит только из одной колонки текста.

Если Вы не определите выводной файл ключом -o, Cuneiform записывает результат в файл "cuneiform-out.[format]". Расширение файла зависит от Вашего формата выводного файла.

По умолчанию Cuneiform распознаёт английский текст. Чтобы изменить язык, используйте ключ командной строки -l, сопровождаемый названием языка. Чтобы получить список поддерживаемых языков, введите команду "cuneiform -l".

По умолчанию Cuneiform выводит простой текст. Имеется несколько выводных форматов. Чтобы получить список, введите команду "cuneiform -f".

[monday2000]

Теперь остаётся ещё проблема как записать в DjVu результаты распознавания из hOCR-файла.

Этим вопросом занимается Jakub Wilk. У него есть утилиты hocr2djvu, hocr2djvused - как раз для этой цели. Вот его страница с этими утилитами:

http://jwilk.net/software/ocrodjvu

Проблема, однако, в том, что это чисто линуксовые утилиты. Как суметь использовать их под Windows - я пока не знаю. Написал вчера письмо Якубу, вот его ответ:

>How to compile your hocr2djvused in Windows? As a console utility.
You don't. hocr2djvu is a pure-Python program.

I no longer have access to a Windows machine. So, unless somebody
donates me a Windows license, I'm afraid you're on your own.

On the other hand I played around with Wine[0], and manager to run
hocr2djvused under it. So here is the recipe:

1. Install these:
http://sourceforge.net/projects/djvu/files/DjVuLibre_Windows/3.5.23%2B4.6/DjVuLibre%2BDjView-3.5.23b%2B4.6-Setup.exe/download
http://www.python.org/ftp/python/2.6/python-2.6.msi
http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11.win32-py2.6.exe
http://pypi.python.org/packages/2.6/l/lxml/lxml-2.2.8.win32-py2.6.exe#md5=18a7e134fc6eeda498068ece7f1656ef
http://pypi.python.org/packages/2.6/p/python-djvulibre/python-djvulibre-0.1.14.win32-py2.6.exe

2. Run:
C:\Python26\Scripts\easy_install argparse

3. Download and unpack ocrodjvu 0.7.0. Well, technically it hasn't been
released yet, but you can download code from the repository here:
http://bitbucket.org/jwilk/ocrodjvu/get/tip.zip
Then, in the unpacked directory, run:
C:\Python26\python setup.py install

4. Now you should have hocr2djvused.exe in your C:\Python26\Scripts
directory.  Note that it needs libdjvulibre.dll and libjpeg.dll (both
from DjVuLibre installation) to run.

• http://www.winehq.org/

--
Jakub Wilk

То есть Якуб сказал, что это чисто Питоновое приложение. Поэтому его на Windows не перенесёшь. Сам я думаю ещё глянуть в сторону Cygwin - там наверняка есть Python.

Хорошо хоть, что распознавание DjVu и запись в него OCR не требуют графического интерфейса от CuneiForm.

В общем, сейчас главное суметь получить hocr2djvused в виде вменяемого консольного Windows-приложения. Может, у кого-нибудь будут идеи, как это сделать?

[monday2000]

Пока что у меня возникло такое мнение, что вариант hocr2djvused от Jakub чересчур навороченный. Требует инсталляции Питона и кучи непонятных "довесков".

Потом скрипт требует компиляции в Питоне и под Питон? Так ли я понял идею?

В общем, подозреваю, что вся эта многоэтажная конструкция будет глючить по-чёрному. И будет на практике машинно-зависимой. Такое решение не назовёшь серьёзным и стабильным.

Сама собой возникает мысль о необходимости и желательности создания с нуля простого и надёжного hocr2djvused конвертера. Его можно сделать на базе любого XML-парсера. И будет это просто в виде обычного exe-файла - без всяких там ненужных наворотов (в данном случае) вроде Питона.

Кто и когда это будет делать, пока неясно.

[monday2000]

Кстати, первым делом обнаружился один неприятный момент:

формат hOCR - это вообще-то HTML-формат. И работать с ним напрямую нельзя - его нужно сначала преобразовать в XML.

В спецификации hOCR указывается на программу http://tidy.sourceforge.net/ , которая умеет автоматически переконвертировать HTML в XHTML.

Вот спрашивается: почему бы сразу не делать XML? Зачем для hOCR избрали HTML? Просто ерунда какая-то.

Как пользоваться этим tidy, я пока не понял. Сделать им конверсию HTML в XML я пока не смог. 

Вот образец hOCR-файла: http://www.onlinedisk.ru/file/545119/ Может, кто-нибудь сможет сконвертировать его в XML при помощи http://tidy.sourceforge.net/ ? Там на сайте http://tidy.sourceforge.net/ есть готовое виндовое консольное приложение - надо только разобраться в его использовании.

[monday2000]

В общем, мне удалось преобразовать HTML в XML. Синтаксис такой оказался:

tidy -q -asxhtml -utf8 < 1.html > page.xml

Проблем оказалось 2:

1. Кодировка UTF-8 - HTML был в UTF-8 - и XML тоже создался в UTF-8. В ASCII пришлось вручную пересохранять.

2. В начале XML-файла автоматически создаётся заголовок:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

IE 6 его не понимает и при загрузке ругается:

Не удается отобразить страницу XML
Не удается просмотреть ввод XML с использованием списка стилей . Исправьте ошибку и затем нажмите кнопку "Обновить"или повторите попытку позднее.
--------------------------------------------------------------------------------

Ошибка загрузки указанного ресурса. Ошибка при обработке ресурса ''http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'...

Оказалось, что это глюк самого IE 6! А сам-то XML-файл валидный оказался. Кстати, если убрать руками из начала XML строчки

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

то тогда и IE 6 начинает правильно загружать и отображать XML-файл. Mozilla Firefox таких дурных проблем не знает.

Вот полученный XML-файл:

http://www.onlinedisk.ru/file/545158/

[monday2000]

Чёрт - только сейчас заметил - неправильно преобразовался HTML в XML ! Пропало более половины информации. 

Как я и предполагал - автоматическая конверсия HTML в XML - оказалась непростым делом... 

Какая же всё-таки глупость была сделать hOCR в виде HTML, а не XML. 

[monday2000]

Посмотрел я внимательнее на потерю информации при конверсии в tidy из HTML в XML.

Выяснилась одна пренеприятнейшая вещь.

Оказалось, что HTML-файл содержит неправильный синтаксис - с точки зрения спецификации HTML. А именно, пустой тег SPAN.

И получается, что tidy удаляет этот пустой тег SPAN - при конверсии из HTML в XML. А удалять-то его нельзя - т.к. там в атрибутах куча нужной информации.

То ли это CuneiForm генерирует неправильный hOCR-файл (наиболее вероятно), то ли спецификация hOCR такая дурная, что толкает на создание неправильных HTML-hOCR-файлов (наименее вероятно).

Это сильно осложняет дело. Как прикажете перегонять в XML некорректный HTML-файл? 

Вот пример из жизни:

<p align=justify><span class='ocr_line' id='line_1' title="bbox 62 89 1283 131">шенствованию компрессоров в ХИ11 и Х1Х вв. способст-<span class='ocr_cinfo' title="x_bboxes 62 101 94 123 97 101 115 124 119 102 137 123 142 99 159 122 162 101 179 123 182 101 201 122 204 98 224 122 227 100 246 121 251 98 269 120 273 99 291 121 298 99 317 121 321 101 351 123 -1 -1 -1 -1 378 99 397 121 399 99 419 122 424 99 447 122 452 99 472 121 477 100 496 131 500 99 518 122 521 98 538 121 541 99 558 122 560 100 580 123 583 99 603 131 607 100 627 123 630 102 649 124 -1 -1 -1 -1 676 102 695 123 -1 -1 -1 -1 721 90 750 123 752 90 798 124 804 92 816 123 822 92 833 123 -1 -1 -1 -1 862 101 881 123 -1 -1 -1 -1 907 90 935 123 941 91 952 123 956 90 985 122 -1 -1 -1 -1 1010 101 1029 122 1033 101 1051 123 1055 117 1061 124 -1 -1 -1 -1 1089 99 1106 122 1110 100 1130 122 1133 99 1153 123 1156 99 1173 122 1175 101 1195 122 1199 89 1219 122 1222 99 1239 122 1242 100 1261 121 1265 111 1283 115 "></span></span>

Внутренний SPAN пуст, но зато имеет кучу атрибутов. И вот он, этот SPAN и выкидывается в процессе конверсии - не попадая в созданный XML.
Вот если бы в tidy была опция "не выкидывать пустые SPAN'ы" - тогда всё было бы OK.

Что делать, пока не знаю.

Вот я даже нашёл пользовательский запрос на эту тему:

Support a way to not drop "empty" <span>s - ID:2821564
Написан он более года тому назад - и ничего по нему так и не сделано.

Скорее всего, следует искать иное средство конверсии HTML-XML. Просто tidy напрямую ведь для этого не предназначен - его изначально создавали лишь как средство "причёсывания" HTML - а потом, наверное, добавили ещё и конверсию в XML.

Нужно искать специализированное программное средство конверсии HTML->XML. Что-нибудь в виде консольной утилиты и freeware обязательно.

[monday2000]

Кажется, мне удалось найти решение.

На этой странице http://www.xsolvo.com/Download нашёлся freeware конвертер html2xmlcl.exe (598.5 KB):

http://www.xsolvo.com/files/html2xmlcl.exe

Он как раз в виде консольной утилиты под Windows.

Синтаксис простой:

html2xmlcl 1.html

создаёт файл "1.xml".

Вот и XML, полученный из hOCR-файла:

http://www.onlinedisk.ru/file/545373/

Правда, html2xmlcl.exe не понимает кодировку utf-8, в которой генерируется hOCR-файл. Так что пришлось сначала вручную пересохранить hOCR-файл в Notepad++ из UTF-8 в ANSI, и только потом уже конвертировать в XML в html2xmlcl.exe. Ну это пустяки, программно преобразовать UTF-8 в ANSI нет проблем.

А вот для сравнения тот же BMP-файл, распознанный в Файнридере, с результатом, сохранённым в формате djvused:

http://www.onlinedisk.ru/file/545389/

Вот такой файл нам и нужно получить из сгенерированного XML-файла.

Но ещё интереснее выглядит использование утилиты djvuxml вместо djvused. Вот XML-файл с ABBYY-OCR слоем, полученный из того же образца через djvuxml:

http://www.onlinedisk.ru/file/545430/

Такой XML-файл ИМХО куда как нагляднее, чем TXT-файл для djvused:

<?xml version="1.0" ?>
<!DOCTYPE DjVuXML PUBLIC "-//W3C//DTD DjVuXML 1.1//EN" "pubtext/DjVuXML-s.dtd">
<DjVuXML>
<HEAD>file://localhost/D:/cuneiform_hocr_v1_0_0/cuneiform-linux-vc6-win-1.0.0/1.djvu</HEAD>
<BODY>
<OBJECT data="file://localhost/D:/cuneiform_hocr_v1_0_0/cuneiform-linux-vc6-win-1.0.0/1.djvu" type="image/x.djvu" height="2208" width="1372" usemap="1.djvu" >
<PARAM name="DPI" value="300" />
<PARAM name="GAMMA" value="2.200000" />
    <HIDDENTEXT>
      <PAGECOLUMN>
        <REGION>
          <PARAGRAPH>
            <LINE>
              <WORD coords="65,120,354,94">шенствованию </WORD>
              <WORD coords="381,128,652,95">компрессоров </WORD>
              <WORD coords="679,120,698,99">в </WORD>
              <WORD coords="724,121,836,87">XVIII</WORD>
              <WORD coords="865,120,884,98">и </WORD>
              <WORD coords="910,120,988,87">XIX</WORD>
              <WORD coords="1013,122,1064,99">вв.</WORD>
              <WORD coords="1092,121,1286,87"> </WORD>
            </LINE>
            <LINE>
              <WORD coords="65,163,199,138">способствовало </WORD>
              <WORD coords="225,171,400,138">развитие </WORD>
              <WORD coords="426,173,689,133">горно-</WORD>
              <WORD coords="725,173,1066,142">промышленности </WORD>
              <WORD coords="1103,165,1122,143">и </WORD>
              <WORD coords="1149,164,1286,141"> </WORD>
            </LINE>

Тогда задача ещё упрощается: нужно из одного XML-файла получить другой XML-файл (под djvuxml) - и внедрять OCR-слой в DjVu не посредством djvused - а посредством djvuxml.

[monday2000]

Попробовал сейчас DjVuLibre XML утилиты. Оказывается, внедрять мета-информацию (в формате XML) в DjVu нужно утилитой djvuxmlparser - а экспортировать мета-информацию (в формате XML) - утилитой djvuxml.

На пробу djvuxmlparser у меня сработала как-то не так - бОльшая часть текста не вставилась из XML. Наверное, глюки с кириллицей, надо будет разбираться. Но это решаемый вопрос.

Но всё равно, с XML работать гораздо легче, чем с djvused-форматом.

Так что теперь задача внедрения CuneiForm OCR в DjVu практически свелась к тому, чтобы из одного XML-файла (результата конверсии hOCR->XML) получить другой XML-файл (в формате, понятном djvuxmlparser).

Сделать это можно путём написания самодельной программы, умеющей работать с XML. Я такие программы уже делал - например, DjVu Pal (когда нужно было вытащить из WinDjView-XML файла букмарков информацию о зонах аннотаций). Я тогда использовал отечественную программную С++ XML-библиотеку pugixml http://code.google.com/p/pugixml/ - довольно удобная, и лицензия у неё (MIT) совместима с GPL.

Вот только нужно будет разобраться со спецификациями hOCR и djvuxmlparser-XML.

И не нужно будет городить такой огород, как сделал Jakub Wilk - с Питоном и прочими нелепыми наворотами.

Кстати - просто поразительно, что инструмент "hocr2xml" отсутствует на официальном сайте hocr http://code.google.com/p/hocr-tools/ ! Вот его-то как раз нужно было им сделать в самую первую очередь... Или они сочли задачу конверсии HTML->XML тривиальной?

[monday2000]

Посмотрел я внимательнее оба XML-файла (которые нужно один в другой превратить), почитал спецификацию hOCR (пока поверхностно).

Похоже, что hOCR, генерируемый в CuneiForm, сильно упрощён. То есть из всей спецификации hOCR там используется от силы 15-20%.

Надеюсь, что написать конвертер из одного XML в другой будет несложно. Конечно, его потом потребуется немало тестить - на разных примерах hOCR-файлов. Пока я не видел hOCR с таблицами и картинками, а hOCR с простым текстом совсем несложно будет перегнать в DjVu-XML.

Спецификация hOCR написана довольно мутно. Я бы и то лучше написал. Ни хрена там не понятно, лучше смотреть на конкретные примеры hOCR-файлов, чтобы понять, что такое hOCR.

Кстати, я нашёл то место в исходниках CuneiForm, где непосредственно генерируется hOCR-файл:

cuneiform-linux-1.0.0\cuneiform-linux-1.0.0\cuneiform_src\Kern\rout\src\html.cpp

Вот он онлайн:

http://bazaar.launchpad.net/%7Ejpakkane/cuneiform-linux/trunk/annotate/head%3A/cuneiform_src/Kern/rout/src/html.cpp

Похоже, что изначально это был файл вывода в HTML - а потом туда добавили опцию вывода в hOCR.

Кстати, давайте введём термины для обозначения обоих XML-файлов. Предлагаю назвать их условно так:

1. hXML (или hxml) - XML-файл, полученный путём конвертации hOCR в XML.

2. dXML (или dxml) XML-файл, понятный программе djvuxmlparser.

Итак, на данный момент задача ставится так, что нужно преобразовать hxml в dxml.

[m7876]

ocrodjvu отлично работает под Linux. Те глюки, которые есть, Jakub быстро исправляет.
Кстати, он позволяет еще использовать и tesseract, у которого теперь тоже есть русский язык. Не знаю, стОит ли Вам изобретать велосипед.
Да, еще имейте в виду, что cuneiform не указывает пиксельные размеры изображения в hOCR. Это может оказаться проблемой.

[monday2000]

m7876

Не знаю, стОит ли Вам изобретать велосипед.

Я теперь уже точно уверен, что стОит. Поддержка tesseract меня пока не интересует (дальше - посмотрим). А tesseract вообще кто-нибудь под Windows скомпилировал?

Те глюки, которые есть, Jakub быстро исправляет.

Ну и я буду исправлять. И тоже быстро. Да там вообще ничего сложного - всего только из одного XML-файла получить другой. Дела великие.

Вообще, я просто поражён Jakub-ским решением. Какие-то дикие, немыслимые навороты - ради чего? Что-то он явно темнит. Это он, видимо, просто проталкивает свой продукт - http://pypi.python.org/packages/2.6/p/python-djvulibre/python-djvulibre-0.1.14.win32-py2.6.exe - не иначе. 

Да, еще имейте в виду, что cuneiform не указывает пиксельные размеры изображения в hOCR. Это может оказаться проблемой.

Спасибо за информацию. Но это уже будет не моя проблема - а проблема CuneiForm-разработчиков.

А вообще - ИМХО к CuneiForm пока невозможно всерьёз относиться. У него отвратительный анализ макета страницы (если он вообще есть - я пока не понял).

Но мне CuneiForm как-то симпатичней - поскольку это отечественный продукт. Да и говорят, что качество распознавания CuneiForm немного лучше, чем у Tesseract.

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

Именно поэтому я хочу сейчас сделать создание OCR-слоя в DjVu средствами CuneiForm - на будущую перспективу, так сказать, и заодно пробудить ещё больший общественный интерес к CuneiForm.

В CuneiForm нужно сделать по крайней мере 2 глобальные вещи: открыть dat-словари (чтобы сделать CuneiForm по-настоящему Open-Source и чтобы открыть дорогу к обучению CuneiForm новым языкам) и сделать в CuneiForm путёвый анализ макета страницы.

Но уже сейчас сделано немало: CuneiForm успешно портирован на Linux, с Linux - обратно на Windows , вот сейчас я сделаю программу под Windows (под Linux она тоже будет компилироваться) для OCR-ния DjVu посредством CuneiForm (в обозримом будущем), и ещё хорошо то, что CuneiForm стал командно-строчным (а был чисто визуальным).

Да, и ещё нужно обновить мультиязычную версию CuneiForm с 0.7 до 1.0.

[m7876]

Какие-то дикие, немыслимые навороты - ради чего?

Да просто Python с кучей библиотек давно уже стал неотъемлемой частью почти любого Linux (примерно также, как Visual Basic -- Windows, и даже серьезнее). Так что никаких наворотов, все абсолютно логично. А, кстати, Jakub'овский pdf2djvu вполне кроссплатформенный и беспитоновский (и я очень им доволен, опять кстати).

Но это уже будет не моя проблема

Ваша, как только Вы текст начнете вставлять

[monday2000]

m7876

Так что никаких наворотов, все абсолютно логично.

Может быть, с точки зрения Linux, и логично. Но вряд ли логично с точки зрения Windows - где можно всю жизнь проработать, не имея даже и понятия о том, что такое Питон (как я, к примеру).
Да и всё равно работа Jakub выглядит нелепой - т.к. требует наличия какого-то "переходника" от Питона к DjVuLibre. Это также странно и подозрительно. Точнее, всё тут ясно - этот "переходник" сделал сам Jakub - вот он на его сайте: http://jwilk.net/software/python-djvulibre - и теперь Jakub этот "переходник" просто "проталкивает" в жизнь - пхая его туда, где он заведомо "ни к селу, ни к городу" - т.е. в свой hocr2djvu. Я так это понимаю. Отсюда и нелепость происходящего - которая просто-таки бросается в глаза. Моё решение будет простым как палка и даже кроссплатформенным - и я обойдусь без всяких там подозрительных излишеств.

А, кстати, Jakub'овский pdf2djvu вполне кроссплатформенный и беспитоновский

Да, это я знаю - но не о том сейчас речь.

Ваша, как только Вы текст начнете вставлять.

Вот этот момент, пожалуйста, подробней. Почему же я должен хоть как-то почувствовать эту проблему? Не пойму. Разве мне будет хоть какое-то дело до присутствия картинок на скане - ведь каждое OCR-слово имеет свои координаты - так что поверх картинки, к примеру, OCR никогда не вставится.