» WinDjView

foo
Ещё осталось 2 вещи, которые я хочу включить в новую версию - аннотации и баг с ориентацией текста. Наверно, к концу февраля будет готово. После этого разработка снова заморозится, если я что-то и буду делать то только править баги. В feature requests на SF-сайте есть много разных штук, которые наверно были бы полезны, хотя лично мне они и не кажутся необходимыми, но до лета у меня точно не будет на это времени.

ghosty
Можно, но проще освободить место на диске или печатать по несколько страниц вручную. Аргументация такая же, как в прошлый раз.

Будьте так добры, добавьте, пожалуйста, содержание в стиле Акробата - с многострочными элементами.

Длинные несворачивающиеся строки в содержании - это основной и самый заметный недостаток текущей реализации.

Это скриншот из Акробата:


Знаю, что однострочное содержание - это ограничение стандартного компонента TreeView, так что компонент придётся написать фактически "с нуля". Однако я нашёл на codeproject.com великолепную статью, в которой всё детально описано и даже приложены все исходники и бинарники:
Franc Morales - CStaticTreeCtrl - A CStatic derived custom Tree control

А это скриншот демонстрационной утилиты на C++

kibi

Цитата:

самый заметный недостаток текущей реализации.

Самая свежая статья там уже могла устареть:

Цитата:

Формат DjVu Алексей Федорчук
...
Последняя редакция: 2004.08.22

Самая свежая информация о формате DjVu содержится тут: http://www.lizardtech.com/products/doc/techinfo.php - особенно интересен DjVu File Format Specification Release November 2005. Наибольший вклад в развитие спецификации формата DjVu сейчас вносят именно Лизарды, а вовсе не полуживой DjVuLibre.

По причине скоро наступающего отсутствия времени решил зафиксировать версию 0.4.1 с текущими изменениями. Доступна на вебсайте, есть обновлённый перевод на русский. Следующая версия ожидается скорее всего в апреле/мае. Всё остальное, что писалось здесь на форуме и что я хотел сделать, отмечено у меня в todo и будет постепенно реализовываться по мере возможности.

Changelog: http://windjview.sourceforge.net/changes.txt
Download: http://sourceforge.net/project/showfiles.php?group_id=114927&package_id=124501

AndyZ
Спасибо.
Модераторы
Хорошо бы шапку поднять.

AndyZ
У меня тут возникла довольно спорная мысль, но всё-таки хочется высказать её: многие и многие DjVu-книги идут в виде сдвоенных сканов. Читать их мука, все мы знаем.

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

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

По крайней мере, руками так сделать получается (перемещаться по странице в нужном масштабе буквой Зю ) - значит, возможно и программно так делать.

Таких "сдвоенных" книг тучи и проблема очень актуальна. Они чуть ли не нечитаемы вовсе из-за этого. Я бы так людей наказывал бы: "прочесть и подробно пересказать такую книгу".

Добавлено:
Пример сдвоенной книги: http://www.kpnemo.ru/ebook/2006/02/22/zhak_iv_kusto_filipp_diole_moguchiy_vlastelin_morey/#full

http://rapidshare.de/files/13841653/Moguchiy_vlastelin_morey.rar.html

http://kpnemo.ru/ebook/2006/02/16/zhak_iv_kusto_filipp_kusto_chtobyi_ne_byilo_v_more_tayn/

http://rapidshare.de/files/13398098/Chtobi_ne_bilo_v_more_tayn.rar.html

Добавлено:
Если так сделать, то эту идею можно и дальше развить: сделать специальный визуальный мета-редактор Djvu, чтобы там был некий ползунок и его вручную ставить на каждой странице на границе разворота - и всё это для всех страниц в микрофайл сохранять отдельно или в тот же дежавю-файл внедрять, чтобы тогда уже WinDjView считывал эту мета-информацию и автоматом правильно определял границу разворота.

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

monday2000

Цитата:

Таких "сдвоенных" книг тучи и проблема очень актуальна. Они чуть ли не нечитаемы вовсе из-за этого. Я бы так людей наказывал бы: "прочесть и подробно пересказать такую книгу".

полушутя замечу что проблема решается очень быстро соответственной диагональю монитора.
Я например предпочитаю книги с разворотами и был бы очень рад, если б WinDjView умел эмулировать его как DjvuReader (который к сожалению скончался, так и не доработанный до конца)

terminat0r

Цитата:

Я например предпочитаю книги с разворотами и был бы очень рад, если б WinDjView умел эмулировать его как DjvuReader

Так ведь уже...
Начиная с версии 0.4.

terminat0r

Цитата:

Я например предпочитаю книги с разворотами

Т.е. выведение на экран одновременно левой и правой одиночной страницы - "разворот?" Такое умеют следующие проги:

1. DjVuReader
2. WinDjView 0.4 и выше
3. DjVu Fancy Viewer 1.5

4. http://www.ict.nsc.ru/ws/elpub2001/1728/ :

Цитата:

Программы отображения электронных документов имеют одно общее неудобное свойство - обычно они отображают на экране компьютера только одну страницу. Данное ограничение представляется вполне естественным, учитывая размеры и стоимость мониторов, но опыт показывает, что со временем дисплеи дешевеют. Если в 1995 году пятнадцатидюймовый монитор стоил около 250 долларов США, то в 2000-ном он стоит 150 долларов, а за прежнюю сумму можно позволить себе покупку семнадцатидюймового. Для математиков возможность видеть разворот или две независимые страницы одновременно имеет большое значение, поэтому имеет смысл предоставлять пользователю возможность открытия второй страницы, особенно если его дисплей позволяет выводить их без наложения друг на друга. Plugin от LizardTech устроен таким образом, что эту функцию легко реализовать средствами HTML и JavaScript.

AndyZ
В версии 0.4.1. маленький косячок - в "Настройки":

monday2000
Спасибо, исправлю.

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

AndyZ

Цитата:

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

Что скажете? Насколько реально? (Имеется в виду, чтобы выводить приблизительно "только левую" или "только правую" часть - с небольшим разумным перехлёстом-захватыванием полоски смежной страницы - величину перехлёста чтобы сам юзер регулировал бы каким-нибудь ползунком). Это было бы спасением при чтении сдвоеных сканов.

Добавлено:
Спасибо, что продолжаете делать 98-версию - я вот вижу на 98 винде.

имеется чисто косметическое замечание. при масшабировании в окне отображения масштаба можно видеть значения вида 100,%, 50,% и так далее. думаю запятую в случае целых коэфициентов масштаба лучше не отображать.

AndyZ
Думаю, полезной была бы функция экспорта части документа в картинку. Причем не только видимой на экране части документа (в этом случае можно воспользоваться одной из программ снятия скриншотов), но и выходящей за пределы экрана (экспортировать заданные страницы документа).

MorSe
поддерживаю. а то по одной странице извлекать (как сделано сейчас) не очень-то удобно. приходится использовать для этого другие программы.

MorSe
mramor
А мне кажется, что это практически не имеет смысла - т.к. слишком непросто это имхо реализовать. То есть, наверное, относительно реально сделать групповой экспорт в bmp - код уже есть, надо просто его чуть подправить в сторону "групповости". Вот только всё равно после этого потребуется эту кучу bmp ещё и скопом в тиф перегонять - значит, нужна всё-таки другая прога.

А если делать групповой экспорт в тиф из WinDjView - то это фактически значит целую новую прогу написать, ведь AndyZ должен быть в рамках GPL, значит, придётся приспосабливать libtiff или netpbm - это такое глючилово, я вот недавно ковырялся в libtiff.

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

mramor
Версия WinDjView последняя?

MorSe
Экспорт диапазона страниц в bmp уже есть в todo. Так что через некоторое время сделаю. Когда именно - не знаю.

monday2000
Я могу добавить сочетания клавиш Shift-PgUp, Shift-PgDn, которые будут скроллировать сначала по горизонтали, а потом по вертикали. Это пока самый разумный вариант, который мне приходит в голову. Тогда зум можно выставлять, например, в Fit Height.
Насчёт libtiff - особенных проблем нет, есть библиотека FreeImage, которая оборачивает libtiff в нормальный интерфейс. Но пока никто не смог меня убедить в том, что вообще экспорт страниц в картинку действительно так уж нужен. Кроме того, для этого есть отдельные утилиты. Поэтому если это всё и будет сделано, то самым низким приоритетом.

>monday2000: Когда я писал, что длинные несворачивающиеся строки в содержании - это основной и самый заметный недостаток текущей реализации, я имел в виду реализацию WinDJView, а не сам формат DJVU.

В последнем определении формата DJVU относительно содержания написано следующее -
* размер оглавления - не более 65536 элементов
* не более чем 256 элементов в каждой ветке (за исключением корневого элемента, где количество элементов ограничено 65536)
* длина строки - 8388608 байт или 4194303 знакоместа (в UTF-8) (~4 мегабайта).

О том, что оглавление должно быть однострочным или многострочным ничего в спецификации не сказано, так как это дело автора конкретного просмотрщика.

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

Что реально ограничивается в DJVU, так это определение, что каждая строка содержания может иметь только одну ссылку, то есть пункт оглавления типа "Психологический практикум 125, 137" заложить не получится. Надо будет его разбить на "Психологический практикум 125" и "Психологический практикум 137". И картинок в оглавление тоже не вставишь. Это точно.

kibi
Естественно, имеется в виду word wrap.

AndyZ

Цитата:

Тогда зум можно выставлять, например, в Fit Height.

Не совсем так, речь идёт о масштабе "как-бы Fit Width для одной половинки сдвоенного скана". Выглядеть это может так:

1. Юзер открывает сдвоенный djvu.

2. Меняет масштаб руками так (сделать бы CTRL+мыш. колесо для этого), чтобы в окне просмотра ему был видна только верхняя часть левой половинки сдвоенного скана (у меня получилось 150%) - по всей ширине левой половинки сдвоенного скана. Таким образом, у юзера возникает иллюзия, что он просматривает не сдвоенные, а одиночные сканы на масштабе Fit Width.

3. Нажимает какую-нибудь кнопочку "Запомнить масштаб".

3. При дальнейшем чтении юзер крутит колёсико и, закончив чтение левой половинки сдвоенного скана, попадает не на левую половинку следующего сдвоенного скана - как сейчас - а на правую половинку этого же скана при том же масштабе (150% или что там). То есть перемещаемся по сдвоенному скану в масштабе ~150% по траектории русской буквы "И".

Цитата:

Я могу добавить сочетания клавиш Shift-PgUp, Shift-PgDn, которые будут скроллировать сначала по горизонтали, а потом по вертикали.

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

AndyZ

Цитата:

Версия WinDjView последняя?

предпоследняя . скачал 0.4.1 - запятые пропали. спасибо за наводку .

kibi

Цитата:

О том, что оглавление должно быть однострочным или многострочным ничего в спецификации не сказано, так как это дело автора конкретного просмотрщика.

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

Ничего тут не понял. Я не ставлю себе задачу знать сам формат DjVu, я просто делаю черновую и скучную работу по сбору информации и всё. А уже на этом материале пусть другие пойдут дальше.

Добавлено:
Вот если Вы напишете на своём сайте какую-нибудь подробную интересную статью на тему DjVu (с картинками, понятную чайникам, например "Исследование формата DjVu: вопросы и ответы") или сделаете программу на тему DjVu - с удовольствием поставлю себе линк.

mramor
Не за что. См. первое сообщение в форуме

monday2000
Цитата:

сделать бы CTRL+мыш. колесо для этого

Зум по ctrl+колесу уже сделан.

Цитата:

Нажимает какую-нибудь кнопочку "Запомнить масштаб".

Когда-нибудь будет автоматическое запоминание последнего масштаба для каждого документа.

Цитата:

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

Юзер будет нажимать Shift-PgDn и получать именно такое поведение, о котором Вы пишете. Колёсико зарезервировано за вертикальной прокруткой. Для горизонтальной уже есть Shift+колёсико. Проблема с мгновенным перескоком очевидна на примере Single Page в Adobe Reader - стоит чуть-чуть не рассчитать движение пальца, и программа скроллирует слишком далеко. Всё время приходится возвращаться назад. Поэтому этот вариант отменяется. А вот прыгать по Shift-PgDn гораздо проще, потому что нажать лишний раз кнопку сложнее, чем прокрутить чуть дальше колёсико. Конечно, прыгать зигзагом при этом будет всё равно сложно.

Ещё один аргумент - это очень неочевидная функциональность. У большинства возникнет больше вопросов, чем это даст выгоды. 19-дюймовый монитор (или даже 17) спасёт [вставить по вкусу].

AndyZ

Цитата:

Зум по ctrl+колесу уже сделан.

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

Цитата:

Юзер будет нажимать Shift-PgDn и получать именно такое поведение, о котором Вы пишете.

Не пойму ничего - что именно будет происходить при нажатии Shift-PgDn? Какой-то мгновенный перескок? Куда именно - просто с лева на право или с низа-лево на верх-право?

Цитата:

Проблема с мгновенным перескоком очевидна на примере Single Page в Adobe Reader - стоит чуть-чуть не рассчитать движение пальца, и программа скроллирует слишком далеко.

Да, я вот вчера поздно вечером тоже об этом подумал. Может быть, здесь можно какой-то хитрый приём придумать? Например, при попадании на следующую страницу делать выдержку полсекунды, во время которой не прокручивать скан, чтобы юзер успел среагировать? Вот, придумал! Надо так сделать: юзер вращает колесо и мгновенно перескакивает с низа-лево на верх-право (всё это в масштабе "псевдо-FitWidth" (около 150%)). Теперь внимание: попав на верх-право, прога не даёт прокручивать скан вниз до тех пор, пока колёсико не прекратит вращение (т.е. вращение, вызвавшее переход на верх-право). Поймав остановку колёсика, прога опять включает прокрутку вниз колёсиком. Здесь нужно будет немного поэкспериментировать: может быть, надо будет на самом деле ловить паузу определённой длительности в серии коротких скроллирований, такая пауза и будет означать конец "прыжка". Это вполне логично: попав на верх-право, юзеру уже не надо скроллировать - до 1 сек (а то и до 2-3) - т.к. нужно читать уже, а не скроллировать.

У нас студенты, помню, умудрялись делать лабы, где по характеру нажатий на клавиатуру определялась личность нажимающего (т.е. из набора профилей личностей). А тут задача явно проще.

Уж больно заманчива имхо перспектива - просто вращать колёсико и при этом зигзагом перемещаться по сдвоенным сканам. Очень не хочется связываться с клавишами при навигации - я только из-за continuous scrolling имею дело с WinDjView - а так бы на плагине сидел бы.

Цитата:

Ещё один аргумент - это очень неочевидная функциональность. У большинства возникнет больше вопросов, чем это даст выгоды. 19-дюймовый монитор (или даже 17) спасёт [вставить по вкусу].

Позвольте не согласиться. У меня 17-дюймовый монитор, 19-дюймовый покупать не собираюсь - просто не нужен, наверное, так у большинства. Попробуйте посмотреть на 17-дюймовом мониторе сдвоенные сканы даже в режиме полный экран - согласитесь, текст гораздо мельче, чем при "псевдо-FitWidth" (около 150%). Ладно, там, ч.б. битовые сканы - там ещё более-менее чётко текст виден. А если это грубо серые (из сложных случаев это самый типичный) или цветные сканы? Там ни хрена толком не видно даже в полном экране. Я вот про себя решил однозначно - никогда не буду читать книги в сдвоенных сканах (без крайней нужды) - очень уж неудобно.

monday2000
Цитата:

юзер вращает колесо и мгновенно перескакивает с низа-лево на верх-право

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

Цитата:

Попробуйте посмотреть на 17-дюймовом мониторе сдвоенные сканы даже в режиме полный экран

Попробовать не могу, ибо такой монитор надо ещё найти. Вроде сейчас у 17'' мониторов то же самое разрешение 1280x1024, как и у большинства 19'', только размер точки меньше.

AndyZ

Цитата:

Но это очень напоминает какое-то шаманство, а я шаманством не люблю заниматься

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

шапка включена

AndyZ
Доброго времени суток!

Есть предложение реализовать поддержку букмарков (bookmarks) или содержания также из внешнего файла (кроме как только из самой дежавушки), например:
есть у нас дежавуха с именем some_djvu_doc.djv и рядом лежит файл с букмарками, т.е. что-то вроде some_djvu_doc.djv.toc или some_djvu_doc.toc,
а от сюда недалеко и до редактируемых favorites bookmarks.

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

nonnus
Букмарки делаются в LizardTech Document Express Editor, а в WinDjView их нельзя делать (т.е. ничего редактировать нельзя).