bolega
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Возню с созданием djvu из-под СК закончил. Больше всего хлопот доставили раскрашенные зоны. В итоге сделал так, что СК сам формирует raw-чанк FGbz. От использования djvulibre для этого отказался, т.к. в некоторых случаях он оказался бессилен, и главное, его результат был заранее непредсказуем. При обработке раскрашенных зон СК извлекает и декодирует sjbz чанк (полученный кодированием текста в DEE) и проверяет на возможность его (точнее, составляющих его блитов) правильной раскраски чанком FGbz. Зоны при этом могут быть любыми, включая непрямоугольные и перкрывающие друг друга (напр., когда одна раскрашенная зона лежит целиком внутри другой). Если в результате анализа СК выясняет, что раскраска с помощью FGbz невозможна (напр., блиты с разными цветами соприкасаются или вообще включены в разные зоны - такое как оказалось бывает!), она выполняется тогда с помощью чанка FG44. Все это естественно делается быстро и на полном автомате.
Решил также очень большую проблему, возникающую при кодировании зон методом подклейки фона, а именно, когда размеры страницы (tif-файла) не кратны соотношению dpi зоны и страницы (это соотношение обычно составляет 1..12) . Это довольно таки частая ситуация. В программе monday2000 в этом случае выдается сообщение о невозможности кодирования. Я нашел, как легко обойти эту проблему (без изменения размера файлов и без перекодирования переднего слоя): СК просто делает небольшую шаманскую модификацию sjbz-чанка. При этом перекодировать маску-передний план (в DEE) не требуется, также как и не требуется физическое изменение размеров тиф-файла. В идеале, конечно, размеры исходных тифов изначально должны быть кратны упомянутому соотношению, но это не всегда можно выполнить, тем более это соотношение не всегда заранее известно.
Кстати, в процессе отладки мне пришлось написать свой native-просмотрщик блитов словаря djvu.
Добавлено:
kalyambus
Цитата:| при 300 dpi имеет разрешение разворота примерно 6000х5000 |
Проблема в том, что это неправильное dpi. На самом деле это не 300, а 600 dpi. Поэтому и СК так долго у Вас работает и обрабатывает: ведь он удваивает разрешение (якобы 300) до реальных 1200! Чтобы решить проблему, после импорта на закладке Files задайте в поле Input dpi=300 и снимите там галку с "only for uknown dpi". В этом случае СК будет брать dpi отсюда, а не из файлов.
Добавлено:
Тут недавно обратили мое внимание на то, что в окне result view в режиме правки мышкой границ полезной области это происходит слишком медленно. Я исправил это. |
Всего записей: 4669 | Зарегистр. 09-09-2002 | Отправлено: 13:31 22-01-2011 | Исправлено: bolega, 14:25 22-01-2011 |
|
.