Как конвертер решает, что именно делать первым и главным <body> документа?
Как отметить ему, что главное тело документа начинается тут, и заканчивается тут.
А вот от еее до бубу - второе <body>?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AFAIR никак. Данной фичи не предусмотрено (де-факто и в рамках формата).
Принцип структурирования простой:
Основной текст (весь) пишется в первый (он же основной) тэг body.
Сноски (сиречь примечания), если таковые имеются, пишутся во второй тэг body.
Концевые сноски (они же — комментарии) также выделяются в отдельный тэг body (второй если в документе присутствует только данный вид сносок или третий, если в документе есть и «обычные» сноски.
В настройках OOoFBTools ЕМНИП есть (была, мне оно требуется не то, чтобы часто) возможность выбора: использовать оба варианта сносок as is, или зафорсить тот или иной тип.
Итого в файле практически [нормально] бывает от одного до трёх тэгов body.
Использование иных структур, пусть и потенциально не запрещённых стандартом, обычно предоставляет возможности исследования особенностей реализации на прикладном уровне (программ для чтения книг).
Лично меня здесь напрягает заявляемое (лично мной практически не используемое, наблюдавшееся только в дистрибутивном примере) выдёргивание из текста, помещаемого в основной тэг body блока аннотации.
По мне оно (текст аннотации) логичнее бы смотрелось рядом с прочими параметрами заголовка. Всё равно отображение (стиль и соответственно применимые элементы форматирования) аннотации не совпадает с основным текстом (говорю на примере CoolReader3).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Первоначально я старался писАть конвертер, который может поддерживать стандарт fb2 в полном объеме (по идее, так оно и получилось, кроме блока в description об оригинале книги и коммерческой псевдозащите (мало кто об этом знает из реальных пользователей fb2 :) ). Потом понял, что ВСЕ возможности стандарта вряд ли кому будут нужны в полном объеме, и оставил идею полной поддержки стандарта по практически неиспользуемым фичам стандарта.
Реальную ценность выноса текста книги в несколько <body> даже представить не могу - разве что, как выше писАл Сергей - блок сносок...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Кстати.
Версия текущая (2.30). app-office/libreoffice-bin-4.2.8.2
Корректор текста применяется только к содержимому первого блока <body>.
Во втором блоке (сноски) кавычки остаются неисправленные '"'.
Пока отмечу здесь.
Интересно насколько вероятна документозависимость?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Посмотрю, в чем там дело. В свое время писал код, чтобы АЕЗДЕ кавычки менялись.
Возможно это из-за очередного "сюрприза" от разработчиков LO - они "любят" менять и ломать API :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Как конвертер решает, что именно делать первым и главным <body> документа?
Как отметить ему, что главное тело документа начинается тут, и заканчивается тут.
А вот от еее до бубу - второе <body>?
AFAIR никак. Данной фичи не предусмотрено (де-факто и в рамках формата).
Принцип структурирования простой:
Основной текст (весь) пишется в первый (он же основной) тэг body.
Сноски (сиречь примечания), если таковые имеются, пишутся во второй тэг body.
Концевые сноски (они же — комментарии) также выделяются в отдельный тэг body (второй если в документе присутствует только данный вид сносок или третий, если в документе есть и «обычные» сноски.
В настройках OOoFBTools ЕМНИП есть (была, мне оно требуется не то, чтобы часто) возможность выбора: использовать оба варианта сносок as is, или зафорсить тот или иной тип.
Итого в файле практически [нормально] бывает от одного до трёх тэгов body.
Использование иных структур, пусть и потенциально не запрещённых стандартом, обычно предоставляет возможности исследования особенностей реализации на прикладном уровне (программ для чтения книг).
Лично меня здесь напрягает заявляемое (лично мной практически не используемое, наблюдавшееся только в дистрибутивном примере) выдёргивание из текста, помещаемого в основной тэг body блока аннотации.
По мне оно (текст аннотации) логичнее бы смотрелось рядом с прочими параметрами заголовка. Всё равно отображение (стиль и соответственно применимые элементы форматирования) аннотации не совпадает с основным текстом (говорю на примере CoolReader3).
Первоначально я старался писАть конвертер, который может поддерживать стандарт fb2 в полном объеме (по идее, так оно и получилось, кроме блока в description об оригинале книги и коммерческой псевдозащите (мало кто об этом знает из реальных пользователей fb2 :) ). Потом понял, что ВСЕ возможности стандарта вряд ли кому будут нужны в полном объеме, и оставил идею полной поддержки стандарта по практически неиспользуемым фичам стандарта.
Реальную ценность выноса текста книги в несколько <body> даже представить не могу - разве что, как выше писАл Сергей - блок сносок...
Кстати.
Версия текущая (2.30).
app-office/libreoffice-bin-4.2.8.2
Корректор текста применяется только к содержимому первого блока <body>.
Во втором блоке (сноски) кавычки остаются неисправленные '"'.
Пока отмечу здесь.
Интересно насколько вероятна документозависимость?
Посмотрю, в чем там дело. В свое время писал код, чтобы АЕЗДЕ кавычки менялись.
Возможно это из-за очередного "сюрприза" от разработчиков LO - они "любят" менять и ломать API :)