Автор Тема: CuneiForm для DjVu  (Прочитано 27567 раз)

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #15 : 06 ЅЮпСам 2010, 21:50:37 »
Зашёл я сейчас на сайт проекта Tesseract http://code.google.com/p/tesseract-ocr/ . М-да, впечатляет. С 3 версии уже и русский поддерживается, и добавлен "модуль общего анализа макета новой страницы" ???:
http://groups.google.com/group/tesseract-ocr/msg/f240b6c7c5afa08b
Плюс в Tesseract есть возможность обучения новым OCR-языкам - а в CuneiForm нет.

Внимание к проекту Tesseract явно уделяется - и немалое. Впрочем, чему тут удивляться - ведь его спонсирует сам Google.

А CuneiForm развивается только силами любителей.

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

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

К CuneiForm нужно просто приложить ещё усилия - и он "заиграет" ничем не хуже, чем Tesseract.

N.M.E.

  • Пользователь
  • **
  • Сообщений: 87
    • Просмотр профиля
Re: CuneiForm для DjVu
« Ответ #16 : 07 ЅЮпСам 2010, 03:20:23 »
Цитировать
Итак, на данный момент задача ставится так, что нужно преобразовать hxml в dxml.
имхо это лишнее..
надо хтмл парсить, так намного проще..
даже я, имея за плечами полторы прочитанные книги по C#, сумел за день в первом приближении сделать такую утилитку..
если есть фреймворк - посмотри http://ifolder.ru/20142561

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #17 : 07 ЅЮпСам 2010, 08:43:00 »
N.M.E.
Цитировать
имхо это лишнее..
надо хтмл парсить, так намного проще..
Не думаю. Как раз наоборот. Если бы это было так - все бы везде вместо XML использовали HTML.

HTML нестрог к своему синтаксису, разрешая ошибки. В hOCR, кстати, как раз такой случай - т.е. наличие пустых тегов SPAN, которые tidy не понимает.

Поэтому HTML трудно парсить. Да и чем его вообще программно парсить? Через DOM? Легче застрелиться. ;D

Вот почитайте о сравнении HTML и XML:

XML против HTML, или Мама, роди меня обратно
http://kolbas2003.narod.ru/staty/xmlprotivhtm.htm

Вот ещё полезно:
Различия между XML и HTML
http://kunegin.narod.ru/ref6/xml/43.htm
Цитировать
если есть фреймворк
А если нет? Я, например, противник всяких фреймворков-рантаймов и т.п. Зачем они, если и без них всё прекрасно работает. Фрейворки нужны только ради того, что майкрософт мог себе деньги зарабатывать - и больше ни для чего.

XML - это уже давно стандарт обмена структурированными данными. Здесь как раз такой случай. Никому сейчас и в голову не прийдёт обмениваться структурированными данными через HTML - это просто смешно и дико неудобно.

Вот, например, у меня на работе всю налоговую отчётность сдают по Интернету именно в формате XML - но вовсе не в HTML. Это тоже случай обмена структурированными данными.

Преобразование hOCR в XML может, и выглядит как лишний шаг - действительно, в принципе можно ухитриться напрямую распарсить hOCR в dxml - но это будет хуже в концептуальном плане. В частности, это затруднит воспроизведение моей программы другими разработчиками - т.к. она станет непрозрачной. Проще говоря, стороннему человеку будет гораздо проще понять суть моей программы, сравнивая hxml и dxml - нежели чем hOCR и dxml.

В общем, я как бы сразу ухожу от hOCR к XML (hxml) и всё - а дальше уже работаю чисто с XML. И мне это представляется наиболее идеологически правильным.

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

Просто, по-видимому, hOCR начали разрабатывать в те времена, когда XML только-только входил в оборот.
« Последнее редактирование: 07 ЅЮпСам 2010, 08:55:47 от monday2000 »

N.M.E.

  • Пользователь
  • **
  • Сообщений: 87
    • Просмотр профиля
Re: CuneiForm для DjVu
« Ответ #18 : 07 ЅЮпСам 2010, 13:09:41 »
Цитировать
Не думаю. Как раз наоборот.
если есть выбор - то, конечно, работать с xml удобнее - кто ж спорит..
но в данном конкретном случае - мы имеем что имеем))..
и создавать некий конвертер "html - xml" только для того, чтоб потом "работать с xml" в данной ситуации сложно и не имеет смысла..
если уж так принципиален формат xml, то больше пользы будет, если тратить время не на конвертацию имеющегося хтмл, а правку вывода даных из cuneiform..

вообще, djvutoxml криво извлекает текст из djvu.. пропадают части слова после цифр, тире, кавычек и т.д.. к тому же xml содержит дополнительную информацию не только о djvu-книге, но даже о месте ее расположения на диске  :o .. поэтому, создавая xml для djvuxmlparser'а придется дополнительно извлекать всю эту информацию напрямую из книги, либо с помощью соответствующих утилит..
в этом плане формат dsed более гибкий - ему необходим только номер страницы..

резюме - если конечной целью является внедрение текста, полученного в cuneiform, то на данный момент наиболее простой способ - парсить html, создавать dsed и внедрять его djvused'ом.. моя программка из предыдущего поста - наглядное тому подтверждение.. в принципе, после того, как данные из html получены, их и в т.н. "dxml" запихнуть проще простого..
в перспективе, при желании, можно поправить формат выходного файла cuneiform'а.. вместе с этим научить его хавать djvu (т.е. на входе д.б. djvu-файл - на выходе xml, dsed или внедренный текстовый слой - по выбору)..
всё остальное - это "шашечки", а не "ехать"..

а вообще, качество распознавания в cuneiform'е оставляет желать лучшего.. нужно ли вообще текст такого качества вставлять в книгу?
это сродни некачественно сделанным книгам (в плане сканов), только с меньшими последствиями.. вроде и книга есть, а пользы от нее 0, а то и вообще - вред.. так и от такого текста - ты ищешь нужное слово, поиск показывает, что его в книге нет, начинаешь лопатить другие материалы.. а оно на самом деле есть.. хорошо, что в отличии от хренового качества картинки, здесь ситуация поправимая..

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #19 : 07 ЅЮпСам 2010, 14:27:57 »
Цитировать
и создавать некий конвертер "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.
Цитировать
но даже о месте ее расположения на диске  :o .. поэтому, создавая 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. ;D
Цитировать
в перспективе, при желании, можно поправить формат выходного файла cuneiform'а.. вместе с этим научить его хавать djvu
В перспективе нужно будет сделать одну-единственную вещь: выкинуть на помойку hOCR (где ему самое место) и разработать взамен XML-стандарт представления OCR-данных. Может быть даже, как ISO-стандарт (хотя, не уверен, будет ли он действительно разумным в этом случае :-\ ). Вот это будет действительно разумно. А CuneiForm, по идее, уже сейчас должен поддерживать DjVu на чтение - т.к. чтение DjVu поддерживается ImageMagick'ом. Это просто я скомпилировал свой CuneiForm без ImageMagick++ - т.к. мне это совсем без надобности, я просто взамен применю fi_ddjvu - чтобы получить BMP из DjVu.

Что касается dsed и djvused, то от них ПОРА уже начинать потихоньку уходить. Они просто разрабатывались тогда, когда XML только создавался. А теперь dsed - это уже анахронизм.
Цитировать
а вообще, качество распознавания в cuneiform'е оставляет желать лучшего.. нужно ли вообще текст такого качества вставлять в книгу?
Я ж и говорю, что "не нужно". Это было бы просто безумием. Цель - только пропаганда и привлечение новых CuneiForm-разработчков - и не более того.
« Последнее редактирование: 07 ЅЮпСам 2010, 17:55:37 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #20 : 07 ЅЮпСам 2010, 19:06:46 »
Я сейчас ещё раз почитал форум OpenOCR.org и в Яндексе порылся на тему CuneiForm.

Насколько я понял, сейчас в Linux-версии CuneiForm отключён анализ макета страницы и анализ таблиц. Надеюсь, это явление - временное. Вызвано оно, скорее всего, тем, что эти функции были слишком "завязаны" на родное GUI - и так быстро "отвязать" их не получилось - поскольку это Windows-специфичные функции.

Правда, я мог что-то не так понять, да и эти сведения могли уже устареть.

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

Даже DAT-словари, по идее, можно открыть - через reverse-engineering. К тому же, код, обращающийся к DAT-словарям - уже открыт, так что это упростит задачу.

N.M.E.

  • Пользователь
  • **
  • Сообщений: 87
    • Просмотр профиля
Re: CuneiForm для DjVu
« Ответ #21 : 08 ЅЮпСам 2010, 19:24:37 »
Цитировать
Я ж и говорю, что "не нужно".
ну, тогда удаляю свою программу за ненадобностью..
успехов  ;)

m7876

  • Новичок
  • *
  • Сообщений: 38
    • Просмотр профиля
Re: CuneiForm для DjVu
« Ответ #22 : 09 ЅЮпСам 2010, 01:11:04 »
Цитировать
Вот этот момент, пожалуйста, подробней. Почему же я должен хоть как-то почувствовать эту проблему? Не пойму. Разве мне будет хоть какое-то дело до присутствия картинок на скане - ведь каждое OCR-слово имеет свои координаты - так что поверх картинки, к примеру, OCR никогда не вставится.
А разве общий размер изображения не нужен для того, чтобы определить, к чему относятся координаты?

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #23 : 09 ЅЮпСам 2010, 09:26:11 »
m7876
Цитировать
А разве общий размер изображения не нужен для того, чтобы определить, к чему относятся координаты?
Нужен. И он там есть.

m7876

  • Новичок
  • *
  • Сообщений: 38
    • Просмотр профиля
Re: CuneiForm для DjVu
« Ответ #24 : 09 ЅЮпСам 2010, 23:12:28 »
А, ну значит, поправили, отлично.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #25 : 10 ЅЮпСам 2010, 13:25:40 »
Вот пример hOCR:
Цитировать
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head><title></title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
<meta name='ocr-system' content='openocr'>
</head>
<body><div class='ocr_page' id='page_1' title='image "sample.bmp"; bbox 0 0 1372 2208'>
<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 class='ocr_line' id='line_2' title="bbox 62 136 1283 176">вовало развитие горно-рудной промышленности и метал-<span class='ocr_cinfo' title="x_bboxes 62 145 81 167 85 144 105 166 108 145 126 165 131 142 150 166 152 144 173 165 176 146 196 167 -1 -1 -1 -1 222 143 241 175 247 143 265 165 268 143 285 165 288 143 307 164 311 142 331 164 334 142 353 164 355 142 375 164 379 144 397 167 -1 -1 -1 -1 423 145 438 167 440 143 460 166 465 143 484 175 488 143 506 165 510 144 530 165 534 153 544 157 549 144 568 175 572 144 592 176 594 144 618 171 620 145 638 166 642 144 662 167 666 136 686 166 -1 -1 -1 -1 722 145 742 167 747 145 765 176 769 145 789 168 793 146 817 167 822 145 847 167 852 145 883 168 885 145 906 167 911 145 929 168 932 146 950 167 955 145 975 167 978 145 998 168 1002 144 1019 166 1021 144 1040 166 1043 144 1063 166 -1 -1 -1 -1 1100 145 1119 167 -1 -1 -1 -1 1146 144 1170 165 1175 143 1193 166 1194 144 1213 165 1217 143 1235 165 1238 144 1260 165 1265 155 1283 159 "></span></span>
<span class='ocr_line' id='line_3' title="bbox 62 179 1272 219">лургии. Во второй половине ХЧ111 в. в Англии Вилькинсон <span class='ocr_cinfo' title="x_bboxes 62 189 84 211 87 188 108 219 111 188 130 219 134 188 150 211 155 188 174 209 178 187 198 209 202 205 209 212 -1 -1 -1 -1 229 179 256 211 259 189 279 212 -1 -1 -1 -1 298 188 318 210 321 188 340 210 341 188 361 211 365 188 384 219 387 189 407 210 411 181 431 211 -1 -1 -1 -1 452 189 472 211 475 189 495 212 497 190 519 212 522 189 542 212 545 191 564 212 568 189 588 212 592 190 610 211 615 190 633 213 -1 -1 -1 -1 652 179 680 211 682 179 713 213 717 180 729 211 736 180 747 211 754 180 765 211 -1 -1 -1 -1 787 190 806 211 810 207 816 212 -1 -1 -1 -1 838 191 857 212 -1 -1 -1 -1 875 180 903 212 908 190 926 211 931 189 947 211 948 190 970 211 974 190 994 212 999 189 1018 211 -1 -1 -1 -1 1041 180 1066 211 1071 188 1090 210 1093 189 1115 210 1119 188 1137 210 1141 187 1160 210 1164 187 1184 209 1188 188 1206 209 1211 186 1228 209 1230 188 1250 209 1254 188 1272 209 -1 -1 -1 -1 "></span></span>
<span class='ocr_line' id='line_4' title="bbox 65 225 1279 265">запатентовал двухцилиндровый поршневой компрессор и <span class='ocr_cinfo' title="x_bboxes 65 232 82 254 87 231 106 254 110 232 129 255 134 231 153 255 156 233 174 254 176 232 194 254 198 231 216 253 220 232 238 253 241 230 261 253 264 233 283 254 287 231 306 254 309 233 330 256 -1 -1 -1 -1 356 233 378 259 381 233 400 254 403 233 423 264 426 232 446 255 449 236 471 261 474 234 494 256 496 235 519 256 523 233 543 255 547 235 565 256 569 235 591 260 595 234 614 265 618 233 638 256 641 234 660 255 663 234 689 256 693 226 713 256 -1 -1 -1 -1 762 234 782 256 785 232 805 255 809 233 828 264 833 234 863 256 868 233 886 254 891 233 909 256 912 234 931 255 933 232 953 255 956 225 976 256 -1 -1 -1 -1 1004 233 1023 255 1026 233 1045 255 1049 233 1073 255 1078 232 1098 254 1103 233 1122 264 1126 232 1144 255 1146 231 1163 254 1166 231 1183 254 1186 231 1206 254 1210 231 1229 263 -1 -1 -1 -1 1259 231 1279 253 -1 -1 -1 -1 "></span></span>
<span class='ocr_line' id='line_5' title="bbox 65 268 1285 310">в то же время Уатт изготовил воздуходувную машину с <i>па-</i><span class='ocr_cinfo' title="x_bboxes 65 278 85 301 -1 -1 -1 -1 103 278 122 300 123 280 143 301 -1 -1 -1 -1 162 278 194 300 196 278 214 301 -1 -1 -1 -1 231 279 250 300 254 278 273 309 277 277 295 300 299 279 323 300 327 279 347 301 -1 -1 -1 -1 366 268 394 301 398 278 417 301 420 279 438 301 441 279 460 301 -1 -1 -1 -1 477 280 497 302 500 279 517 301 520 279 536 301 538 280 558 303 561 281 578 303 581 279 601 302 604 281 623 302 627 279 647 302 647 280 671 302 -1 -1 -1 -1 690 280 709 301 711 278 731 301 734 279 750 301 752 279 776 306 777 278 798 310 801 277 821 299 823 277 843 300 845 277 867 304 869 277 889 308 892 278 911 299 915 277 933 299 938 277 958 308 961 277 992 300 -1 -1 -1 -1 1009 277 1033 298 1039 277 1057 299 1061 277 1091 300 1097 277 1117 299 1121 278 1139 299 1143 276 1164 307 -1 -1 -1 -1 1183 275 1200 298 -1 -1 -1 -1 1218 275 1238 297 1243 276 1261 298 1266 286 1285 291 "></span></span>
<span class='ocr_line' id='line_6' title="bbox 67 322 409 356"><i>ровым приводом. </i><span class='ocr_cinfo' title="x_bboxes 67 322 87 354 91 324 111 345 114 325 133 346 136 323 162 345 167 323 191 346 -1 -1 -1 -1 210 323 230 346 235 324 254 356 258 324 278 346 281 325 300 347 303 323 323 346 325 325 347 351 350 323 370 346 373 325 397 346 402 342 409 348 -1 -1 -1 -1 "></span></span>
</p>
Размеры страницы там - 1372 2208.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #26 : 11 ЅЮпСам 2010, 15:39:02 »
Мне пришёл ответ от Thomas Breuel. Я написал ему письмо с критикой выбора HTML под hOCR. Он мотивировал свой выбор такой ссылкой:

http://scholar.google.de/scholar?hl=en&q=hocr+author%3At-breuel&btnG=Search&as_sdt=2000&as_ylo=&as_vis=0

По этой ссылке выложены его материалы.

Короче, он погнался за двумя зайцами сразу: он хочет и в броузере просматривать hOCR - но также и не терять при этом геометрические данные о словах.

Что и говорить, подход просто дикий. Я бы сказал - пещерный. Как жаль, что таких дилетантов допускают к принятию важных решений.

Единственный толк, который я от него получил, так это то, что он подкинул мне идею использовать конвертер с именем html2xhtml - для конверсии HTML - XML. Вот ссылку я уже сам нашёл:

http://www.it.uc3m.es/jaf/html2xhtml/download.html

Продукт распространяется под GPL 2. Это то, что надо. На пробу сработал правильно, создал полноценный XML. В общем, буду им пользоваться, скорее всего.

В djvuxmlparser я нашёл баг. Он неправильно обрабатывает русский dxml - не внедряет в DjVu кириллические символы оттуда. Я уже локализовал место ошибки в коде - теперь вот веду переписку с Леоном Боту и Биллом Риемерзом по поводу устранения бага. Самому мне сложно правильно устранить данный баг - мой вариант исправления может оказаться не универсальным. Леон не хочет вообще-то этим заниматься - он недолюбливает XML и ему нравится djvused-язык. А DjVuLibre XML-утилиты, кстати, делал Билл, а не Леон - так что я на Билла тут больше надеюсь.

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #27 : 12 ЅЮпСам 2010, 10:10:31 »
Леон Боту нашёл и устранил баг в djvuxmlparser. Вот исправление:

http://djvu.cvs.sourceforge.net/viewvc/djvu/djvulibre-3.5/libdjvu/GString.h?r1=1.28&r2=1.29

И ещё он добавил новую опцию в djvused:
http://djvu.cvs.sourceforge.net/viewvc/djvu/djvulibre-3.5/tools/djvused.cpp?view=log Revision 1.40
Цитировать
Also I added in CVS a new djvused option (-u)
to produce and utf8 encoded dsed file instead of a pure ascii one.

$ ~/djvulibre-3.5/BUILD/tools/djvused -u -e output-txt sample.djvu | head -20
select; remove-txt
# -------------------------
select "sample.djvu"
set-txt
(page 65 56 1304 2120
 (column 65 56 1304 2120
  (region 65 56 1304 2120
   (para 65 56 1304 2120
    (line 65 2079 1286 2120
     (word 65 2087 354 2113 "шенствованию")
     (word 381 2079 652 2112 "компрессоров")
     (word 679 2087 698 2108 "в")
     (word 724 2086 836 2120 "XVIII")
     (word 865 2087 884 2109 "и")
     (word 910 2087 988 2120 "XIX")
     (word 1013 2085 1064 2108 "вв.")
     (word 1092 2086 1286 2120 ""))
    (line 65 2034 1286 2074
     (word 65 2044 199 2069 "способствовало"
Это он сделал для того, чтобы djvused стал делать человеко-читаемые файлы. Эту идею когда-то пытался реализовать автор программы DjVu Reader Дмитрий Гарькаев aka Dickobraz. У него на сайте даже была выложена пробная утилита djvused8: http://www.djvu-soft.narod.ru/opendjvu/ . Но, по-моему, она немного кривая. Впрочем, теперь вот и просто djvused обрёл такой функционал.
« Последнее редактирование: 12 ЅЮпСам 2010, 10:31:40 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #28 : 12 ЅЮпСам 2010, 10:47:56 »
Вот исправленная версия djvuxmlparser:

http://www.djvu-soft.narod.ru/soft/djvuxmlparser.rar  (254 КБ)

А вот обновлённая  версия djvused:

http://www.djvu-soft.narod.ru/soft/djvused.rar  (278 КБ)

Синтаксис такой: djvused sample.djvu -u -e 'output-txt' > 1.txt

Это скомпилированные мною экзешники в MS VC++ 6.0. Готовы к работе и никаких dll не требуют.
« Последнее редактирование: 03 ґХЪРСам 2010, 09:01:22 от monday2000 »

monday2000

  • Администратор
  • *****
  • Сообщений: 985
    • AOL клиент - -
    • Yahoo клиент - -
    • Просмотр профиля
    • Создание книг в электронном виде из бумажных книг (в формате DjVu)
    • E-mail
Re: CuneiForm для DjVu
« Ответ #29 : 14 ЅЮпСам 2010, 11:17:49 »
Я попросил Билла изменить djvuxmlparser так, чтобы он начал принимать путь к обрабатываемому DjVu через командную строку - вместо того, чтобы вытаскивать его из XML-файла.

Но Билл мне даже не ответил на это письмо.

Боже мой, как можно было вообще додуматься до такой чуши, чтобы помещать путь к DjVu внутрь XML вместо командной строки djvuxmlparser! >:( Это Билл делал djvuxmlparser и это была явно его идея. Как-то очень "по-Тулонски", я бы сказал. ;D

Тогда я предложил Леону Боту, что если я сам сделаю нужную модификацию в djvuxmlparser, и пришлю ему - то согласен ли он включить это исправление в состав официальной версии djvuxmlparser?

Леон ответил мне следующее:
Цитировать
I would accept a change that adds one optional argument to override the file specified in the XML file.
То есть, он не возражает. Конечно, Леон разумный человек, и ему эту чушь билловская также совершенно очевидна.

Так что буду теперь делать модифицированную версию djvuxmlparser. Если кто хочет помочь - милости прошу.

И ещё по моей просьбе Леон добавил в http://djvu.sourceforge.net/doc/man/djvused.html описание опции -u:
Цитировать
-u
Cause djvused to print hidden text and annotations as UTF-8 instead of encoding non-ASCII characters with octal escape sequences for maximal portability. This option is convenient for manually editing or viewing the djvused output. This option also causes the emission of an UTF-8 BOM under Windows.
« Последнее редактирование: 14 ЅЮпСам 2010, 11:22:48 от monday2000 »