monday2000 Цитата: Прописываете в INFO-чанк нужные размеры?
Ну, это слишком грубо и, наверное, приведет к ошибке (если изменять только его). Я же говорил, что изменения вносятся непосредственно в раскодированный sjbz-чанк.
При этом никаких побочных эффектов не возникнет. Чанк, как и структура страницы, остаются абсолютно правильными с точки зрения стандарта.
Если посмотреть на структуру sjbz-чанка, то он начинается с размеров канвы, на которую наносятся блиты. Теоретически, эта канва может быть любой, это всего лишь белая так сказать подложка. Вот ее размеры я слегка и изменяю (на 1-11 пикселей), чтобы достичь нужной кратности. Естесственно, такие же размеры нужно подставить и в INFO-чанк. При этом нужно помнить, что начало координат у блитов (как и у djvu-страницы) находится в левом нижнем углу, а не в верхнем. Поэтому зоны, помещаемые затем с помощью вашего метода МПФ, нужно соответствующим образом сдвигать вниз на столько же пикселей.
Цитата: А как это "От использования djvulibre для этого отказался"?
Я имел ввиду от специального синтаксиса djvumake, введенного в последней версии djvulibre, когда раскраска задается последовательностью прямоугольников. Отказался по той причине, что блит в djvu как оказалось, не является связным черным компонентом, а может состоять из нескольких раздельных (на большое расстояние!)кусков. Может так оказаться (у меня такое встретилось), что эти куски одного блита могут принадлежать разным раскрашенным зонам. И здесь плохо не то, что такие зоны невозможно раскрасить как нужно, а то, что заранее нельзя определить этот факт, и в итоге юзер получит непредсказуемый результат (раскраску). Если вам интересно, могу привести пример такой ситуации.
Кстати, пока я это не понял, я разработал алгоритм автоматического формирования пересекающихся раскрашивающих прямоугольников. Ранее я ошибочно писал, что это невозможно. Но оказалось, что эту задачу можно изящно решить методом графов. Интересно, что если области невозможно было закрасить с помощью ряда прямоугольников, то это соответствовало тому, что в графе появлялись циклы. Но, вообщем, алгоритм я полностью реализовал, пока не понял, что он бесполезен, т.к. он полагался на связные "блиты" исходного тифа, а не на то, какими они становились после кодирования в DEE. Но это и к лучшему: теперь СК использует исключительно блиты после DEE, что гарантирует 100% правильность раскраски (или ее невозможность с помощью FGbz).
Кстати, как побочный эффект всего этого, я ввел в СК команду, которая открывает нужный djvu-файл, интерактивно позволяет расставить на страницах зоны раскраски, и по команде ввести эту раскраску в исходный djvu.
Цитата: Откуда такие сведения? Можно простой JPEG помещать в DjVu - это да
Я это и имел ввиду. Т.е. jpg как бы становится чанком заднего фона.
.