FictionBook 3.0 - информация к размышлению

Материал из FictionBook
Перейти к: навигация, поиск

Введение

Рассматривая предложения по бета-версии формата FictionBook все время возвращаюсь к одной и той же мысли. Можно конечно сейчас начать копаться в отдельных тегах, пытаться что-то улучшить, от чего-то защититься, но это выльется в диалог с Дмитрием Грибовым. А почему?

Более пяти лет пропаганды формата FictionBook позволяет сделать два глобальных вывода. Первый приятный - формат все-таки стал де факто основным форматом электронных библиотек в русскоязычном сегменте сети Интернет. Второй менее приятен - для очень многих пользователей даже этого сайта формат так и остался чем-то туманным. Даже те из них, которые пишут ридеры, редакторы, библиотеки допускают ошибки в понимании применения тех или иных тегов. Разумеется не все, но все же, увы, их большинство.

Даже беглый взгляд на схему fb3 вызывает сомнение, что для основные масс пользователей он станет более понятен. Эту мысль подтверждает и вялость обсуждения предложений по новой версии формата FictionBook. Я хочу вынести на обсуждения предложения, направленные на улучшение стройности формата. Сразу предупреждаю, что это даже не конкретные готовые предложения, а принципы построения третьей версии, которые в случае одобрения, надо еще довести до реализации. Честно, хотел выстроить всю систему до уровня развернутого готового предложения, но понял, что одному делать трудно и долго, можно просто опоздать, и подготовить предложения к тому моменту, когда они уже не будут нужны, как с шестиосной классификацией жанров.

Хочу сразу сказать, что я сейчас не рассматриваю драфт FB3 с критической точки зрения. Многие предложения драфта понятны и логичны, очень мало тех, которые вызывают вопросы и сомнения. Но сейчас не об этом. Сейчас хочется остановиться, оглянуться и подумать - а туда ли мы развиваемся? Или - как долго можно вводить новые типы, теги и атрибуты без опасения, что не кто-то из новичков, а уже сам не будешь понимать, что и для чего введено? 8) Итак, обо всем по порядку.

Разделяй и властвуй

Здесь я не хочу сказать ничего нового, а только напомнить старые истины. Вспомните, как описываются сложные системы взаимодействия OSI, или более практичный TCP/IP. Очень просто - рассматривают отдельные уровни взаимодействия - физический, транспортный, межсетевой, прикладной и другие независимо друг от друга. То есть не мешают все в общую кашу и становится все намного яснее. Здесь есть еще одна выгода - можно дорабатывать какой-либо уровень (вводить новый протокол, использовать новую физическую структуру передачи сигнала) и при этом совершенно не трогать остальные уровне, потому что им в принципе все равно, по какой физической среде будет передаваться сигнал или какой транспортный протокол будет использоваться.

Как бы можно было бы применить этот принцип в FB3:

Первый уровень - файловый

Здесь описываются все файлы, которые входят в fb3, их назначение и взаимодействие. Я не буду подробно разжевывать этот уровень и перейду сразу ко второму уровню.

Далее я буду рассматривать файл fb3-body, во-первых, как самый интересный, а во-вторых, я уже говорил, что предложенные принципы я еще не додумал до конца. 8)

Второй уровень - структурный

В структурном уровне решается вопрос описания структуры книги. Это никак не влияет на файлы и их взаимодействия и никак не отражает содержимое книги.

Если провести аналогию с бумажной книгой, то это приблизительно похоже на оглавление. Но приблизительно, потому что электронная книга более строго относится к структуре. Если ввести понятие уровня заголовка, то мы часто видим как бумажная книга начинается заголовками второго уровня, например, От автора и Предисловие, а потом идет заголовок первого уровня - Глава 1. Это частый случай. На практике вакханалия с уровнями заголовков бывает и круче, поэтому у меня всегда вызывали удивление предложение делать электронную книгу похожую на бумажную. Электронная книга структурно всегда будет лучше оформлена, чем бумажная. Но это тема другого разговора, а здесь я ее коснулся, чтобы обратить внимание на беззаголовочную структуру первого уровня, куда входят два заголовка второго уровня - От автора и Предисловие. Это очень важный момент, вызывающий ошибки и путаницу. Скажу больше - не весь софт нормально обрабатывает беззаголовочную структуру - хотя это основа формата FictionBook.

Так вот структура - это разбиение всего текста книги на секции, неважно с заголовком или без. Вся книга разбивается на секции первого уровня, далее следует разбиение последних на секции второго уровня и так далее. Я бы выделил два типа секций - секция структурная и секция конечная. Секция структурная может содержать только секции и больше ничего. Секция конечная не может содержать секций. Вот их основное отличие.

Структурные секции умирают на этом уровне не оставляя потомства, а конечные секции раскрываются во всей красе на следующем уровне - у них разная судьба.

С точки зрения программной обработки существующая схема и описание элемента section не вызывает никаких нареканий. С точки зрения практики, если описать эти два типа секций, как разные элементы и ошибок было бы меньше и понималось бы лучше и програмировалось бы проще. А кто не распутывал структуру fb2 после конвертации, когда пропадали начальные или конечные теги элемента section? Кошмар, не правда ли? А если ввести атрибут уровня секции (level=2), то и распутать было бы проще, а главное, запутать конвертер было бы сложнее! 8) Вот так небольшое расширение формата уменьшило бы некоторую головную боль.

Третий уровень - блоковый

Блоки - это замечательно.

Вспомните сколько ошибок вызывают неуместное применение элементов даже у опытных редакторов. Что тут говорить про новичков? В схеме fb2 каждый элемент в последовательности имеет свое место, перестановка элементов вызывает ошибку. Чтобы определить правильное место для элемента, надо сверяться со схемой, к которой далеко не все относятся благодушно. Поэтому любое словесное описание схемы, даже содержащие некоторые неточности, публикой принимается на ура. Лично мне не понятна нелюбовь к схеме и нежелание с нею сверяться, но это факт, который невозможно не принять.

Блоки решают все эти проблемы. Теперь не надо работать на уровне элементов, можно вообще о них забыть. Вся конечная секция состоит из основного текста и блоков. Основной текст - это набор абзацев, которые передают текст документа и не имеют никакого предформатирования, то есть каждый абзац заполняет все пространство от левого края текстового окна до правого в соответствии с настройками программы ридера. Блоки - это контейнеры элементов характеризующихся точкой привязки к основному тексту, положением относительно окна основного текста (слева, справа, по центру, 50% ширины экрана и т.д.), признаком обтекания, типом (текстовая врезка, рисунок, таблица, формула, заголовок и т. д.) и, конечно, содержанием, то есть набором всех возможных элементов для данного типа блока.

При этом редактор представляется набором форм, похожих на форму заполнения description, только для каждого блока своя. Вызывая форму мы обязательно заполняем все обязательные поля и при необходимости необязательные поля. На самом деле, каждое поле - это элемент или атрибут, которые редактор расставит согласно схеме, но нам с вами об этом знать не обязательно! И мы не можем совершить здесь ошибку. Разумеется для принципиальных любителей схемы всегда остается возможность редактировать в notepad согласно схемы :).

Давайте для примера рассмотрим блок заголовка, где-то так <block type=title ...>...</block>. Почему заголовок - это блок? Потому что, во-первых, он преформатирован, то есть располагается иначе чем основной текст, во-вторых, имеет несколько элементов, а значит их надо загнать в контейнер. Впрочем, первое условие уже определяющее.

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

Точкой привязки блока всегда будет то место основного текста, куда вставлен блок. Первый элемент - title - основной текст заголовка, он может быть размещен по центру, справа, слева. Встречал все три случая, однако обычно размещается по центру. Следующий элемент - рисунок. Это может быть русунком к главе, видел и случаи заголовков с художественно выполнен текстом, например, рисунок с цифрой главы - это тоже рисунок. Третий элемент - расширенный заголовок (extended title). Это, например, - "в которой говорится о ...". Четвертый элемент - эпиграф, который в свою очередь может иметь текст, автора, источник, время и место написания/изречения. Этих элементов может быть несколько.

Кстати, автор, источник, время и место написания нам будет встречаться часто, как в составе других блоков (например, цитата), так и как самостоятельный блок (часто художественная книга заканчивается чем-то вроде Москва 1988-1990 г. Поэтому логично выделить его в отдельный блок. То есть блок может содержать другие блоки. Естественно, не любые, а только те, которые уместны в данном блоке и, главное, оговорены в схеме.

Выглядеть это будет приблизительно так:

<block type=subscription>
<source>...</source>
<where>...</where>
<when> ...</when>
<author>...</author>
</block>

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

Что такое <source>? Это и "Письмо Ивана Иваныча к Ивану Никифоровичу", и "Капитал", и "Разговор в поезде". То есть все, что отвечает на вопрос "откуда?". Где было написано или изречен текст эпиграфа выясним в элементе <where>. А вот <when> а не <date> по той причине, что это не только "8 января 1951 года", но и "начало III века до нашей эры" или "вчера после полудни", что уже никак не date. Я уж молчу, что автор это и "А.С. Пушкин" и "Собеседник в поезде". То есть не будем ставить преграды там, где в них нет острой необходимости. Я не вводил атрибута align для блока subscription, потому что этот блок как в основном тексте, так и в вышестоящем контейнере всегда right. А вот блок title может быть и right, и center, и left, и даже на 30% окна и быть обтекаемым - например, в учебниках это встречается не редко.

Сразу давайте оговоримся, что одно дело создание fb-документа, где мы обязаны максимально соответствовать авторскому варианту, и другое дело отображение, где ридер должен считаться с техническими характеристиками устройства отображения. Поэтому на экране мобильника никто не ожидает увидеть обтекаемые заголовки на 30% ширины экрана слева, а вот на 19" мониторе это вполне ожидаемо, также и на eInk электронных книжках.

Подытожим наши размышления:

<block type=title align=center>
<title>Глава 1</title>
<img>glava1.jpg</img>
<extended_title>Размышления о FB3</extended_title>
<epigraph>Блоки - это замечательно</epigraph>
  <block type=subscription>
  <author>Прохожий</author>
  </block>
</block>

Так будет оформлен документ, а в редакторе, как и говорил раньше, мы просто заполним две формы, форму блока tite и форму блока subscription или проверим, как их заполнит импортированный материал.

Концепция блоков позволяет нам отвлечься от общей схеме документа fb3, а сосредоточиться на блоках, таких внятных и понятных, с которыми мы встречаемся постоянно. Обдумать, что нам в них надо иметь, а что лишнее. Это значительно упрощает задачу и делает подготовку новой редакции формата коллективной и плодотворной. А собрать блоки в общую схему - это вопрос технический.

Оставим пока блоки, хотя здесь еще о многом можно говорить, и перейдем к следующему уровню.

Четвертый уровень - инлайновый

FictionBook - это формат структуры.

Это неоспариваемая истина. Но, с другой стороны, надо признать, что выделенное слово - это не способ отображения, это авторский акцент. Курсив - это текст выпадающий из основного текста (содержание письма, инлайновая цитата или что-либо подобное)и тоже авторское выделение. Я уже молчу о верхних и нижних индексах, подчеркивании и зачеркивании текста. Лесенка в стихотворной строке - это тоже важный элемент от которого зависит способ прочтения (дополнительный акцент) - это авторская структура.

Все что я перечислил это инлайновые элементы, то есть элементы акцентирования части, слова, буквы внутри абзаца или абзаца целиком. Они не зависят от того, в каком абзаце они встречаются и в каком блоке находится этот абзац. Мне могут возразить, что есть элементы, которые выделяются структурно и их нельзя выделять инлайновыми элементами, например, title. А так ли это? Никто не встречал выделения текста в заголовке? Я пока не встречал... Но если их нет, то и не будут использовать, а если они импортируются из dос, то почему бы при импорте не нормализовать заголовки самой программе редактора и не забивать голову этой проблемой людям :).

Поэтому задачей разработки FB3 на этом уровне является перечисление этих элементов, то есть решить какие элементы необходимы для того, чтобы полностью отразить авторский замысел.

Заключение

Сразу скажу, что я читал предложения по fb3, анализировал схему, и мне показалось, что мы размножаем недостатки fb2. Потом я надолго отложил новые предложения и стал анализировать проблемы, которые возникают при подготовке документов в формате fb2, их причины и искать пути их решения.

Размышления привели к выводам, что надо обсуждать не схему, а состав каждого блока на третьем уровне и перечень инлайн документов на четвертом уровне. Здесь очень важен опыт многих верстальщиков, чтобы не упустить ни одного момента. А собрать все в единую схему - это задача техническая, и с нею справится автор формата самостоятельно.

Я давно сознательно не заглядывал в предложения по fb3, чтобы подсознательно не ограничиться рамками существующих предложений.

Если автор формата, в первую очередь, и коллеги примут и поддержат принципиальные предложения, изложенные выше, то я готов технически организовать обсуждение перечня и состава блоков и инлайн-элементов, результаты которых будут учтены автором в окончательной схеме формата FB3.

Алексей Седых