Компиляция DjVuLibre 3.5.23 под MS VC++ 6.0

[monday2000]

Недавно вышла новая версия DjVuLibre - 3.5.23:

NEW IN VERSION 3.5.23
------------------------
- Djview3 has been deprecated by djview4 whose source comes in
  its own tarball. Use configure option --enable-djview to force
  the compilation of djview3.
- Set ddjvuapi_version to 19.
- Added ddjvu_document_create_by_filename_utf8
- Generate icons with rsvg rather than imagemagick.
- djvused: correctly outputs escape characters.
- djvumake: added options to generate foreground colors.
- Various bug fixes.

[monday2000]

Леон Боту по моей просьбе подправил страницу http://djvu.sourceforge.net/doc/man/djvumake.html . А именно, подправлено описание опции FGbz - добавлено описание цветов и зон раскраски.

И плюс Леон сумел исправить глюк в ddjvu - неспособность создавать PDF. Леон даже прислал мне исправленную скомпилированную версию под Windows! Это при том, что Леон - закоренелый линуксоид, у него вроде винды отродясь не было. Хотя он прислал мне этот файл для тестирования:

http://www.djvu-soft.narod.ru/soft/ddjvu_pdf.rar (28 КБ)

Но он оказался правильно работающим (впервые). Т.е. пока ddjvu.exe, доступный на сайте DjVuLibre, работает неправильно - а этот - правильно.

[monday2000]

Леон прислал мне письмо, в котором сказал, что он "залил исправленную версию". Я не совсем понял, что он имеет в виду - наверное, имеется в виду сайт http://djvu.sourceforge.net/ .

[monday2000]

Мне удалось скомпилировать DjVuLibre 3.5.23 в MS VC++ 6.0.

Это довольно важное достижение для меня. Дело в том, что я пользуюсь DjVuLibre 3.5.17, которая уже успела ощутимо устареть, и поэтому использовать её в последнее время стало просто мучительно.

Мне пришлось для этого кое-что подправить в исходниках DjVuLibre 3.5.23. Все исправления я отправил Леону Боту.

В результате получились совершенно те же самые обычные DjVuLibre-утилиты - такие же, как и в DjVuLibre 3.5.17 по своим свойствам. Т.е. они не зависят ни от каких DLL, и не поддерживают TIF.

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

[monday2000]

Выкладываю DjVuLibre 3.5.23, скомпилированную (вся целиком) в MS VC++ 6.0:

Исходники:

http://www.djvu-soft.narod.ru/soft/djvulibre_v3_5_23m_src.rar  (658 КБ)

Экзешники:

http://www.djvu-soft.narod.ru/soft/djvulibre_v3_5_23m_bin.rar  (1,38 МБ)

Это исходники и экзешники всех обычных DjVuLibre-утилит http://djvu.sourceforge.net/doc/index.html плюс ещё 4 моих клона с этих утилит:

fi_ddjvu, fi_c44, djvudumpm, djvumakem.

Утилиты не нуждаются ни в каких DLL и скомпилированы без поддержки TIFF. Исходники слегка подправлены, чтобы их можно было скомпилировать в MS VC++ 6.0 (а также, естественно, содержат компиляционный проект под MS VC++ 6.0).

Мне хотелось бы, чтобы Леон Боту занёс в DjVuLibre 3.5.23 мои исправления в коде DjVuLibre, а также компиляционный проект для MS VC++ 6.0 - короче, я хочу, чтобы и официальный DjVuLibre 3.5.23 теперь стал компилироваться в MS VC++ 6.0.

Но что-то Леон уже 2 раза последние промолчал в ответ на мои письма.

[monday2000]

Леон Боту прислал мне письмо в ответ на замеченные проблемы при компиляции DjVuLibre 3.5.23 в MS VC++ 6.0. Привожу с моими вопросами:
Я наконец-то сумел скомпилировать DjVuLibre 3.5.23 в MS VC++ 6.0

In general I absolutely dislike to change the code for buggy compilers.
This is too expensive to maintain in the long run.

Я заметил небольшой баг. В djvutxt я заменил

#include "libdjvu/miniexp.h"
#include "libdjvu/ddjvuapi.h"

на

#include "../libdjvu/miniexp.h"
#include "../libdjvu/ddjvuapi.h"

чтобы суметь скомпилировать djvutxt.

This happens because the compiler options are incorrect: you need to specify ".." as a potential directory for include files.

Баг № 2:

d:\djvulibre-3.5.23\libdjvu\atomic.cpp(293) : error C2664: 'InterlockedExchange' :
cannot convert parameter 1 from 'volatile long *' to 'long *' Conversion loses qualifiers

I changed the test to
 #elif defined(WIN32) && !defined(USE_WIN32_INTERLOCKED)
 # define USE_WIN32_INTERLOCKED 1
so you can just define USE_WIN32_INTELOCKED to 0 in the compiler options.

Баг № 3

d:\djvulibre-3.5.23\libdjvu\jb2image.cpp(586) : error C2248: 'get_bounding_box' : cannot access private member declared in class 'JB2Dict'
        d:\djvulibre-3.5.23\libdjvu\jb2image.h(338) : see declaration of 'get_bounding_box'

No way I make that public.
I've added a friend class JB2Codec declaration after the private. Maybe this works for you (it should not be necessary, and I'll remove it if other compilers complain about it.)

[monday2000]

Возвращаюсь к теме после длительного перерыва.

Сегодня я придумал, как устранить Баг №3. Вот изменённый код:

См. http://djvu.cvs.sourceforge.net/viewvc/djvu/djvulibre-3.5/libdjvu/JB2Image.cpp?revision=1.13&view=markup строка 1057. Там есть функция "void JB2Dict::JB2Codec::Decode::code(const GP<JB2Dict> &gjim)". Я изменил её следующим образом:

Код: [Выделить]

void
JB2Dict::JB2Codec::Decode::code(const GP<JB2Dict> &gjim)
{
  if(!gjim)
  {
    G_THROW( ERR_MSG("JB2Image.bad_number") );
  }
  JB2Dict &jim=*gjim;
  // -------------------------
  // THIS IS THE DECODING PART
  // -------------------------
  int rectype;
  JB2Shape tmpshape;
  do {
    code_record(rectype, gjim, &tmpshape);       
  } while(rectype != END_OF_DATA);
  if (!gotstartrecordp)
    G_THROW( ERR_MSG("JB2Image.no_start") );
  // cache bounding boxes
  int nshapes = jim.get_shape_count();
  int ishapes = jim.get_inherited_shape_count();
  //jim.boxes.resize(0, nshapes-ishapes-1);
  jim.boxes_resize(nshapes, ishapes);
  for (int i = ishapes; i < nshapes; i++)
    //jim.boxes[i-ishapes] = libinfo[i];
        jim.boxes_set_at(i-ishapes, libinfo[i]);
  // compress
  jim.compress();
}

// Добавленная мною функция
void JB2Dict::boxes_resize(int nshapes, int ishapes)
{
        boxes.resize(0, nshapes-ishapes-1);
}

// Добавленная мною функция
void JB2Dict::boxes_set_at(int pos, LibRect& value)
{
        boxes[pos] = value;
}В общем, я просто сделал 2 новые простенькие функции-помощника, которые обращаются к закрытым полям класса - и так обошёл проблему. Также нужно добавить объявления этих 2 функций в JB2Image.h

Написал сегодня письмо Леону Боту, предложил внести эти изменения в CVS DjVuLibre.

Эти исправления для меня крайне важны. Без них я не мог скомпилировать последние версии исходников DjVuLibre в привычном мне компиляторе MS VC++ 6.0.

Теперь же эта проблема, наконец, решена (надеюсь). Теперь я получаю возможность актуально синхронизироваться с CVS DjVuLibre и другие плюсы.

[monday2000]

К сожалению, Леон мне не ответил. Впрочем, он ранее мне написал, что он не будет "приспосабливать DjvuLibre под старые глючные компиляторы".

Изложу в одном посте, какие нужно сделать изменения в исходниках DjVuLibre 3.5.24 (теперь уже 24 версия), чтобы они компилировались под MS VC++ 6.0.

1. В файле ddjvuapi.h нужно закомментировать такой кусок кода (в верхней части файла):

Код: [Выделить]

#include <stdlib.h>
#include <stdio.h>
/*
#ifndef DDJVUAPI
# ifdef WIN32
#  ifdef DLL_EXPORT
#   define DDJVUAPI __declspec(dllexport)
#  else
#   define DDJVUAPI __declspec(dllimport)
#  endif
# endif
#endif
*/
#ifndef DDJVUAPI
# define DDJVUAPI /**/
#endif
2. В файле miniexpi.h нужно закомментировать такой кусок кода (в верхней части файла):

Код: [Выделить]

/*
#ifndef MINILISPAPI
# ifdef WIN32
#  ifdef DLL_EXPORT
#   define MINILISPAPI __declspec(dllexport)
#  else
#   define MINILISPAPI __declspec(dllimport)
#  endif
# endif
#endif
*/
#ifndef MINILISPAPI
# define MINILISPAPI /**/
#endif
3. В файле DjVuGlobal.h нужно закомментировать такой кусок кода (в верхней части файла):

Код: [Выделить]

/*
#ifdef WIN32
# ifdef DLL_EXPORT
#  define DJVUAPI __declspec(dllexport)
# else
#  define DJVUAPI __declspec(dllimport)
# endif
#endif
*/
4. Вот эта ошибка

d:\djvulibre-3.5.24m\libdjvu\atomic.cpp(293) : error C2664: 'InterlockedExchange' : cannot convert parameter 1 from 'volatile long *' to 'long *'
        Conversion loses qualifiers

исправляется так: в файле atomic.cpp в строке 150 меняем

Код: [Выделить]

#elif defined(WIN32) && !defined(USE_WIN32_INTERLOCKED)
# define USE_WIN32_INTERLOCKED 1на

Код: [Выделить]

#elif defined(WIN32) && !defined(USE_WIN32_INTERLOCKED)
# define USE_WIN32_INTERLOCKED 0
5. В djvutxt меняем:

Код: [Выделить]

#include "libdjvu/miniexp.h"
#include "libdjvu/ddjvuapi.h"
на

Код: [Выделить]

#include "../libdjvu/miniexp.h"
#include "../libdjvu/ddjvuapi.h"
6. Делаем исправление, как описано в предыдущем посте.

7. Скопировать в исходники DjVuLibre 3.5.24 все файлы *.dsp и *.dsw, взятые из DjVuLibre 3.5.17.

[monday2000]

Я предложил Леону Боту модифицировать ddjvu - так, чтобы она могла декодировать в т.ч. и битые DjVu-файлы - т.е. такие, где есть одна или больше битых страниц (а остальные страницы - нормальные).

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

Леон ответил мне следующее:

Well, if the file is broken, it should be corrected.
I believe that making ddjvu silently replace broken pages by white pages is wrong.
Assuming page 7 and 36 are broken, you can always do something like  "ddjvu
--page=1-6,8-35,37-9999  error.djvu".

- L.

То есть, Леону эта идея не понравилась.

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

У меня возникла иная идея: выводить не белые страницы вместо битых, а ... чёрные. Но Леону и это явно не понравилось - он промолчал в ответ.

Честно говоря, битые DjVu-страницы встречаются в жизни исключительно редко. Почти никогда. Но всё же бывают.

В общем, я решил сделать самому такой функционал в fi_ddjvu.

Кстати, кроме битых страниц, есть ещё и особенный случай пустых DjVu-страниц. Такие страницы содержат лишь только INFO-чанк - и больше ничего. Такие страницы создаёт documenttodjvu из чисто белых сканов. Забавно, что djvudecode (в том же DjVu Small) не умеет декодировать такие пустые DjVu-страницы - вываливается с ошибкой. А вот ddjvu (с относительно недавних пор) умеет (в MiniDjVu Plus том же) их декодировать (правда, с руганью "malformed DjVu page") - в чисто белые листы.

Так что у меня fi_ddjvu будет декодировать пустые DjVu-страницы в белые листы, а битые DjVu-страницы - в чёрные листы. Можно было бы ещё больше извратиться - допустим, для битых страниц выдавать белые листы, перечёркнутые крест-накрест по диагонали - но это было бы уже слишком. Думаю, хватит (для понятности) и чёрных листов.

[monday2000]

Леон Боту прислал мне ответ:

I've added one option in ddjvu, -skip, that causes it to skip corrupted pages.

= L.

Молодец Леон, не остался в стороне.

Вот код исправления:
http://djvu.git.sourceforge.net/git/gitweb.cgi?p=djvu/djvulibre.git;a=blobdiff;f=tools/ddjvu.cpp;h=b9cb0384b594deb9fd347d6065a9f5402fbe2e91;hp=981a27070d84dfb2e5ea71dfb36fea4aca9a541e;hb=3cc41e2a72bbd6d34e81a9a214abbebf41cc00c7;hpb=cdb41b482effe58fb8b2c7bfe78f022a9a95671e

[monday2000]

Я предложил Леону Боту реализовать мою старую идею - прикрутить к djvudump опцию текстового вывода. Ну что это такое, что djvudump выводит результат своей работы в стандартный вывод (stdout), а в текстовый файл - нет.

И вот сегодня Леон прислал мне письмо:

Done.

I remember an old email where I suggested to use the ">" redirection operator and you said that this caused problems under some versions of windows.

The syntax is

djvudump [-o outputfile] ...inputfiles...

which keeps things compatible with the previous version of djvudump.

- L.

Вот мой старый топик с изложением этой идеи:
https://sourceforge.net/projects/djvu/forums/forum/103286/topic/3289524

А вот исправление, внесённое Леоном:
http://djvu.git.sourceforge.net/git/gitweb.cgi?p=djvu/djvulibre.git;a=commitdiff;h=6a6e6a047b41a431cfc091bd71fcad554fd79437

[monday2000]

Я на днях обнаружил глюк в djvuxmlparser - он не вставлял в DjVu аннотации из DjVuXML-файла.

Написал Биллу Риемерзу письмо. И вот сегодня он, наконец, исправил глюк. Вот его исправление:

http://djvu.git.sourceforge.net/git/gitweb.cgi?p=djvu/djvulibre.git;a=commitdiff;h=6db359d1ad5e7e863fac53301e7ff884cfe44423

Теперь всё работает.

[monday2000]

У ddjvu обнаружилась одна неприятная проблема: программа оказалась неспособной различать "серые" и "цветные" DjVu-файлы. Я специально беру эти термины в кавычки, потому что чисто с программной точки зрения они почти неразличимы. Программная разница, конечно, есть - но она весьма слабо выражена.

Поэтому все программы, основанные на DjVuLibre, не могут автоматически декодировать "серый" DjVu в 8-битный серый обычный графический файл - а вместо этого порождают 24-битный цветной файл. Так ведёт себя и ddjvu, и WinDjView, и DjView, и даже DjVu Viewer от Caminova!

Единственная программа, которая успешно справилась с задачей - это djvudecode от LizardTech - которая есть в составе DjVu Small. DjVu Small во всех случаях правильно выбрал глубину цвета создаваемого декодированного файла - когда нужно - 8 бит, и когда нужно - 24 бит.

Я попытался "обмануть" DjVu Small - например, взял серый TIF, поставил там в Фотошопе 1 красную точку, задежавючил. Декодировался такой DjVu правильно - в 24-битный тиф.

Вообще, по идее, чтобы определить в 8 или в 24 бита нужно декодировать данный DjVu, необходимо проанализировать 2 слоя DjVu: передний план (FG44 или FGbz), а также задний фон (IW44) - и проверить, нет ли в этих слоях хотя бы одного не-серого пикселя. Задача непростая, что и говорить. И очень ресурсоёмкая - чтобы определиться с выбором глубины цвета, придётся прошерстить дважды полностью слои DjVu. И это если не учитывать всякие иные экзотические DjVu-слои - типа JPEG и т.п.

Написал я письмо Леону Боту. Посмотрим, что он ответит. Оно вроде бы и мелочь - эта проблема - но всё же не такая уж и маленькая.

[monday2000]

Леон прислал ответ:
Я спросил, если ли какая-то программная разница между "серым" и "цветным" DjVu. Вот его ответ:

No, it is not. Therefore we would have to scan all the image to find that it is grayscale.
It is easier to convert the TIFF after its generation using imagemagick or something like that.
- L.

То есть, для того, чтобы определить, 8 или 24 бит использовать при декодировании, придётся делать полный рендеринг DjVu и смотреть каждый пиксель - все ли серые или есть хотя бы один цветной. Жаль. Очень топорное решение.

[Gordnub]

Сколько памяти требует компилятор? Работает под TR-DOS? Какие промежуточные файлы создаёт? Есть ли встроенный редакторинтегрированная среда? Обрабатывает-ли русские комментарии и/или русские строки? Или это вообще кросс-компилятор под Windos-у?