gribuser (gribuser) wrote,
gribuser
gribuser

Что такое epub и почему он не заменит fb2

Что такое fb2 и почему он устарел мы уже выяснили, пришла пора разобраться с результатами работы IDPF.

Коротко о главном
Если вы хотите составить себе адекватное представление о epub, представьте, что вы сохранили на диск какую-нибудь (например, эту) веб-страницу вместе с используемой на ней графикой и стилями. Для всех современных браузеров это стандартная функция, например в FireFox это делается через меню «Файл → Сохранить как → Веб-страница полностью». Можно сохранить рядом не одну, а несколько страниц. Затем вы кладете рядом с вашими страницами два служебных XML-файла. Один просто метка «это epub» (container.xml), второй содержит перечень всех файлов – .html, .css, .jpg, etc (обычно это файл content.opf).
Осталось поместить всё это в zip-архив и сменить ему расширение с .zip на .epub.
Всё.
Книга готова, а вы уже знаете, что такое epub. Это не шутка и не преувеличение – epub это просто архивированный в zip html. Ни больше, ни меньше.

Про формат подробно
Размещение содержимого в epub-архиве

Как мы уже выяснили, epub – это zip-архив с несколькими файлами. Когда вы архивируете файлы ZIP-архиватором и вкладываете в архив XML-файл container.xml, вы говорите прозой создаете файл в формате «Open Container». Несмотря на убийственно-пафосное название этого мероприятия (IDPF стоило знать, что есть ISO-стандарт OPC и не изобретать велосипед), за «Open Container Format» (OCF) вполне можно поставить IDPF «зачот» (почему – выясним ниже).
Помимо файл container.xml (должен лежать в META-INF) epub обязательно содержит еще один служебный файл, где перечислены все прочие файлы, размещенные в архиве, и указан их тип, как правило называется content.opf.
Вся конструкция для знающего человека сильно напоминает java-пакеты вообще и OpenDocument в частности. И в самом, деле IDPF ищет пути объединения с OpenDocument. Не очень понятно, что мешало стартовать с клоном OD, ведь OpenDocument на два года старше OCF, но, видимо, велосипеды – неизбежный удел дилетантов, вовремя доки почитать не удосужились. Вот и xpointer IDPF так же, по всем судя, твердо намерены реизобрести в рамках EPUB3. Версии к 5-й догадаются использовать стандартизованный w3c формат для ссылок и тоже будут искать пути объединения.

Какие данные хранятся в epub
epub обычно содержит следующую информацию:
  • Мета-данные: название, язык, авторы, etc.
  • Средства навигации: порядок листания для xhtml-файлов и «карта сайта содержание»
  • Собственно текст в виде нескольких xhtml-файлов, которые могут использовать стили css, картинки в jpg, gif и png а так же векторную графику svg и шрифты. Последняя версия epub декларирует поддержку MathML.
  • Помимо этого epub может включать ряд дополнительных узкоспециализированных файлов разметки, PDF-версию книги для печати и т. п. экзотику, реально не используемую, не поддерживаемую читалками и среднему читателю неинтересную.
Мета-информация в epub
Минимальная мета-информация epub включает название, ID документа и язык. Помимо этого можно указать авторов, переводчиков и других участников создания книги, дату публикации/написания, тему книги (в свободной форме), plain-text описание и данные об издательстве.
Ключевая мета-информация хранится в стандартной схеме Doublin Core, немного расширенной. Описание авторов, тематики и всех других полей (за исключением дат и языка) дается в свободной текстовой форме, что, фактически, исключает эффективную автоматическую каталогизацию epub из разных источников.

Средства навигации
epub, как мы помним, может включать множество html-файлов. И файлов будет множество. Не потому, что этого требует IDPF, а потому, что от больших файлов epub-читалки падают и все делают много маленьких. И вот для того, чтобы привычное читателю «пролистывание» работало, создатель epub указывает порядок, в котором файлы следует предъявлять. «При открытии показываем 3.html, когда читатель пролистает его до конца открываем 1.html, затем 8.html. А файл footnotes.html при прямом пролистывании недостижим, туда читатель будет попадать по сноскам», что-то в таком роде. Содержится обычно в файле content.opf.
Еще одно средство навигации внутри книги – содержание. Если присутствует, то, как правило хранится в toc.ncx. Технически это более аналог функции «карта сайта», чем привычного «содержания». Cодержание в бумажной книге (или электронном документе) повторяет структуру текста, а .ncx не связан с общим порядком следования текстовых фрагментов и может прямо им противоречить. Впрочем, в реальности файл как правило используется именно в качестве содержания и оформляется «штатно», повторяя порядок, заданный для листания.
Вообще, повторное хранение и переписывание на разные лады одних и тех же данных – фирменный знак epub. Мета-данные храняться в четырех местах: в описании OPF контейнера container.xml, в описании epub-пакета content.opf, в файле содержания toc.ncx и в html-файлах (в тегах meta). Содержание описывается трижды – «карта книги» из toc.ncx спорит с перечислением фрагментов в content.opf кто из них главнее, а заголовки h1-h6 в html смотрят на все это, и думают о реванше.

Текст книги
Разумеется, в epub присутствуют и собственно html-файлы с текстом книги. Так же в архиве хранятся используемые в тексте элементы – графика, стили, скрипты, шрифты.
Никаких существенных «надстроек» или «ограничений» в отношении html, css и т.п. epub не задает. Берем современный Web-контент, ставший уже даже не «динамическим», а «текучим» (epub декларирует поддержку html5, больше смахивающего на ОС, чем на язык разметки, его и браузеры-то пока поддерживают ограниченно), сохраняем на диск, архивируем – и вуаля, электронная книга готова.
«Дорогой, я сохранила интернет на диск, что дальше?»

История вопроса
Чтобы лучше понять основную силу и основную слабость epub, вернемся на 12 лет назад. В 2000-м году, когда ваш покорный слуга только-только приобщился к электронному чтению (если быть точным, был коварно подсажен на оное небезызвестным the-ebook), в сети уже существовали «Библиотека Мошкова», «Альдебаран», «Литпортал» и бог знает сколько еще мелких библиотек. Довольно много текстов было, в принципе, доступно. В основном именно в виде HTML.
HTML уже тогда давал широчайшие возможности для оформления. Благодаря этому люди, готовившие тексты, создавали иногда подлинные шедевры верстки. Достаточно вспомнить, что абзацы в библиотеке Мошкова были (и сейчас Мошков жжет в таком же роде, по-моему) оформлены миксом из тегов <dt> и <pre>. Однако, реально существовавшие читалки (iSilo, Microsoft Reader, Mobipocket, устройства типа REB и т.п.) понимали только ограниченный диалект HTML и еще более ограниченное подмножество CSS. Конечно же, каждая читалка строила «расширения» над форматом, но никто не верстал под конкретную читалку.
В финале, после соединения творческих прорывов создателей текстов, вдохновленных мощью HTML+CSS и ничем не ограниченных в полете своей фантазии, с реальными читалками, на экране пользователя получалась, как правило, ерунда. В лучшем случае книга была неказиста, но читаема. В худшем – текст вообще превращался в месиво.
Моим первым ответом на это стала программа ClearTXT, убирающая из текста «творчество». Однако, достаточно быстро стало ясно, что никакой эвристический анализ не угонится за фантазией создателей html-книг. В итоге все равно приходилось работать руками, больше или меньше.

Проблемы с диалектом были не единственными. Программы-читалки имели не только индивидуальные «выразительные средства» и «языковые предпочтения». Ни одна не читала HTML напрямую (в этом плане мало, что изменилось, кстати, предлагаю поразмышлять – почему). Каждая программа использовала свой, обычно закрытый, метод подготовки и упаковки данных. lit, rb, lrf, chm – каждый создатель читалки и разработчик устройства считал своим долгом «изобрести» новый закрытый «формат» и своё, личное, DRM-решение. Средства для конвертации в этот закрытый формат часто были либо недоступны, либо выпускались в виде приложений и/или библиотек под конкретную платформу, с ограниченной документацией или вовсе без нее.

Две проблемы в 2000-м, одна проблема в 2012
Итак, в 2000-м году взять произвольный html и скормить его читалке нам мешали две вещи:
  1. Необходимость использовать громоздкие сторонние средства для упаковки HTML в понятный читалке формат
  2. Несовместимость читалки с используемой разметкой и стилями

epub предлагает решения для обеих проблем:
  1. Средства упаковки стандартизированы и технологичны – можно даже вручную, минут за 20, собрать весьма сложную книгу используя OCF, notepad и zip-архиватор.
  2. Как мы уже видели, epub совместим со всеми и всяческими диалектами, стилями и методами разметки. Сохраняй из web, архивируй и читай.

Казалось бы, все хорошо.
И по поводу упаковки к epub претензий, помимо эстетических, нет. Используется, пусть нестандартное и не самое удачное, но адекватное задаче решение, к тому же простое, как палка.
А вот относительно отображения текста в читалках нас ждут плохие новости. Сам «формат» совместим со всем и всяческим HTML, это да. Куда как просто было написать в стандарте «см. спецификацию html». Соблазн был велик и IDPF не устоял. Но вот мы открываем наш «какой угодно» HTML в «какой угодно читалке» и...
И обнаруживаем, что мы ни на йоту не сдвинулись относительно 2000-го года. Как и в конце прошлого века, каждая конкретная читалка понимает только свой, ограниченный, диалект html+css. Как и в прошлом веке, диалект обычно недокументирован. По-прежнему в каждой читалке для решения даже таких стандартных проблем, как сноски, вводятся свои, ни с чем не совместимые, расширения (поищите epub footnotes в google, методики создания, помимо превращения сносок в ссылки, варьируют от совершенно кислотного CSS до javascript). Простейшие вещи сделать практически невозможно, сложные вещи либо не работают, либо роняют читалки.

Вот вам домашнее задание: не подглядывая в epub от ЛитРес, сделайте epub с пустой строкой между двумя абзацами (текст, пустая строка, снова текст, как перед этим абзацем), одинаково отображаемый в iBooks, ADE, Sony и Nook. Китайские чудо-читалки и прочую экзотику оставим в стороне, чтобы задача оставалась выполнимой. И даже выравнивания по ширине и переносов со сносками не попросим. Просто пустая строка, тег <empty-line/> в fb2. Время пошло.

Забавно в этом плане было недавно читать отзывы на пафосно стартовавшие на сайте аймобилки epub-книги студии Лебедева. С любовью сверстанные под iBooks на iPad, epub от Лебедева получали заслуженно восторженные отзывы обладателей этого устройства и весьма грубую ругань от обладателей других устройств, суть которой можно резюмировать как «ваша книга не читается». В итоге рецензии потерли, а рядом с чудо-epub выложены fb2. Не так пафосно, зато работает предсказуемо. Я так и не понял, почему не был использован отлично зарекомендовавший себя PDF, уж во всяком случае на Android-планшетах бы работало, да и на десктопе можно было бы почитать, ну да оставим Лебедеву лебедево.

Вердикт по делу epub
Явные плюсы формата – простота и технологичность zip-пакета, открытость.
Так же как плюс можно рассматривать единое DRM-решение. IDPF стыдливо делает вид, что DRM в epub типа открыт и типа любой может сделать свой. Все типа верят. И ясно понимают, что epub существует на 99% благодаря тому, что Adobe поддерживает для него DRM-инфраструктуру. DRM-зло, но один DRM на всех это меньшее зло, чем по DRM на магазин.
Да, глупо, когда архивированный HTML с взламываемым за одну минуту DRM выдается за невесть какую инновацию. Но zip и прочая стандартизация это какой ни на есть, а прогресс.
Касаемо плюсов это все.

А вот в области создания сложной разметки epub совсем никуда не годится и дальше будут только минусы. Формат не дает создателю книги ни гарантий относительно того, что увидит конечный читатель на экране, ни надежных средств контроля, которые позволят отсечь хотя бы заведомо «нерабочие» варианты, ни готовых решений для стандартных задач. Мой первый epub, только что прошедший валидацию, уронил две читалки из трех, на которых я его тестировал (слишком большой html – 2Мб, и слишком много ссылок, как я потом установил). Создатели документов вынуждены либо игнорировать «фичи» отдельных epub-читалок, либо предлагать несколько epub, чтобы читатель мог взять файл, совместимый именно с его устройством. Ради такого финала и огород городить не стоило – что толку верстать html5 зная, что читать его будут в IE3?

Чего нам ждать от epub в будущем
Наиболее благоприятный для epub сценарий – вытеснение из ниши программ-читалок мелких разработчиков несколькими крупным игроками. Сделать полнофункциональный html5-парсер с постраничной разбивкой как минимум не проще, чем сделать современный браузер, а отдача несопоставимо меньше, и случайных людей тут не будет. Однако ни google, ни Мicrosoft, ни Opera пока что не бегут делать новые движки epub-читалок чтобы Adobe мог как следует поднять бабла на своем чудо-DRM. И сама Adobe вполне ясно свой потенциал по развитию ридеров показала – ADE до сих пор не имеет ни поддержки сносок, ни нормально типографики, ни переносов.
Так что гораздо вероятнее, что лет за пять вокруг epub сформируется некий «неписанный IDPF» неформальный свод правил верстки, рабочих решений по оформлению, опробованных на ведущих читалках «хаков» и «фокусов». Сетевое сообщество уже формирует «истинный» epub-стандарт поверх всепрощающего «html5+css3+все_чего_хочется_еще». Описываются реальные решения для реальных проблем в реальных ридерах. Потом эти «фокусы», будучи стандартом де-факто, станут обязательными и для разработчиков новых читалок. Те, кто в IT достаточно давно, чтобы успеть наглотаться дыма браузерных войн и поработать с IE4, NN4 и Opera 3, отлично представляют себе, что именно нас ждет – по этим граблям сетевое сообщество уже ходило и икается эта прогулка до сих пор. Поэтому когда я вижу «этот epub оптимизирован под iBooks» я испытываю не просто де-жа-вю, а острый рвотный рефлекс.

И вот за то, что нас пытаются выпихнуть «назад в 90-е» я ставлю epub незачет. Нам не нужны хаки, становящиеся неработоспособными в новой версии софта. Нам не нужны неписанные правила, по крупицам отлавливаемые методом тыка. Не нужны узаконенные баги. Не нужна «валидация тестированием» по всем читалкам – «покажет или не покажет». Всё это мы проходили.
Нам нужна надежная и удобная технология, четкий стандарт и рабочие средства контроля качества. И epub этого нам дать не смог, к сожалению.

Чего от epub ждать бесполезно
Среди недостатков epub есть и еще один, который мы пока не затрагивали – принципиальная несовместимость с другими форматами. epub рожден быть монополистом. Извлечение данных из epub и конвертация в другой формат даже для нехитрого html является непростой задачей. Когда же epub заматереет, обрастет хаками под устройства и замысловатыми решениями, типа подстраничных сносок на CSS, извлечь из него что-либо будет задачей практически неразрешимой. Какой бы формат Adobe не разрабатывала, получается PDF – вход рубль, а выход пять.
А ведь нам все еще нужна поддержка разных (в т.ч. старых) читалок и устройств. Нужна полноценная поддержка альтернативных форматов, которые уже приобрели вес (mobipocket на Kindle) и будут еще появляться на рынке.

В добавок нам нужны средства каталогизации, обмена цитатами и заметками и прочая и прочая, чего epub даже на декларативном уровне пока что не обещает. Иными словами, нам нужен fb3, которому и будет посвящена следующая статья.
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 56 comments