Предыдущая тема :: Следующая тема |
Автор |
Сообщение |
GribUser Автор формата FB2 - Автор библиотеки FB
Зарегистрирован: 30.09.2004 Сообщения: 2475 Откуда: Москва
|
Добавлено: Чт Июл 03, 2008 17:26 Заголовок сообщения: Драфт FB3 |
|
|
Предложение по формату fb3
Документация касается только собственно файлов книг, библиографии и прочее оставим напопозже. В части общей логики я всё обдумал, в части изменений дескрипшта я более-менее уверен в предлагаемом, в плане возможностей форматирования есть масса вопросов, но, я надеюсь, редакторская общественность поможет нам с этими вопросами разобраться.
Предлагаю присутствующим высказываться - критиковать и дополнять. |
|
Вернуться к началу |
|
|
Alan Автор ридера Alreader и клона Haali
Зарегистрирован: 25.01.2005 Сообщения: 421
|
Добавлено: Чт Июл 03, 2008 17:44 Заголовок сообщения: |
|
|
Что волнует прежде всего меня
1. Отдельное СВОЕ расширение архива, а не маразм типа fb2.zip
2. Неплохо было бы ограничить методы упаковки стандартным дефлейтом, а не всем, что может в себе содержать зип
3. не понятен смысл нескольких текстовых файлов. На мой взгляд текстовая часть должна быть в одном файле, без бессмысленного дробления. формировать общее содержание из нескольких файлов - желания особого нет. Про имена ссылок, которые могут пересекаться в разных файлах, я вообще молчу, а при таком подходе 100% появятся книги-сборники, в которые будут просто копироваться текстовые части из разных книг...
4. Неплохо было бы предусмотреть хранение картинок как внутри документа, так и в виде файлов в архиве, например в отдельной папке Image
5. Заметки с точностью до символа - это конечно красиво, но нереально, имхо... Гораздо удачнее было бы автоматом нумеровать каждый параграф и ссылаться на него.
НО! самое главное конечно - пункт 3. Имхо глупость... Я конечно понимаю, что оригинальность - это наше все, но неплохо было бы учитывать опыт гораздо более распространенных форматов типа опенофиса, абиворда и опен хмл... Текст - отдельный файл. Все дополнительное, без чего по минимуму можно обойтись - дробится в отдельные файлы...
А вот отдельная обложка - вполне удачное новшество будет... |
|
Вернуться к началу |
|
|
GribUser Автор формата FB2 - Автор библиотеки FB
Зарегистрирован: 30.09.2004 Сообщения: 2475 Откуда: Москва
|
Добавлено: Чт Июл 03, 2008 18:00 Заголовок сообщения: |
|
|
Alan писал(а): | Отдельное СВОЕ расширение архива, а не маразм типа fb2.zip | fb3 подразумевается, собственно.
Alan писал(а): | Неплохо было бы ограничить методы упаковки стандартным дефлейтом, а не всем, что может в себе содержать зип | Я в зипах чесгря мало смыслю, в терминах не отвечу, но я целиком за простоту и совместимость. Чего в драфт записать, шоб было корректно и однозначно?
Alan писал(а): | не понятен смысл нескольких текстовых файлов. | Бывают всё-таки БОЛЬШИЕ книжки. И ОЧЕНЬ БОЛЬШИЕ. И читать/парсить весь текст по каждому тычку нет ну никаких причин. Аналогично и при автоматизации всяческой удобнее отдельно со структурой, отдельно с собственно текстом - вплоть до вычитки частей разными редакторами и быстрой перекомпоновки ознакомительных, полных, бонусных текстов и прочего.
Alan писал(а): | Неплохо было бы предусмотреть хранение картинок как внутри документа, так и в виде файлов в архиве, например в отдельной папке Image | А внутри всё, не будет больше. Че-то написать забыл про это, ща поправлюсь.
Alan писал(а): | Заметки с точностью до символа - это конечно красиво, но нереально, имхо | XPointer это реальность, данная нам в ощущениях. |
|
Вернуться к началу |
|
|
Alan Автор ридера Alreader и клона Haali
Зарегистрирован: 25.01.2005 Сообщения: 421
|
Добавлено: Чт Июл 03, 2008 18:01 Заголовок сообщения: |
|
|
Кстати еще неплохо было, что бы текст всего был только в пределах <p></p>... Т.е. чтобы конструкции вида <code>текст</code>, <title>текст</title> и т.д. правильно записывались в виде <code><p>текст</p></code> и <title><p>текст</p></title>, соответственно... |
|
Вернуться к началу |
|
|
GribUser Автор формата FB2 - Автор библиотеки FB
Зарегистрирован: 30.09.2004 Сообщения: 2475 Откуда: Москва
|
Добавлено: Чт Июл 03, 2008 18:08 Заголовок сообщения: |
|
|
Alan писал(а): | Кстати еще неплохо было, что бы текст всего был только в пределах <p></p> | Я тож к этому склоняюсь. Заодно и всякие v в расход пустить, это ашипк был. |
|
Вернуться к началу |
|
|
Mike Sinkovsky Зрелый участник форума
Зарегистрирован: 27.10.2005 Сообщения: 296 Откуда: Пермь
|
Добавлено: Чт Июл 03, 2008 18:11 Заголовок сообщения: |
|
|
Насколько понял тэги <section>, <title> и тому подобное теперь могут быть только в fb3_book.xml, а собственно текст в нем наоборот быть не может, всегда в отдельных файлах? |
|
Вернуться к началу |
|
|
Alan Автор ридера Alreader и клона Haali
Зарегистрирован: 25.01.2005 Сообщения: 421
|
Добавлено: Чт Июл 03, 2008 18:13 Заголовок сообщения: |
|
|
Цитата: | Я в зипах чесгря мало смыслю, в терминах не отвечу, но я целиком за простоту и совместимость. Чего в драфт записать, шоб было корректно и однозначно? |
метод сжатия - deflate
Цитата: | Бывают всё-таки БОЛЬШИЕ книжки. И ОЧЕНЬ БОЛЬШИЕ. |
много чего в жизни бывает. Ради одной такой книги, встреченной среднестатическим читателем за все время активного чтения, не стоит выдумывать бредовые алгоритмы... Да и ради БОЛЬШОЙ книги - читатель вполне может подождать лишние пять-десять секунд. Если опять-таки вспомнить опыт более распространенных форматов - большие файлы не представляют собой особой проблемы...
Цитата: | XPointer это реальность, данная нам в ощущениях. |
ок, в конце концов опция не обязательна к поддержке...
Добавлено спустя 7 минут 12 секунд:
Mike Sinkovsky да, непонятно...
еще другое не понятно - что новая книга всегда должна открываться со страницы, на которой есть ссылки на реальный текст?
Или читалка должна смешать кучу файлов для выдачи текста на экран... Или опять информация должна быть дублирована, типа титл и в тексте и в дескрипшине...
Вроде в фб2 уже были грабли с делением информации на дескрипшин и отображаемый текст... может не стоит наступать на те же грабли еще раз... |
|
Вернуться к началу |
|
|
Mike Sinkovsky Зрелый участник форума
Зарегистрирован: 27.10.2005 Сообщения: 296 Откуда: Пермь
|
Добавлено: Чт Июл 03, 2008 18:20 Заголовок сообщения: |
|
|
Допустимые методы сжатия - store (без компрессии) и deflate (совместимый с zlib).
fb3_meta.xml и cover.[jpg|png] рекомендуется сохранять без компрессии для ускорения доступа.
fb3_meta.xml рекомендуется располагать первым в начале архива, тоже для ускорения доступа. |
|
Вернуться к началу |
|
|
Alan Автор ридера Alreader и клона Haali
Зарегистрирован: 25.01.2005 Сообщения: 421
|
Добавлено: Чт Июл 03, 2008 18:22 Заголовок сообщения: |
|
|
а вообще, в целом, извиняюсь, конечно, но все это очень сыро, что тут "обдумывалось" - не особо видно... |
|
Вернуться к началу |
|
|
Marina_Ch Постоянный участник форума
Зарегистрирован: 14.04.2006 Сообщения: 779 Откуда: Москва
|
Добавлено: Чт Июл 03, 2008 22:05 Заголовок сообщения: |
|
|
Сноски двойные хочется!
Концевые и постраничные. Типа как в ворде. _________________ REB 1100, REB 1200, SE P910i |
|
Вернуться к началу |
|
|
Cherckes Новенький участник форума
Зарегистрирован: 05.05.2007 Сообщения: 89 Откуда: Гомель
|
Добавлено: Пт Июл 04, 2008 4:24 Заголовок сообщения: |
|
|
Цитата: | Тег author в title-info получит новый атрибут role, который будет принимать значения author|translator|compiler|illustrator|editor. |
А мне эта часть очень даже симпатична, по сжатию, много ли людей хранит книги не в аривах? т.е. давно пора. _________________ http://esperantofb2lib.at.tut.by/ - Книги в fb2 на эсперанто. |
|
Вернуться к началу |
|
|
Mike Sinkovsky Зрелый участник форума
Зарегистрирован: 27.10.2005 Сообщения: 296 Откуда: Пермь
|
Добавлено: Пт Июл 04, 2008 8:13 Заголовок сообщения: |
|
|
А действительно, как тогда теперь будут выглядеть ссылки и примечания, раз текст раскидан по нескольким файлам? |
|
Вернуться к началу |
|
|
GribUser Автор формата FB2 - Автор библиотеки FB
Зарегистрирован: 30.09.2004 Сообщения: 2475 Откуда: Москва
|
Добавлено: Пт Июл 04, 2008 11:38 Заголовок сообщения: |
|
|
Mike Sinkovsky писал(а): | Насколько понял тэги <section>, <title> и тому подобное теперь могут быть только в fb3_book.xml, а собственно текст в нем наоборот быть не может, всегда в отдельных файлах? | Да, идея в этом. Непонятно, как быть со сносками в свете всего этого, единственное. Стоит, видимо, пилить сноски не на секции, а выделять их каким-нить специальным контейнером типа <note>, а не секцией. В принципе они по-любому обрабатываются в итоге отдельно, завести им свой отдельный тег уже само напрашивается.
Alan писал(а): | Или читалка должна смешать кучу файлов для выдачи текста на экран... Или опять информация должна быть дублирована, типа титл и в тексте и в дескрипшине... | Почему - кучу? Всего два, дескрипшн и текущую секцию. Ну, если не хочется рвать страницы по секциям - две секции. Чесгря мне задача сложной не кажется. Для этого вся структура и вынесена в отдельный файл, чтобы в каждый момент времени читалке не пришлось иметь дело с большим объемом данных - в простом случае заголовок+еще один файл, в сложном - несколько, но в любом случае ничего катастрофичного.
Alan писал(а): | много чего в жизни бывает. Ради одной такой книги | Ну вот нам в обозримом будущем с такими книгами придется столкнуться. Из-за чего, собстна, и сыр-бор.
Alan писал(а): | ок, в конце концов опция не обязательна к поддержке... | Ну я не вижу, чем вам не угодила запись типа
part3.xml#xpointer(string-range(/contents/p[56],"",16,32))
В принципе стоит в 3.0 ограничить возможности xpointer до прямого указания пути по номеру элемента, а уже там к 3.01 и далее полную поддержку задекларировать. Изобретение велосипедов нам ни к чему, а тут по сути будет стандартная форма записи для совершенно очевидной вещи, и всё это потом легко и органично наращивать можно будет.
Добавлено спустя 13 минут 31 секунду:
Mike Sinkovsky писал(а): | fb3_meta.xml и cover.[jpg|png] рекомендуется сохранять без компрессии для ускорения доступа.
fb3_meta.xml рекомендуется располагать первым в начале архива, тоже для ускорения доступа. |
Хм, а оно там не монофиолетово, где размещается? Всё-равно сперва прочитать заголовок надо со списком файлов, а потом один seek и ты в шоколаде нет?
Mike Sinkovsky писал(а): | А действительно, как тогда теперь будут выглядеть ссылки | notes.xml#id_565
Вот как-то так |
|
Вернуться к началу |
|
|
Mike Sinkovsky Зрелый участник форума
Зарегистрирован: 27.10.2005 Сообщения: 296 Откуда: Пермь
|
Добавлено: Пт Июл 04, 2008 12:18 Заголовок сообщения: |
|
|
По поводу размера - вобще ни разу в жизни не встречал файл чтобы читалка его не взяла. Десятки мегабайт - нормально. Там что, счет уже на сотни?
Гораздо больше нарягает отсутствие сборников, из-за этого читать мелкие рассказы с того же литреса обычно желания не возникает. Банально неудобно.
Добавлено спустя 1 минуту 16 секунд:
GribUser писал(а): | notes.xml#id_565 |
А внешних ссылок теперь не будет чтоли?
Добавлено спустя 7 минут 50 секунд:
GribUser писал(а): | а оно там не монофиолетово, где размещается? Всё-равно сперва прочитать заголовок надо со списком файлов, а потом один seek и ты в шоколаде нет? |
Там свойства файла продублированы в двух местах - перед файлом и в центральном каталоге в конце архива. Так что для прочтения первого файла в архиве читать центральный каталог необязательно.
Хотя, может по нынешним временам это и правда копейки.. |
|
Вернуться к началу |
|
|
GribUser Автор формата FB2 - Автор библиотеки FB
Зарегистрирован: 30.09.2004 Сообщения: 2475 Откуда: Москва
|
Добавлено: Пт Июл 04, 2008 12:47 Заголовок сообщения: |
|
|
Mike Sinkovsky писал(а): | А внешних ссылок теперь не будет чтоли? | Почему? Будут, как и раньше.
Mike Sinkovsky писал(а): | По поводу размера - вобще ни разу в жизни не встречал файл чтобы читалка его не взяла. | Ну это здорово зависит от читалки. На сотни там я не уверен, но вообще меров 30 текста спокойно я могу себе представить. Или вот примеру на литресе есть фича генерации сборников (не доступная публике, пока что), так я в ней легко могу всего Лукьяненко слить, к примеру, в один сборник, сколько там метров выйдет? Ну и так далее. Я вообще не вижу, честно говоря, недостатков у растаскивания секций по файлам. В системе с избытком ресурсов склеить файл из фрагментов руда не составит. А для простых алгоритмов на всех фронтах - от редактуры до каталогизации - открывается огромное поле срезанных углов, куча задач решаются проще при разделенном файле. |
|
Вернуться к началу |
|
|
|
|
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
|
Powered by phpBB © 2001, 2005 phpBB Group
|