и создавать некий конвертер "html - xml" только для того, чтоб потом "работать с xml" в данной ситуации сложно и не имеет смысла..
А я его и не создаю - а просто взял чужой готовый. Так что для меня тут никакой сложности нет вовсе - процесс конвертации HTML->XML
полностью автоматический. Зато я не представляю себе, как я бы программно парсил HTML - а вот XML парсить для меня программно как раз вполне легко.
и создавать некий конвертер "html - xml" только для того, чтоб потом "работать с xml" в данной ситуации сложно и не имеет смысла..
Да, я согласен, что это спорный момент. Но при кажущейся её излишности, конвертация "html - xml" всё же имеет многие плюсы:
1. Поскольку мне явно придётся ещё долго отлаживать всю цепочку внедрения OCR в DjVu, то мне будет гораздо нагляднее иметь дело только с XML - а не с HTML. То есть я сразу получаю XML, и дальше об исходном HTML забываю, словно его и не было никогда. XML в разы нагляднее для человека, чем HTML.
2. Я хотел бы, конвертируя "html - xml", в т.ч. намекнуть всем заинтересованным лицам, что пора бы выкинуть на свалку hOCR, и взамен сделать какой-нибудь "xOCR" (на базе XML). hOCR всё равно не жилец - так что я в своей программе от него сразу же избавляюсь полностью.
3. Как я уже сказал, стороннему разработчику легче (точнее, нагляднее) будет понять смысл происходящего в моей программе, если там будет идти конверсия hxml-dxml, а не hOCR-dxml. Может, кто-то захочет написать свою реализацию такой же программы (хотя бы потому, что я собираюсь использовать XML-библиотеку pugixml - а кому-то захочется свою XML-библиотеку применить). Для этого ему будет достаточно лишь сделать свой конвертер hxml-dxml, и всё - и это будет весьма несложной задачей.
если уж так принципиален формат xml, то больше пользы будет, если тратить время не на конвертацию имеющегося хтмл, а правку вывода даных из cuneiform..
Такую правку вообще делать не следует. Зачем тогда вообще нужен OCR в DjVu, чтобы его ещё и править. Нет, никакой правки не должно быть. Другое дело, что Вы скажете, что без правки получится галиматья в OCR-слое DjVu-файла - так это другой вопрос, это вопрос повышения качества самого CuneiForm. Я же написал, что к идее OCR-ния DjVu-файла посредством CuneiForm пока нельзя относиться всерьёз при всём желании.
Понимаете, я-то, конечно, сделаю программу под Windows для создания и внедрения в DjVu OCR-слоя посредством CuneiForm. Однако эта программа будет носить исключительно
пропагандистский характер - а пользоваться ею реально будет
невозможно. Что поделаешь - такова уж суровая реальность - слишком ещё низко качество анализа макета страницы в CuneiForm-Linux. Поэтому отпадает нужда в правке OCR-данных (раз уж программой не предполагается всерьёз пользоваться).
Конечно, может возникнуть вопрос - а зачем тогда городить огород - если всё делать исключительно в пропагандистских целях?
Смысл есть, смысл в рекламе CuneiForm'а, в увеличении общественного интереса к нему - что должно в конечном итоге привести к появлению новых разработчиков, которые улучшат CuneiForm чисто алгоритмически. Конечно, на это уйдут годы - но надо же что-то делать, не сидеть же сложа руки.
вообще, djvutoxml криво извлекает текст из djvu.. пропадают части слова после цифр, тире, кавычек и т.д..
Ну что ж, нужно просто исправить эти глюки, вот и всё. Я в состоянии это сделать - с помощью Леона Боту. И я планирую это сделать. Глюки эти я, кстати, и сам ещё ранее заметил. Но я на сегодняшний день уже не один десяток глюков устранил в DjVuLibre-утилитах - так что меня эти глюки не смущают. Наоборот, здорово - появится повод отладить djvuxmlparser.
к тому же xml содержит дополнительную информацию не только о djvu-книге,
DPI и Gamma? Эту информацию можно просто не указывать в dxml - тогда она не изменится в DjVu при внедрении туда dxml.
но даже о месте ее расположения на диске
.. поэтому, создавая xml для djvuxmlparser'а придется дополнительно извлекать всю эту информацию напрямую из книги, либо с помощью соответствующих утилит..
Вот это, согласен, просто бред.

Хотя, особой проблемы тут нет - вставить в XML путь к обрабатываемому XML-файлу. Я попробую поговорить с Леоном Боту на тему устранения этого бреда. Конечно, я сам мог бы сделать подкорректированную версию djvuxmlparser'а - принимающую путь к обрабатываемому DjVu в командной строке - но будет гораздо интересней, если это окажется в официальной версии DjVuLibre.
резюме - если конечной целью является внедрение текста, полученного в cuneiform, то на данный момент наиболее простой способ - парсить html, создавать dsed и внедрять его djvused'ом..
Нет, не самый простой. Самый простой - как раз мой способ. А знаете, почему? А потому что невозможно понять, что такое "hOCR", глядя лишь на его спецификацию. Можно только взять побольше разнообразных примеров hOCR-файлов - чтобы чисто на примерах понять, что есть hOCR. Из этих посылкок вытекает требование максимальной человеко-понятности представления OCR-данных - а ему отвечает как раз XML (hxml), а не HTML (hOCR).
К тому же ещё и dxml лучше, чем dsed - потому что он непосредственно нагляден человеку, в отличие от dsed - что крайне важно в условиях, когда нужно будет БЫСТРО и ВИЗУАЛЬНО найти очередной косяк в преобразовании данных из hOCR в DjVuLibre-формат (в условиях непонимания до конца "что такое hOCR").
Проще говоря, мне будет гораздо быстрее, проще и легче визуально сравнить 2 XML-файла (hxml и dxml) - чтобы оценить возможную ошибку преобразования "hxml -> dxml" (при отладке программы), чем пытаться визуально сравнить hOCR и dsed.

в перспективе, при желании, можно поправить формат выходного файла cuneiform'а.. вместе с этим научить его хавать djvu
В перспективе нужно будет сделать одну-единственную вещь: выкинуть на помойку hOCR (где ему самое место) и разработать взамен XML-стандарт представления OCR-данных. Может быть даже, как ISO-стандарт (хотя, не уверен, будет ли он действительно разумным в этом случае

). Вот это будет действительно разумно. А CuneiForm, по идее, уже сейчас должен поддерживать DjVu на чтение - т.к. чтение DjVu поддерживается ImageMagick'ом. Это просто я скомпилировал свой CuneiForm без ImageMagick++ - т.к. мне это совсем без надобности, я просто взамен применю fi_ddjvu - чтобы получить BMP из DjVu.
Что касается dsed и djvused, то от них ПОРА уже начинать потихоньку уходить. Они просто разрабатывались тогда, когда XML только создавался. А теперь dsed - это уже анахронизм.
а вообще, качество распознавания в cuneiform'е оставляет желать лучшего.. нужно ли вообще текст такого качества вставлять в книгу?
Я ж и говорю, что "не нужно". Это было бы просто безумием. Цель - только пропаганда и привлечение новых CuneiForm-разработчков - и не более того.