-Поиск по дневнику

Поиск сообщений в akry

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 21.08.2007
Записей:
Комментариев:
Написано: 40049

Форматы хранения книг, общая модель

Суббота, 12 Февраля 2011 г. 21:42 + в цитатник

Гросс данке Alfizik за обилие информации про формат DjVu, и за развеивание некоторых моих стереотипов. Ниже — моя попытка систематизировать информацию и создать модель, в которой видны области применимости разных форматов. Текст — слегка переработанный комментарий к этому посту.

В статье я буду упоминать «плавающую» и «фиксированную» вёрстку. Под «плавающей» я имею в виду такой формат, при котором во главе угла стоит поток текста, а остальные графические элементы привязаны к тем или иным местам в этом тексте, и при изменении размера окна, шрифта, они автоматически занимают нужную относительную позицию. Пример: практически любая веб-странца, большинство документов MS-Word, хорошо сделанные электронные книги. Фиксированная вёрстка подразумевает сохранение визуального взаиморасположения всех элементов. Пример: все журналы, газеты. У каждого из типов вёрстки есть свои области применения, свои преимущества и недостатки.

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

Поэтому наверное можно выстроить такую последовательность, в виде «цель, наиболее подходящие форматы, за-против»:

1. Книга в бумажном виде. У неё есть свои плюсы и минусы, свои цели, подробно перечислять здесь не буду.


2. Архивное хранение, когда нужно по максимуму избежать потерь. Форматы: сканы в TIFF и прочих «точных» форматах. JPEG, и уж тем более вейвлеты тут использовать очевидно не стоит. Цели архивного хранения могут быть разными, и они будут определять в первую очередь качество и разрешение сканирования. Плюсы: максимум визуальной информации. Минусы: объём, неудобно читать с мобильных устройств, да и с большого экрана листать страницы тяжело. Множество файлов не так удобно хранить на диске, как один файл со многими страницами. Также забудем про текстовый copy-paste.


3. Быстренько переслать другу статью/рисунок/рукопись/книжку, сохранить себе. Форматы: обычные JPG, когда не надо заморачиваться, а просто сосканировать. Плюсы и минусы похожи на то, что было в предыдущем случае. Только объём поменьше.


4. Быстренько сохранить/переслать статью/рисунок/рукопись/книжку чуть более продвинуто и удобно для хранения/чтения/каталогизации — завернуть в один файл. Форматы: в первую очередь это DjVu без текстового слоя, может быть с метаданными. Можно использовать и PDF, но хранить голые картинки в нём имхо извращение. Как я успел заметить, в основном именно такие сравнения между этими двумя форматами и показывают ошеломляющее преимущество DjVu, что неудивительно. :) Плюсы: всё в одном файле, размер (особенно в случае с DjVu) часто значимо меньше, чем у отдельных графических файлов. Одному файлу во всяких системах каталогизации можно удобно назначать метаданные: ключевые слова, аннотацию, обложку, ISBN и т. п. Минусы: в общем то те же, что и были для графики.


На этом заканчиваются чисто графические способы хранения и начинаются танцы. Если с графикой в плане вывода всё было понятно (альфа и омега: разрешение + потери, ни о каком изменении документа для удобств вывода, кроме масштабирования, речи нет), то дальше появляются варианты.

Промежуточные варианты

5. Быстренько распознать статью/книжку и переслать текстовый файл. Форматы: чисто текстовые, или допускающие голый текст. Например, doc, txt, pdf. Плюсы — легко ознакомиться, минусы — из рассмотрения выпадают формулы, рукописи, графики.  Однако в целом ряде случаев этот способ вполне применим и более чем достаточен.


6. Быстренько сохранить/переслать статью/рисунок/рукопись/книжку «с удобствами», объединив со сканами (опять же быстренько) текст без особой вычитки методом «как получится». Текст можно добавить в виде отдельного «сопроводительного» файла. А можно вклеить его в текстовый слой в DjVu или в PDF, поверх скана страницы. Очевидно, что главное приложение, я бы сказал, бытовое.

Форматы: в первую очередь DjVu и PDF. Для последнего FineReader 10 даёт специальную опцию: текст поверх картинки. Текстово-графический DjVu (как мне говорили) сделать тоже очень просто.

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

Минусы: возможности по адаптации к устройствам вывода по-прежнему ограничены масштабированием, что не всегда айс. Особенно если мы говорим о ебуках и мобильных устройствах. Также у нас появляется некоторая избыточность: большое количество текста присутствует и в графике, и в собственно текстовом виде. Причём графика реально часто нужна только в ограниченном количестве мест. На это можно возразить, что мол потери по объёму невелики, но не такой ли аргумент оспаривали ценители DjVu? Мне кажется, нужно быть последовательным: если уж мы ратуем за сокращение объёма (спорный тезис, но популярный среди апологетов DjVu), следует признать, что оно в DjVu происходит вовсе не всегда оптимальным образом. Причём не по причине нерадивости кодирующих, а в силу принципиальных особенностей формата. Для любого схожего набора алгоритмов, текст + графика будет занимать больше объёма, чем просто текст.
Таким образом, в качестве основных преимуществ здесь я бы выделил не «рекордно малый объём», а скорость создания того, что можно прочитать с большого экрана и проиндексировать. А при необходимости, и обработать на следующем уровне.
Кстати, на этом же этапе можно добавить и интерактивность, и гиперссылки.

Примечание. FineReader 10 может распознать сразу DjVu, без промежуточных танцев.


7. Уже не так быстро: вручную (или автоматически, или полуавтоматически) разделить текст и графику. Текст рассматривать только как текст (без графического «бонуса»), всё остальное — как растр (без скверно распознанного текстового мусора). На самом деле трудозатраты во многих случаях не катастрофические, хотя в качестве полемического аргумента всегда можно найти книжку, где графика и формулы доминируют. :)
Преимущества очевидны: у нас впервые за всю историю процесса появляется возможность для reflow — мы можем в определённых пределах менять взаиморасположение элементов. Я уже не раз писал, для чего это не просто нужно, а критично: в первую голову для компактных устройств отображения. При этом мы сохраняем все формулы и картинки в первозданном виде (предел качества определяется разрешением сканирования). Я специально подчёркиваю этот момент, потому что похоже существует заблуждение, что только полностраничная копия спасёт сложные формулы. Это не так: достаточно перевести в растр только формулы. Более того, мы можем выбирать, сохранять формулы/картинки с потерями, или без — для архивирования.

Форматы. На этом этапе мы уже уходим из домена DjVu — как я понимаю, формат не поддерживает «гнездовую вёрстку» со сложным взаиморасположением графических, векторных и текстовых элементов. И не поддерживает сохранение отдельных графических элементов без потерь. Не будем сейчас обсуждать их значимость для архивирования.

Хочу заметить, что на этом этапе у нас есть в распоряжении не только PDF, но и банальный и простой в использовании HTML, и CHM. С интерактивностью, гиперссылками и прочими радостями.

Плюсы: reflow и огромный мир мобильных устройств, сохранение всех преимуществ с предыдущих этапов (есть формулы, возможно индексирование, всё в одном файле). Возможность скопировать не только текст, но и отдельные картинки (иногда полезно).

Минусы: больше трудозатрат, это раз. Рельно распространён только один формат — PDF, который отнюдь не самый удачный с точки зрения оптимизации и простоты создания, это два. Разумеется всегда можно сверстать в Кварке или в Индизайне, но аудитория таких форматов сразу же ассимптотически уменьшается до дизайн-контор, и про ебуки тоже можно забыть. Пара слов про «простоту создания»: на самом деле нам, как конечным пользователям, по барабану, насколько трудно пришлось программистам, лишь бы конечный результат нас удовлетворял. Можно подумать, кодирование в MPEG доступно в Notepad любому. Нет, там тоже сложные алгоритмы, но для нас важно наличие удобного софта, а не детали реализации. Для PDF такой софт присутствует в изобилии. И в формат можно печатать, как на виртуальный принтер, что безусловно плюс.


Окончательные варианты

8. Перевод всего, что можно, в вектора. Иногда возражения против перевода PDF неявно основываются на предпосылке, что альтернатива картинкам — только полная векторизация. Но полностью векторизация невозможна даже теоретически, потому что существуют принципиально растровые элементы вроде фотографий.

Цель такого действа: максимальная гибкость в воспроизведении документа где угодно, от экрана, до типографии, с возможностью изменения содержания и взаиморасположения максимально возможного числа элементов. Это уточнение очень важно: без него мы можем просто взять TIFF в хорошем разрешении и не мучиться.

Векторно-растровых форматов много, среди них очевидно не только и не столько PDF, сколько EPS и форматы верстальных программ вроде InDesign.

Очевидные сферы применения: издательство (включая создание ебуков), переводы книг, переиздания.

Минусы: Сложность создания. Разумеется мы говорим о reverse engeneering исходного скана — с OCR и трассировкой векторов, — а не о варианте, когда у нас и так есть все исходники.

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

Добавление. Качество распознавания формул и всяких символов в FineReader можно несколько улучшить, поигравшись с «Сервис - Редактор языков - Формальные языки», и добавив греческий язык. Сразу начинают лучше распознаваться всякие ф1 и ф2. А для распознавания сложных формул обратите внимание на InftyReader (русского языка нет).


Итого

1. Трудозатраты на 8-й этап («полная векторизация») очень велики и неадекватны большинству задач, поэтому я ратую за то, чтобы он остался только для специальных случаев.

2. Для паранойяльного архивирования нужны TIFF или аналоги. Забыли про DjVu, Jpeg и вектора.

3. Для промежуточного архивирования, когда потери не важны, годятся DjVu, Jpeg, Pdf. DjVu имхо удобнее.

4. Весь спор реально крутится вокруг того, что удобнее для обычного пользвователя — 6-й или 7-й этапы. И в рамках каких форматов удобнее реализовать каждый из них. Мне кажется, я достаточно подробно обозначил их сферы применения.

Также, надеюсь, очевидны некоторые распространённые заблуждения касательно DjVu.

  • Для сохранения «графика+текст» есть только DjVu. Нет, это же можно сделать в HTML, CHM, PDF, а также в изрядном количестве специфических форматов программ вёрстки. Вопрос выбора формата определяется целью. Для публикаций в Вебе имхо лучше брать HTML и PDF. Для плавающей вёрстки DjVu принципиально непригоден, а вот с PDF я слышал, есть возможность reflow (см.).
  • Разделение текста и графики обязательно ведёт к потерям графики. Нет, это та же самая картинка, что в DjVu. Как сосканировали, так и будет.
  • DjVu идеален для архивов. Опять же, it depends.
  • DjVu всегда меньше по размерам, чем PDF. Не обязательно. Я легко могу подобрать примеры, где это утверждение будет ложным, для любого разумного разрешения сканирования. К сожалению, много книг в DjVu, которые мне попадались, попадают как раз в эту категорию.
  • Внутренняя сложность формата PDF важна для конечного пользователя. Нет, гораздо важнее наличие удобных программ для работы. Никого не заботит, как сложно устроен mp3, им просто пользуются.
  • DjVu принципиально лучший формат для электронного отображения книг. Не всегда, зависит от. Как только у нас появляется необходимость в изменении расположения элементов (все мобильные приложения, бывает нужным и на PC) — опа. Стоит рассмотреть другие форматы.
  • DjVu всегда легче по трудозатратам, чем другие форматы (единственным противником обычно выбирается PDF, хотя это не вполне корректно). Для FineReader нет никакой принципиальной разницы, куда пойдёт его вывод — в DjVu, в PDF, в DOC или даже обратно в TIFF. В изрядном количестве случаев FR адекватно распознаёт, где тексты, а где графика — остальное легко расставить вручную. Разумеется, как мы уже обсуждали, есть ряд книг, забитых формулами, где это утверждение неверно. Но много книг, сделанных в DjVu, в эту категорию не попадает.

Я специально не рассматриваю вопросы проприоретарности, лицензирования и доступности SDK. В этому плане основные рассмотренные форматы стоят друг дружки.

btw Примеры, находящиеся на сайте djvu.org, вроде «djvu_example.pdf» — штука коварная. У djvu конечно очень хорошие алгоритмы сжатия. Но есть несколько «но». Первое: это алгоритмы сжатия с потерями. Поэтому (см. цели) если нужно архивное хранение, то всё-таки tiff. Второе: понятно, что djvu.org старается выбрать примеры, на которых она выглядит выигрышно. Я подозреваю, что Adobe может найти книги, на которых гораздо лучше и компактнее смотрится pdf. Да и сам я в недавно перевёл в DjVu в pdf пару книжек, получилось компактнее. Выбор материала, настроек — всё влияет.

Поделиться, оценить: Like it!Поделиться ВКонтакте!Процитировать в LiveJournal!Процитировать в Twitter!Добавить блог РІ GoogleReader!
Рубрики:  Идеи и мысли
Метки:  
Понравилось: 1 пользователю



 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку