» Утилиты для DjVu: FR11 DTL Crutch, DjVu Anno Editor и др.

NME
Вот что ответили по нашему вопросы из ТП FR:

Программа ABBYY FineReader использует технологии, работающие только с растровыми изображениями. Для того чтобы распознать исходный векторный документ, ABBYY FineReader 11 Professional Editionпреобразует его в растровый. При сохранении документа DjVu в режиме “текст под изображением страницы” используется растрированное изображение, под которое помещается текстовый слой.
...
Вы открываете исходный векторный документ и хотели бы сохранить качество изображения. К сожалению, на данный момент в программе ABBYY FineReader не поддержана работа с векторными изображениями. Мы передали пожелание добавить поддержку векторных изображений в Отдел исследований и разработок нашей компании.

AKazak
интересно, с каких это пор djvu стал векторным?
тот, кто отвечал, не имеет представления об этом формате..
от ABBYY всего лишь требуется вставить распознанный текст в имеющийся файл..
есть предположения, почему они этого не делают - у них есть всякие функции поворота, разворота и т.п.. при включенных опциях якобы улучшается качество распознания, но координаты текста и графики в конечном результате могут не совпадать.. с 9й версии эти опции можно отключать, а для 8ки я специальную утилиту для устранения перекоса делал - turnthetext..
так вот, видимо, чтобы не заморачиваться с пересчетом координат текста, они тупо сделали "универсальный" метод - заново перекодируют в djvu как повернутые, так и не повернутые изображения.. и логику эту они навряд ли будут менять.. так что остается только переносить распознанный текстовый слой в исходный djvu самостоятельно, благо это не сложно.. тем более, что его всё-равно желательно допиливать crutch'ем, им же и перенести..

По поводу программы правки шейпов в маске. Проблема назрела дано. Есть такая програмка Djvutoy, которая может извлекать шейпы из djvu в виде картинок. Неплохо было бы, чтобы эти шейпы можно было редактировать и внедрять обратно в файл djvu. Если, например, в файле много разных шейпов одной и той же буквы, то можно выбрать наилучший ее вариант и засунуть обратно в словарь djvu, при этом читабельнось текста улучшится, и размер файла тоже можно будет уменьшить. Писал об этом Леону (автору djvulibre), вот что он ответил:

You can do that using the C++ api but it requires a bit of investigation.

Each djvu page is an ensemble of chunks.
The trick is to
1. load these chunks from an existing page,
2. tweak the JB2Image structure that represents the stencil,
3. recompute the shapes tree that determines how they are encoded,
4. and reassemble the chunks.

To do (1) you can use the ddjvuapi <http://sourceforge.net/p/djvu/djvulibre-git/ci/master/tree/libdjvu/ddjvuapi.h>
If you first include the file DjVuImage.h, this file also reveals a function named GP<DjVuImage> ddjvu_get_DjVuImage(ddjvu_page_t *page).
This function returns a smart pointer to a DjVuImage class which defines member function get_xxxx to access the c++ data structure that represents all the chunks.
You can use djvuimage->get_fgjb() to get a smart pointer to a JB2Image.

To do (2), you have to investigate the api of class JB2Image which is reasonably well explained in file <http://sourceforge.net/p/djvu/djvulibre-git/ci/master/tree/libdjvu/JB2Image.h>.

To do (3) and (4), best is to check program cpaldjvu.cpp <http://sourceforge.net/p/djvu/djvulibre-git/ci/master/tree/tools/cpaldjvu.cpp>. The creation of the JB2Image starts around line 718. The recomputation of the shape tree is line 763 (since you change some glyphs, the existing tree is probably suboptimal). The assembly of the djvu file starts around line 792.


Of course all of this requires a fair amount of work understanding how all this works and reading partly obsolete comments.
You need to be familiar and proficient with c++. But people have done things like this before...

Hope it helps.

- L.


Если у кого получится, то, думаю, это будет большой прорыв в djvu кодировании (пафосно, но тем не менее).

теоретически, мне по силам решение данной задачи - на нынешнем этапе мне доступно раскодирование и обратное кодирование в jb2.. сохранить шейпы в bmp формат и читать их обратно из bmp - не проблема..
а проблемы я вижу вот какие:
1) пока не очень понятен механизм определения "одинаковости" символов, кто и как это будет делать и какой д.б. интерфейс для этого? вот, представим, словарь на 1000 символов - что, пользователь должен 76000 раз просмотреть его, чтобы выбрать все цифры и буквы кириллицы (заглавные и строчные)? а то и еще больше - курсив, жирные, латиница, разные шрифты.. это тебе, блин, не просто "вычитка" получится, а "полный пипец".. можно немного облегчить задачу - отдать часть работы на откуп файнридеру - ну, сгруппирует он их как-то, а потом всё-равно эти кучки разгребать как-то надо - и всё вручную..
2) ну, допустим, отсортировали мы символы, выбрали лучшие из лучших, но.. размеры символов могут немного отличаться - на глаз особо не заметишь, а когда они встанут в ряд, тут начнется - буквы будут "плясать" по высоте, расположение их уже не будет "в линию", разные межбуквенные интервалы, разная жирность и т.п.. в итоге вместо "идеально ровного и красивого" документа получим хаотичный, плохо читаемый набор "красивых" букв..
более-менее что-то приличное может получиться только на почти идеальном исходном материале, но зачем столько геморроя, чтобы улучшать и так хорошее?
в общем, идея хорошая (как и мир во всём мире), только на практике слабо реализуемая.. по трудозатратам будет значительно превышать вычитку, а конечный результат далеко не всегда будет оправдывать ожидания.. так что, пока нет..

Цитата:

1) пока не очень понятен механизм определения "одинаковости" символов, кто и как это будет делать и какой д.б. интерфейс для этого? вот, представим, словарь на 1000 символов - что, пользователь должен 76000 раз просмотреть его, чтобы выбрать все цифры и буквы кириллицы (заглавные и строчные)? а то и еще больше - курсив, жирные, латиница, разные шрифты.. это тебе, блин, не просто "вычитка" получится, а "полный пипец".. можно немного облегчить задачу - отдать часть работы на откуп файнридеру - ну, сгруппирует он их как-то, а потом всё-равно эти кучки разгребать как-то надо - и всё вручную..

Механизм одинаковости определяется на глаз. Вот сейчас взял книгу на 320 страниц, зажатой агрессивным методом, 100 страниц на словарь, извлек шейпы с помощью djvutoy, получилось 350 шейпов. Например, попадаются шейпы с рваными , или неровными буквами, их заменяем на ровные или нерваные. Пересмотреть все и определить, какой на какой заменить, большого труда не составит, это не 76 0000.


Цитата:

2) ну, допустим, отсортировали мы символы, выбрали лучшие из лучших, но.. размеры символов могут немного отличаться - на глаз особо не заметишь, а когда они встанут в ряд, тут начнется - буквы будут "плясать" по высоте

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

sergiokapone
"а я говорю - купи слона"..
решения ни первой, ни второй проблемы я не увидел.. нужно конкретное пошаговое видение реализации процесса - открываем то, конвертируем сё, смотрим там, вводим сям.. а выражение "определяется на глаз" - ниочём..
насчет количества шейпов - небольшой ликбез по структуре jb2 - информация о шейпах может храниться в т.н. словарях Djbz - они могут быть встроены в страницу или представлять отдельные документы в структуре djvu, используемые несколькими разными страницами.. в то же время, значительная часть шейпов закодирована в чанке Sjbz! эти шейпы (из Sjbz) используются только на данной странице..
что делает DjVuToy - он смотрит, на какие шейпы ссылаются блиты на данной странице, и конвертирует данные шейпы в tif.. из данной информации нельзя понять, сколько шейпов было взято из общего словаря, а сколько из чанка Sjbz..
приведу свой пример - есть файл плохого качества из 2х страниц + общий словарь Djbz - информация из DjVuToy:
1я страница - Total shapes: 833 Total blits: 3305
2я страница - Total shapes: 429 Total blits: 1314
раскодировав данный файл самостоятельно я получаю:
словарь - 208 общих шейпов
1я страница - 625 встроенных шейпов
2я страница - 221 встроенных шейпов (здесь по факту только половина страницы заполнена)
т.е получается, что количество шейпов на странице, не входящих в общий словарь, может быть довольно таки большим, а умножив на количество страниц и прибавив шейпы из общего словаря - получаем вообще огромное количество.. так что те 350 шейпов характеризуют всего одну страницу, во всем документе их может оказаться несколько тысяч..
теперь моё видение данной ситуации - я признаю, что бывают случаи, когда какие-то символы хотелось бы заменить.. и, в принципе, это возможно реализовать с помощью нескольких утилиток, выполняющих следующие функции:
1 - добавление шейпов (и блитов) на страницу (уже сделано)
2 - удаление блитов
3 - смещение блитов
4 - изменение в блитах ссылки на шейп
5 - информация о блитах/шейпах по координатам точки (вспомогательная программа или встроенный в утилиты функционал)
6 - добавление на страницу блита+шейпа из bmp файла (не обязательно)
изменять/удалять сами шейпы не желательно, т.к. согласно спецификации на них могут ссылаться другие шейпы, и изменив один "в нужном направлении", мы можем загубить другой..
программу для удаления блитов я планирую сделать "в обозримом будущем", остальные - может быть при наличии времени/желания..
наличие данных утилит позволит, как говорится, "обработать напильником" отдельные неказистые элементы книги.. "тотальное улучшение" всей книги данным способом по прежнему считаю утопией..

Ясно, так проблему не решить. Тогда, наверное, проблему нужно решать все-таки еще на этапе кодирования. ghosty как-то экспериментировал с этим.

в дополнение к DjVu Blits Merger'у, который позволяет добавлять блиты\шейпы на страницы djvu-книги, сделал программу для удаления блитов со страницы.. правда она удаляет блиты не из файла, а из видимой части страницы книги.. также при необходимости данные удаленные (вернее - скрытые) блиты можно обратно восстановить..
программа DjVu Blits Hider в шапке, описание сделаю позже.. но, имхо, там и так всё интуитивно понятно..
самый наглядный способ - создать в WinDjView аннотации в тех местах, где нужно удалить блиты, сохранить их в файл и указать в программе, что координаты нужно брать из файла *.bookmarks.. только в этом случае перед началом создания аннотаций необходимо убедиться, что данная книга не содержит уже созданных аннотаций, иначе может быть удалено что-то нужное.. проще это сделать в WinDjView Extended - там нужно кликнуть правой клавишей мыши по странице - если появится пункт меню "удалить все аннотации" - значит они уже есть и их надо удалить, если нет - то можно создавать новые..

пофиксил небольшой баг и добавил в шапку [more=описание]DjVu Blits Hider v0.1.1

НАЗНАЧЕНИЕ И ОПИСАНИЕ ПРОГРАММЫ
программа предназначена для удаления со страниц djvu-книги графических изображений mask-слоя (blits).. может применяться для очистки страницы от "грязных пятен", лишних элементов маски и т.п. без перекодирования файла.. совместно с DjVu Blits Merger'ом позволяет редактировать mask-слой djvu-книги - Hider удаляет, а Merger вставляет на это место нужную графику.. есть поддержка Drag & Drop, в поддержке ком. строки не вижу необходимости..

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

есть несколько способов указаний на область скрываемых блитов:
1. Точка - указание координаты точки на странице, которая принадлежит скрываемому блиту.. координаты данной точки можно определить в программе DjView из проекта DjVuLibre, подведя курсор в режиме "выделение" к нужному блиту..
2. X-Y-W-H - указание области, внутри которой блиты будут скрыты - указываются координаты левого нижнего угла прямоугольника, а также его ширина и высота..
3. X-Y-X-Y - то же, что и п.2, только вместо ширины и высоты указываются координаты правого верхнего угла прямоугольника..
4. ..из файла *.bookmarks - области, в которых будут скрыты блиты, определяются из файла закладок и аннотаций программы WinDjView или её модификации WinDjView Extended.. использование модификации предпочтительнее из-за того, что в ней есть функционал определения наличия на странице/в книге существующих аннотаций (если кликнуть по странице ПКМ, то при наличии в книге аннотаций появится пункт меню "удалить все аннотации" - их желательно удалить, чтобы не были скрыты блиты под этими старыми аннотациями).. данный способ указания областей считаю лучшим, так как пользователь видит на экране данные области, а также нет необходимости вручную вбивать координаты.. хотя в определенных случаях другие способы могут оказаться оптимальнее..

галка на пункте "скрывать блиты, частично попадающие в область" позволяет скрывать блиты, которые попали в указанную область не полностью..

при использовании программы стОит всегда помнить, что графические символы в djvu (шейпы), могут быть не того размера и формы, которые изначально представляет пользователь, поэтому после внесения изменений в файл крайне желательно проверить, не удалилось ли чего лишнего и не осталось ли чего ненужного.. в любом случае - все внесенные программой изменения в djvu-файл всегда можно откатить обратно..


СИСТЕМНЫЕ ТРЕБОВАНИЯ
Windows XP+
.NET Framework 2.0


ОПИСАНИЕ ИНТЕРФЕЙСА

Открыть
Сохранить
RU/EN - переключение интерфейса на русский/английский язык

----------
Область редактирования - страницы djvu-книги, на которых скрываются блиты
Весь документ
Страницы (отдельные - через запятую, диапазон - через тире.. пример:
"-4,7,10-12,55-" - редактирование страниц 1,2,3,4,7,10,11,12,55 и до конца документа)

----------
Скрываемая область - область страниц(ы) книги, на которых(ой) будут скрыты блиты
X,Y,W,H / X1,Y1,X2,Y2 - координаты точки или области, под которой будут скрыты блиты
Точка / X-Y-W-H / X-Y-X-Y / Координаты из файла *.bookmarks - способы указания областей, под которыми будут скрыты блиты (см. ОПИСАНИЕ ПРОГРАММЫ)
Скрывать блиты, частично попадающие в область - см. ОПИСАНИЕ ПРОГРАММЫ
Кнопка "Открыть файл *.bookmarks" - открытие другого файла *.bookmarks - требуется если первоначально был открыт не тот файл или скрываемые области хранятся в нескольких файлах *.bookmarks

----------
Скрыть блиты - скрываем блиты в соответствии с настройками на указанных страницах / во всей книге
Восстановить скрытые блиты - восстанавливаем блиты на указанных страницах / во всей книге
после нажатия данных кнопок для внесения изменений в документ необходимо также нажать Сохранить

----------
Статусбар - адрес эл. почты

[/more] на DjVu Blits Hider.. текущая версия 0.1.1

Цитата:

СИСТЕМНЫЕ ТРЕБОВАНИЯ
Windows XP+
.NET Framework 2.0

И .NET Framework все испортил, зачем писать код с использованием этой дряни?

VV123
не собираюсь изучать еще один язык программирования из-за чьих-то религиозных убеждений.. меня всё устраивает..

недавно выяснилось, что DjVu Solo (а м.б. и еще какие-либо древние кодеры) не соблюдают стандарт DjVu
Цитата:

8.3.12 INCL
This is the counterpart to the FORM:DjVi chunk which provides document-level
("shared") information. The INCL chunk simply contains the (unencoded) UTF8
encoded ID of the included component file. To obtain the data for this chunk, the
decoder should look for this ID at in the governing DIRM chunk. The corresponding
chunk must be of type FORM:DJVI and contain the shared chunk.

и пишут название (ID) чанков в кодировке Win-1251 вместо UTF8 - и после INCL, и в кодированную часть DIRM.. это имеет значение, если ID не на латинице, а, например, на кириллице.. в связи с этим DjVu Chunk Remover некорректно работал с данными файлами..
т.к. реализация всех фич, которые я хотел внести в ремувер, может занять продолжительное время, то я решил выпустить промежуточную версию только с данным багфиксом.. текущая версия 0.4.1, ссылки в шапке..
видимо, со временем и в другие программы надо будет ввести проверку на соответствие ID кодировке UTF8, ибо такие древние файлы с кириллицей в названии чанков хоть и очень редко, но встречаются..

Блок word дает пробел для разделения слов. \n в конце слова дает конец абзаца. Блок char дает возможность размещать отдельно две части разорванного переносом слова.
А какие преимущества дает использование блоков line и paragraph в текстовом слое? Про page тоже не очень понятно, в коде, который создает djvuOCR он избыточен, все равно же там по страницам текстовый слой создается.

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

paveleon

Цитата:

Блок word дает пробел для разделения слов.

нет.. пробелы в конце слова добавляют некоторые редакторы (в т.ч. DjVuOCR) для удобства и уменьшения размера текстового слоя.. а вот ФР11 и 12 этого не делают, заключая пробел в блок char

Цитата:

\n в конце слова дает конец абзаца.

имхо не гуд помещать конец абзаца в блок word.. для этого существуют другие блоки, в которые word входит..

Цитата:

Блок char дает возможность размещать отдельно две части разорванного переносом слова.

странное заявление.. а как он это делает?

Цитата:

А какие преимущества дает использование блоков line и paragraph в текстовом слое?

а какие преимущества может давать форматирование текста кроме того, что текст отформатирован? для простого поиска по тексту - никаких, а вот для разных манипуляций с текстом - может дать..
например, есть слово в конце абзаца - если знак перевода строки \n впихнуть в блок word, то при копировании и вставке этого одного слова перевод строки также будет присутствовать.. не критично, но приятного тоже мало..
пример 2 - при выделении текста в просмотрщике (например, WinDjView) при наличии блоков line строки выглядят ровными, намного эстетичнее и приятнее глазу имхо, чем без них.. сравнить можно при просмотре текста из-под ФР11 или 12 и после обработки данной книги Crutch'ем (который помимо прочего вставляет блоки line)
можно еще примеров привести при необходимости, но по-моему и так понятно, что плюсы у форматирования есть..

Цитата:

Про page тоже не очень понятно, в коде, который создает djvuOCR он избыточен, все равно же там по страницам текстовый слой создается.

есть стандарт текстового слоя djvu, в нем предусмотрено 7 различных зон, в т.ч. "экзотические", такие как column и region.. зоны низшего порядка входят в зоны высшего.. от типа используемой зоны зависит, как она координируется относительно "родителя".. абсолютные координаты только у первого родителя.. то, что в извлеченном посредством утилит DjVuLibre текстовом слое стоят абсолютные координаты - это утилиты переводят все смещения "детей" относительно "родителей" в удобочитаемый вид.. видимо, такой порядок был придуман не зря, а для уменьшения размера конечного файла.. теоретически, можно попытаться сделать текстовый слой на одних word'ах, но это может вызвать неправильное отображение выделенного текста в просмотрщиках и увеличить результирующий файл..

Цитата:

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

про редактирование понятно, у меня самого в очень далеких планах сделать редактор текстового слоя djvu, а вот про поиск и тем более просмотр (скрытого текста) - не очень.. можно по-подробнее?

Мне надо было сказать, что я смотрел только как отображает текстовый слой WinDjView. Через него мы можем либо забирать текст в буфер обмена, либо искать строку.
К концу подстрок, оформленных word, в буфере добавляется пробел, при поиске они тоже определяются отдельно. А если подстрока оформлена char, она вставляется в буфер как есть, приклеиваясь к следующей подстроке. При поиске также две соседних подстроки будут совпадать с целым словом.
Этим эффектом можно пользоваться для слов, разорванных переносом строки, или для китайского текста, в котором пробелов вообще нет.
(Если блок line означает графическую строку, он тоже будет усиливать эти разрывы.)
Что в других средствах просмотра я не знаю, надо проверять.


Цитата:

Блок char дает возможность размещать отдельно две части разорванного переносом слова.

Первая часть этого слова (без символа переноса) оформляется блоком char. При копировании в буфер и при поиске слово будет целым. Но на странице графики две его части будут в отдельных прямоугольниках и могут выделяться по отдельности.


Цитата:

если знак перевода строки \n впихнуть в блок word, то при копировании и вставке этого одного слова перевод строки также будет присутствовать

Да, это верно. Еще и пробел от блока word появляется в начале следующей строки.


Цитата:

текстовый слой на одних word'ах

Если точнее, то на char'ах. word эмулируется char с пробелом в конце, но не наоборот.


Цитата:

про поиск и тем более просмотр

Я только про то, что текст извлекается в удобочитаемом виде, правится редактором с проверкой орфографии и регулярными, затем вклеивается обратно. Тут важно сохранить соответствие подстрок-слов. При редактировании где-то надо будет их соединять и разбивать. Вставлять там '=' к примеру.
Еще, на самом первом этапе скрипт дает список разрывов строк с неопределившимся переносом, чтобы вручную указать настоящие дефисы. Это просто, так как отмечать дефисы надо только в 10-20% случаев.
Кстати, вы заметили, что можно вставлять в djvuOCR настоящий юникод, а не восьмеричные коды?

paveleon
что я понял из разговора
1) есть стремление сделать что-то положительное (и хоть это и является на мой взгляд изобретением велосипеда, всё равно, то что есть стремление - это положительный момент)
2) нет понимания, как устроен текстовый слой djvu
3) нет понимания, как реализованы поиск, выделение и копирование в WinDjView
без понимания 2 и 3 сложно сделать что-то стОящее..
касательно корректного поиска при наличии переносов - я заморачивался в своё время и реализовал его на уровне просмотрщика в модификации программы WinDjView Extended.. там есть специальный чекбокс "игнорировать переносы".. насколько помню, для корректного копирования тоже код как-то модифицировал.. рекомендую поюзать прогу, там есть масса удобных фич, отсутствующих в основной версии программы.. возможно, там уже есть всё, что нужно..
в основной версии WinDjView поиск происходит по сплошному тексту, не зависит от деления на блоки, но чувствителен к количеству пробелов между словами, наличию дефисов/переносов.. в Extended я постарался устранить эти недостатки..
DjVuOCR в свою очередь тоже "борется" с переносами, сливая 2 половинки слова в одно в документах, распознанных ФР8.. это же делает FR11 DjVu Text Layer Crutch для документов ФР11 и 12..
таким образом, для нормального поиска по djvu-книге все инструменты есть.. исправлять вручную некоторые неправильно определенные файнридером переносы имхо не имеет смысла, т.к. во-первых - WinDjView Extended прекрасно справится с такими случаями при поиске, а во-вторых - следующий значимый этап по повышению качества текста - это вычитка.. исправление переносов вручную - это только мизерная часть данного процесса, дающая незначительную выгоду только при копировании текста..
если еще осталось желание этим заниматься, могу подсказать что надо делать, ибо всё это я уже проходил, нюансы мне известны.. конкретику лучше обсуждать в личке, т.к. здесь это уже оффтоп..
кстати, все манипуляции с txt-слоем djvu-файла проводит утилита djvused, а не DjVuOCR.. в т.ч. работа с юникодом вместо восьмиричного представления символов - это функция данной программы в относительно "свежих" версиях.. но она имеет ряд "нехороших" встроенных функций, влияющих на оформление текста - так она принудительно вставляет после блока line символ конца строки, после paragraph - 0x1F и т.п.. в Crutch'е есть выбор, что ставить после блоков или ничего не ставить.. но djvused имеет открытые исходники, так что при необходимости можно подправить под себя..

обновил DjVu Chunk Remover до версии 0.5..
основные нововведения - это поддержка одностраничных документов, а также добавление BG44 белого цвета при удалении только фона и добавление FGbz черного цвета при удалении только цвета маски - это позволяет корректно отображать цветные страницы при удалении либо фона, либо цвета маски..

такой вопрос по теме djvu
возможно есть уже программа которая бы позволяла извлекать из готового файла djvu нужный диапазон страниц, как это можно делать с pdf файлами?

спасибо!

Цитата:

balik1982

AVS Document Converter?

скачал AVS Document Converter 3.0.2
с djvu он вообще не работает

balik1982
ну, прям чтоб 1 в 1 с акробатом - такого нет..
а вообще, DjVu Chunk Remover просто и быстро может удалять любые указанные страницы или диапазон.. например, нужно извлечь с 5 по 10 страницу - открываешь книгу в программе, в поле "страницы" указываешь "1-4,11-", отмечаешь чекбокс "удалить страницы", жмешь "удалить" и "сохранить" - указываешь новое имя книги с извлеченными страницами или перезаписываешь старый файл.. получается типа извлечение..

это уже более интересно, попробую.

часто приходится с журналов в djvu извлекать статьи и в DjVuEditor это делать долго и не удобно

balik1982
я функционал по удалению страниц в ремувер встроил именно по той причине, что все другие известные мне методы "долгие и неудобные")))

не подскажите, а где можно найти программу djvutoy?
И чем лучше проводить перевод из формата djvu в картинки, или же в текст, чтобы потом можно было создать файл формата fb2/pdf?

serg3001

Цитата:

djvutoy?

https://www.upload.ee/files/6020609/DjVuToy_2.08_eng.zip.html

Engaged_Clown
там пишет, что заблокировано: содержит вирус или шпион

serg3001
http://s019.radikal.ru/i621/1607/f8/0fddbb9b5a85.png
Всё там нормально, не советую пользоваться говноантивирусами. У меня вообще их нет.

---

Вот оффсайт вроде http://www.gratilog.net/xoops/modules/mydownloads/singlefile.php?cid=62&lid=2796

serg3001

Цитата:

чем лучше проводить перевод из формата djvu в картинки, или же в текст

для меня удобнее всего переводить в картинки с помощью WinDjView Extended - доступны несколько форматов, в т.ч. tif и png.. ну а в текст - файнридер.. кстати, новым файнридерам не требуется перевод из djvu в промежуточный графический формат, они и djvu неплохо хавают..
Engaged_Clown

Цитата:

Вот оффсайт вроде http://www.gratilog.net/xoops/modules/mydownloads/singlefile.php?cid=62&lid=2796

не, оффсайт здесь http://www.cnblogs.com/stronghorse/ , а здесь http://pan.baidu.com/s/1jGrnmsA папка с файлами, тока там всё на китайском..

Цитата:

не подскажите, а где можно найти программу djvutoy?

Оф.сайт
http://www.cnblogs.com/stronghorse/

Цитата:

здесь http://pan.baidu.com/s/1jGrnmsA папка с файлами, тока там всё на китайском..

Все печеньки тут.