Форматы хранения книг, общая модель
Гросс данке
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 можно несколько улучшить, поигравшись с «Сервис - Редактор языков - Формальные языки», и добавив греческий язык. Сразу начинают лучше распознаваться всякие
и
. А для распознавания сложных формул обратите внимание на 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 пару книжек, получилось компактнее. Выбор материала, настроек - всё влияет.
Mirrored from тайный блог aKry.
Поделиться, оценить:
