» WinDjView

IvanStorogev

Цитата:

Смысл такой операции в отсутствии перепаковки JPEG в IW44. Очень удобно разрозненные картинки объедмнять в один файл.

По-моему, это уже такая экзотика... Имхо WinDjView мыслится не просто как очередной DjVu-просмотрщик, а именно в первую очередь как средство для чтения DjVu-книг (колхозных и им подобных). Потому и имхо такой акцент сделан на continuous scrolling - о чём Лизардам позаботиться явно недосуг - наверное, потому, что они-то и гоняются за подобным универсализмом.
Имхо то же самое касается колонтитулов (header & footnote). Я думаю, эта "буржуйская приблуда" актуальна только при дежавючении стопки листов белой бумаги (то, что представляет из себя обычный офисный документ). То есть это совершенно ни к чему в контексте создания и прочтения электронных DjVu-версий бумажных книг - то, что всех нас тут интересует в первую очередь (ни разу эта тема тут нигде вообще не звучала). Гоняться за воплощением каждой мелочи из спецификации - дорогое удовольствие. Может быть, лучше посмотреть на вещи максимально с практической стороны? WinDjView имхо и так самое лучшее сейчас средство для чтения DjVu-книг - по большому счёту, к WinDjView придраться просто не к чему - настолько он вылизан и проработан.

Добавлено:
AndyZ
Давно я хотел Вас спросить: имхо всё-таки бледновато и даже возможно чуть-чуть более размыто WinDjView отображает иногда (даже вроде бы не всегда) некоторые Djvu-документы. Вот скриншоты одной и той же страницы:

DjVu Plugin 5.0.2:
http://img145.imageshack.us/img145/6200/plugin8cm.jpg (98 КБ)

WinDjView 0.3.5:
http://img138.imageshack.us/img138/6762/windjview5xp.jpg (88 КБ)

(Это какая-то спецификация - то ли эта http://www.lizardtech.com/files/doc/techinfo/DjVu3Spec.djvu , то ли аналогичная). Видите разницу визуально? По-моему, есть. Что это? Я так думаю - это некое несовершенство самого DjVuLibre. И как бы тут побороться? (Желательно конкретный совет).

Цитата:

Давно я хотел Вас спросить: имхо всё-таки бледновато и даже возможно чуть-чуть более размыто WinDjView отображает иногда (даже вроде бы не всегда) некоторые Djvu-документы.

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

AndyZ

Цитата:

Это даёт то, что я её хорошо знаю и люблю использовать.

А заодно - чтобы чужие шаловливые ручки там не баловались.

И ещё у меня к Вам такой вопрос: можно ли использовать исходники WinDjView, чтобы скомпилировать (конечно, хотелось бы все ) консольные экзешники из последнего DjVuLibre (вот эти http://djvulibre.djvuzone.org/doc/index.html )? Если "да" - может быть, это лучше Вам сделать? Извиняюсь за такое нахальство, просто если я туда полезу - ещё что-нибудь напортачу раз, и потом - это же Ваша разработка, как-то неудобно мне эксплуатировать продукт чужого труда вот таким образом. Либо посоветуйте мне как конкретно, и я сам попробую это сделать - не знаю, как лучше, но очень хочется наконец-таки составить готовые компиляционные проекты для DjVuLibre консольных экзешников под MS VC++ 6.0.

А тогда уже желающие смогут (в значительной степени) сами программировать то, что им нужно - если это будет достаточно просто.

Добавлено:
Да, можно будет тогда уже открыть тут, в "Программы" (а то и в "eBookz") тему по DjvuLibre - заинтересованные лица могут быть. (Например, рубордовец Илья Менжиров aka alih, да и другие могут найтись).

Цитата:

Я использую те алгоритмы, которые заложены в DjVuLibre. Там реализована быстрая билинейная интерполяция, причём для чёрно-белых документов есть отдельный оптимизированный алгоритм. Он действительно быстрый - ресайз картинок размерами 3000x4000 пикселей до ширины экрана происходит за доли секунды. Это идеально для непрерывного скроллинга - если скроллировать с разумной скоростью, то новые страницы всегда успевают отрисоваться в фоновом режиме. Цветные страницы ресайзятся медленнее, но всё равно достаточно быстро.

С год назад я пробовал другие open-source реализации ресайзинга, но они все работали существенно медленнее, чем текущий вариант. Если Вам удастся найти готовый алгоритм, который будет давать лучшее качество при сравнимом времени работы, то я могу его использовать.

Посмотрите на алгоритм (оченно старинный, Фанта \Fant's resampling algorithm\), используемый в pnmscale из netpbm библиотеки, он очень простой, но работает быстро, особенно версия на целых числах pnmscalefixed. Его, похоже, и используют лизардовцы, т.к. результаты ресемплинга отличить нельзя.

Могу написать/выдрать нужные функции, сообщите только интерфейс.
Если добавиться этот алгоритм, в качестве альтернативы, то WinDjView станет не подражаемой прогой

monday2000
Цитата:

можно ли использовать исходники WinDjView, чтобы скомпилировать (конечно, хотелось бы все) консольные экзешники из последнего DjVuLibre

Исходники WinDjView тут вроде ни при чём - но можно использовать подредактированную мной DjVuLibre и makefile. Нужно просто написать правильный makefile, чтобы компилить эти утилиты. Ну или проекты, если они Вам больше нравятся.

Цитата:

Вот скриншоты одной и той же страницы

Как ни странно, но мне скриншот из WinDjView нравится больше, потому что текст более сглаженный, а на скрине из плагина он более угловатый, и более заметно то, что буквы не находятся на одной линии по горизонтали. Я думаю, похожего эффекта можно достичь, уменьшая гамму. Ещё я заметил, что у ваших скриншотов подозрительно маленькое разрешение. На 1280x1024 всё выглядит гораздо лучше Да и оптимизировать под разрешение менее 1024x768 судя по статистике уже не имеет смысла.

foo
Цитата:

Могу написать/выдрать нужные функции, сообщите только интерфейс.

Например, интерфейс такой - на входе и на выходе DIB (то есть BITMAPINFO и указатель pBits).

AndyZ

Цитата:

Например, интерфейс такой - на входе и на выходе DIB (то есть BITMAPINFO и указатель pBits).

Т.е. вы хотите масштабировать уже на стадии вывода на экран, может быть лучше это делать после получения данных (немасштабированных) из DjVuLibre, перед помещением в кеш? Т.е. делаем обертку для функций get_bitmap, get_fg_pixmap, get_bg_pixmap?
Или даже изменить саму DjVuLibre?

AndyZ
Не получается создать lib-файлы из исходников WinDjView 0.4. Ни под Win98, ни под Win2000. Использую одну и ту же команду:
Цитата:

nmake "DEBUG=1" "UNICODE=0" /f makefile

(находясь в папке WinDjView-0.4\libdjvu)

Win98:
Цитата:

IFFByteStream.cpp(71) : fatal error C1034: assert.h: no include path set
IW44EncodeCodec.cpp
DjVuGlobal.h(73) : fatal error C1034: new.h: no include path set
IW44Image.cpp

Это у меня, видимо, какая-то системная переменная не прописана. Path = "C:\Program Files\Microsoft Visual Studio\VC98\Bin" я руками прописал в autoexec.bat. Надо что-то ещё прописать?

Win2000: Здесь я при инсталляции MS VC++ 6.0 сразу указал зарегистрировать переменные среды - и проблем типа "no include path set" не возникает уже. Но тут своё:
Цитата:

GRect.cpp(276) : warning C4244: 'return' : conversion from '__int64' to 'int', p
ossible loss of data
GRect.cpp(278) : warning C4244: 'return' : conversion from '__int64' to 'int', p
ossible loss of data
GRect.cpp(287) : warning C4244: 'return' : conversion from '__int64' to 'int', p
ossible loss of data
GRect.cpp(289) : warning C4244: 'return' : conversion from '__int64' to 'int', p
ossible loss of data

Цитата:

Generating Code...
LIB : fatal error LNK1104: cannot open file "..\Debug_Unicode\libdjvud.lib"
NMAKE : fatal error U1077: 'lib' : return code '0x450'
Stop.

В обоих ОС успевает сгенериться некоторое количество obj-файлов при этом. Да, ответьте, пожалуйста, на дурацкий вопрос - в чём разница между "Debug" и "Release"? Всю жизнь ломаю над этим голову. И зачем мэйкфайлу указывать "UNICODE=0" или "UNICODE=1" - чем либы будут отличаться и есть ли подобный "Уникод-выбор" в "родной" последней DjVuLibre?

Добавлено:
AndyZ

Цитата:

Ну или проекты, если они Вам больше нравятся.

Да, хотелось бы уйти от компиляции lib-файлов, а просто понаделать dsw-проекты для каждого (для которого получится) консольного приложения на http://djvulibre.djvuzone.org/doc/index.html . Наверное, так сложнее тем, что потребуется включить в dsw-проект уйму других файлов (тех, из которых либы компилятся), но зато сохранится максимальная прозрачность и можно будет в любом dsw-проекте сразу прыгнуть на определение любой функции. Один разок помучаться и составить эти dsw-проекты, а потом просто уже открывать и подправлять, как кому надо, добавлять там свои cpp-файлы, или менять существующие.


Добавлено:
В общем, взял я исходники djvulibre-3.5.16 и пытаюсь в лоб скомпилировать cjb2.cpp. Открыл его, компильнул в djvulibre-3.5.16\tools файл cjb2.cpp, создался dsw-проект, прописал в Tools - Options - Directories include-путь "C:\DJVU\DJVULIBRE-3.5.16\LIBDJVU". Теперь cjb2.cpp успешно компилируется, но экзешник, разумеется, пока не билдится. Подскажите, что надо сделать. Выдаются такие ошибки:

Цитата:

--------------------Configuration: cjb2 - Win32 Debug--------------------
Linking...
cjb2.obj : error LNK2001: unresolved external symbol "public: __thiscall GArrayBase::~GArrayBase(void)" (??1GArrayBase@@QAE@XZ)
cjb2.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall GException::~GException(void)" (??1GException@@UAE@XZ)
cjb2.obj : error LNK2001: unresolved external symbol "public: static void __cdecl GExceptionHandler::exthrow(class GException const &)" (?exthrow@GExceptionHandler@@SAXABVGException@@@Z)
cjb2.obj : error LNK2001: unresolved external symbol "public: __thiscall GException::GException(char const *

Ну и так далее. Пытаюсь добавлять в проект "Project" - "Add to project" - "Files" наугад cpp-файлы из "C:\DjVu\djvulibre-3.5.16\tools" - такие, где windows-поиском можно найти имена из списка ошибок unresolved external symbol. Надо ли включать ещё и одноимённые (соответствующие) h-файлы при этом? (Или нужные заголовки функций уже сидят в каком-нибудь большом уже подключённом h-файле?) А то, чем больше я добавляю cpp-файлов, тем больше ошибок unresolved external symbol. Подскажите пожалуйста, что надо сделать, чтобы получить cjb2.exe таким способом (не создавая заранее свои lib-файлы). То есть, правильно ли я действую? Просто я ещё не успел до конца так дойти - ошибок-то всё больше и больше. А дальше, если разберусь, уже буду сам пробовать другие экзешники сделать - по аналогии.

То есть важно не просто сделать экзешники, а именно составить dsw-файлы для каждого из них - чтобы юзер потом запустил dsw-файл, нажал пункт "Rebuild all" и всё, и получил Windows-экзешник (ну там include-пути прописать самое большее чтобы ему).

monday2000

Цитата:

Generating Code...
LIB : fatal error LNK1104: cannot open file "..\Debug_Unicode\libdjvud.lib"
NMAKE : fatal error U1077: 'lib' : return code '0x450'
Stop.

Предварительно нужно создать соответствующие папки ..\Debug_Unicode, ..\Debug, ..\Release_Unicode, ..\Release или попытаться откомпилировать сами проекты WinDjView, тогда они создадуться автоматически и либы собирутся нормально.

foo
Цитата:

...может быть лучше это делать после получения данных (немасштабированных) из DjVuLibre, перед помещением в кеш? Т.е. делаем обертку для функций get_bitmap, get_fg_pixmap, get_bg_pixmap?

Я имел в виду именно такой вариант.

monday2000
Цитата:

Надо что-то ещё прописать?

Нужно настроить переменные среды INCLUDE, LIB и PATH. Это делает либо инсталлятор, либо файл vcvars32.bat. На предупреждения не обращайте внимания.

Цитата:

nmake "DEBUG=1" "UNICODE=0" /f makefile

Если мейкфайл называется makefile, то ключ /f указывать не обязательно. И "UNICODE=0" не надо. То есть варианты команд такие: nmake, nmake "DEBUG=1", nmake "UNICODE=1" и nmake "DEBUG=1" "UNICODE=1". Кавычки, наверно, необязательны.

Цитата:

в чём разница между "Debug" и "Release"?

В опциях компилятора и в подключаемых библиотеках. В debug включена отладочная информация, а в release нет. Кроме того, в debug выключены оптимизации, а в release они, наоборот, включены.

Цитата:

И зачем мэйкфайлу указывать "UNICODE=0" или "UNICODE=1" - чем либы будут отличаться и есть ли подобный "Уникод-выбор" в "родной" последней DjVuLibre?

Я подозреваю, что ничем. Это просто для consistency - чтобы уникодный exe файл линковался с уникодной либой. Опция UNICODE даёт то, что вызываются специальные unicode-варианты WinAPI функций.

Цитата:

что надо сделать, чтобы получить cjb2.exe таким способом (не создавая заранее свои lib-файлы)

Создать проект, в который включены все используемые cpp файлы (включая файлы из djvulibre). Лучше конечно создать отдельный проект для djvulibre, который будет генерить lib, и отдельный проект для cjb2, который будет с этой либой линковаться, добавить их в один и тот же workspace и проставить project dependencies.

foo
AndyZ
Спасибо за ответы! Очень существенно. Буду теперь обязательно "грызть" по крайней мере cjb2.cpp.
AndyZ

Цитата:

проставить project dependencies.

А что это такое - "project dependencies"? Просто я при написании своих простейших консольных прог всегда обходился 1 dsw-проектом. Я всё это дело изучал вот по этой книжке: http://downloads.ebuki.apvs.ru/_UNSORTED/Microsoft.Press.Programming.Windows.5th.Edition.chm - прочитал её с экрана почти всю год назад.

monday2000
.dsw - это не project, а workspace. Проект - это .dsp. В одном workspace может быть несколько проектов, причём можно указать зависимости между ними - то есть в каком порядке компилировать.

Ваша ссылка на книгу не работает. Я сам в основном изучал не по книгам, а по примерам из студии, ну и конечно MSDN и Google.

AndyZ
Спасибо.

Цитата:

Ваша ссылка на книгу не работает.

А, значит там RuIPs only. Книжка имхо замечательная - простая и понятная. С нуля обучает вообще. Вот зеркало: http://rapidshare.de/files/11000134/Programming_Windows_.CHM.html А вот эту только сейчас заметил (т.е. не читал) http://rapidshare.de/files/10585630/Programming_Windws_with_MFC.chm.html - наверное, тоже полезная.


Добавлено:
Тут есть тема по российским прокси: http://forum.ru-board.com/topic.cgi?forum=55&topic=0281&glp .

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

AndyZ

Цитата:

Из тех списков, которые публикуют, работают единицы, и те прикрывают за несколько часов.

Интересно. Я встречал и коммерческие службы - $1 за 1 ГБ - через русский прокси. Выйти на них можно через форум бесплатного сервиса fload.ru.

Добавлено:
Вчера я сумел скомпилировать cjb2.exe под MS VC++ 6.0. Кому интересно, вот выложил:

http://rapidshare.de/files/12855747/cjb2_exe_msvcpp6.rar.html (148 КБ)

Попутно нашёл микробаг в исходниках, подправил (без этого не компилировалось). Описание внутри архива. Теперь займусь прочими консольными программами от DjVuLibre. Вообще-то это, конечно, не новость -скомпилированные под Win DjVuLibre-исходники вот тут лежат уже года 2: http://djvu.anadelta.com/WinDjvu.zip - но там просто сами экзешники, а dsp-dsw-файлы не прилагаются для их компиляции.

Добавлено:
Интересно, что экзешник из конфигурации "Release" больше такового из конфигурации "Debug" ровно на 700 КБ - 284 и 984 КБ. Не знаете ли, как сделать конфигурацию "Release" по умолчанию? А то при открытии dsw-файла исходники билдятся по-умолчанию в "Debug".

AndyZ
Послал по почте файлы с новым методом ресемпоинга.

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

У меня есть несколько вопросов по Вашей реализации: 1) почему для thumbnails используется исходный алгоритм, 2) почему если размер картинки увеличивается, что используется исходный алгоритм, и 3) я совершенно не понял смысл строк 194-199 в RenderThread.cpp - комментарий "Skip custom scale if near to actual size" е соответствует коду. Почему при условии в строке 195 тоже используется исходный алгоритм?

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

Закончил компиляцию DjVuLibre 3.5.16 для Win32. Поместил соответствующую информацию тут: http://sourceforge.net/forum/forum.php?thread_id=1439736&forum_id=103285 .

Скачать комплект можно тут: http://rapidshare.de/files/13157024/DjVuLibre_3_5_16_Win32.rar.html (1,35 MB)

Присоединяюсь к просьбе F3GBJU! И спасибо за замечательную программу и активную разработку

AndyZ

Цитата:

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

Для больших масштабов этот алгоритм и не нужен, там и так все хорошо, он нужен как раз при уменьшении.


Цитата:

У меня есть несколько вопросов по Вашей реализации: 1) почему для thumbnails используется исходный алгоритм?

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


Цитата:

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

По той же самой причине - встроенный алгоритм работает быстрее, а видимой разницы при upsampling'е, практически нет.


Цитата:

3) я совершенно не понял смысл строк 194-199 в RenderThread.cpp - комментарий "Skip custom scale if near to actual size" е соответствует коду. Почему при условии в строке 195 тоже используется исходный алгоритм?

Этот кусок я взял из DjVuLibre, здесь определяется является ли требуемый размер практически идентичным оригинальному (+/- 15 пикселей), если да, то ресемплинга не происходит, или он делается быстро. Т.е. смысл этого куска, если мы имеем Actul Size, то пусть его обрабатывет DjVuLibre, по приведенным выше причинам.

На мой взгляд, это является оптимальным решением.

Цитата:

Если разница небольшая, то я включу его в следующую версию.

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

foo
Цитата:

Этот кусок я взял из DjVuLibre, здесь определяется является ли требуемый размер практически идентичным оригинальному (+/- 15 пикселей), если да, то ресемплинга не происходит, или он делается быстро. Т.е. смысл этого куска, если мы имеем Actul Size, то пусть его обрабатывет DjVuLibre, по приведенным выше причинам.

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

Насчёт скорости - судя по замерам, новый алгоритм работает примерно в 2 раза медленнее.

Добавлено:
По-видимому, правило должно быть такое: если и ширина и высота картинки больше чем в 2 раза меньше, чем у исходной, то можно использовать новый алгоритм. Вроде бы если картинка больше, то новый алгоритм даёт качество даже чуть хуже, чем сейчас. А на таких маленьких картинках, как thumbnails, разница и в скорости и в качестве почти незамента.

AndyZ

Цитата:

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

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


Цитата:

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

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


Цитата:

А на таких маленьких картинках, как thumbnails, разница и в скорости и в качестве почти незамента

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

Я скомпилировал консольную утилиту cjb2.cpp из DjVuLibre 3.5.16 под Win32 - с поддержкой TIFF. Поместил соответствующую информацию там же: http://sourceforge.net/forum/forum.php?thread_id=1439736&forum_id=103285 .

Скачать пакет можно тут: http://rapidshare.de/files/13232587/cjb2t.rar.html (243 KB)

Сам экзешник я назвал чуть-чуть иначе - "cjb2t.exe" - вместо родного названия "cjb2.exe" - чтобы не перепутать с первоначальным "простым" cjb2.exe. Там же прилагается компиляционый проект под MS VC++ v6.0 - т.е. каждый теперь может сам скомпилировать.

Вот какая неприятная проблема вырисовалась. Имеется *.djvu - 7 полноцветных страниц (скан журнала). При попытке его распечатать из WinDjview на диске создается зачем-то огромный своп-файл в 620 мегов (на 4 страницы), после чего место на диске, задание пропадает из очереди печати, и печать не происходит.
С чем это может быть связано, и можно ли этого избежать? Спасибо.

ghosty
Версия WinDjView последняя? Какая версия Windows? Какой принтер? Установлен ли последний драйвер?

Механизм печати следующий: WinDjView отсылает драйверу принтера исходные полноразмерные полноцветные страницы, после чего сам драйвер производит масштабирование (и преобразование к чёрно-белому виду). Так сделано потому, что как показали эксперименты, именно такой метод даёт наилучшее качество печати. А в процессе работы драйвера создаётся тот самый файл.

Если журнал A4 отсканирован в разрешении 600 dpi, то каждая страница, отсылаемая на принтер, будет занимать по 100 мегабайт. По-видимому, драйвер с этим не справляется. Попробуйте печатать по 2-3 страницы за раз.

AndyZ

Цитата:

Если журнал A4 отсканирован в разрешении 600 dpi, то каждая страница, отсылаемая на принтер, будет занимать по 100 мегабайт. По-видимому, драйвер с этим не справляется. Попробуйте печатать по 2-3 страницы за раз.

Да, скорее всего, именно в этом разрешении он и отсканирован. Потому что после того, как я освободил место на диске, мне удалось распечатать все 7 страниц. При этом было использовано 715 Мб.

Цитата:

Версия WinDjView последняя? Какая версия Windows? Какой принтер? Установлен ли последний драйвер?

Последняя. WinXP SP2. HP 1000w. Установлен.

Т.е. избежать создания такого большого спул-файла (без потери качества) не удастся?
Как-то странно все-таки. М.б. возможен перевод этих самых исходных полноразмерных полноцветных страниц в JPG, например, перед передачей драйверу?
Та же проблема, кстати, и с печатью из офиц. плагина, поэтому это ни в коем случае не критика, а стремление как-то разобраться...

AndyZ
Такое небольшое пожелание: нельзя ли сделать фичу "Reload" (и по F5) - чтобы файл перезагружался и причём та же страница выводилась? А то я тут сейчас руками в Эдиторе делаю гиперссылочное оглавление в одной книжке (т.е. изображение пунктов оглавления делаю как ссылки) - и приходится после вставки очередной гиперссылки вручную переоткрывать книгу и листать на страницу с оглавлением - чтобы посмотреть, что получилось. Кстати, в дежавю-плагине по-моему такой фичи тоже нет.

ghosty
Цитата:

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

Может быть и можно, но, честно говоря, совершенно не хочется этим заниматься. Печатает - и хорошо.

monday2000
Цитата:

нельзя ли сделать фичу "Reload" (и по F5)

Не получится, вроде всё равно придётся закрывать файл в WinDjView перед тем как нажимать Save в редакторе. Можно не листать, а вводить номер страницы на тулбаре. Наверно помогут favorites, но когда они появятся сказать не могу. А почему нельзя проставить сразу все ссылки, а потом проверять что получилось?

AndyZ
Когда ожидается новая версия ? Может быть нужно с чем-нибудь помочь?

AndyZ

Цитата:

Может быть и можно, но, честно говоря, совершенно не хочется этим заниматься. Печатает - и хорошо.

Я Вас хорошо понимаю, мне тоже, наверное, было бы лениво с этим возиться Но представьте себе, если у человека не 7 листов, а 70 %)
Хотя, возможно, лучше задать этот вопрос в другой ветке.

Добавлено:
Вот, еще придумал: может быть, можно сделать такую опцию, чтобы печать автоматически происходила страница за страницей (только после того, как отпечатана одна страница, подавать на печать другую) в том случае, если, например, величина страницы при печати будет превышать, к примеру, 20 Мб. Или это тоже сложно?