Формат NFB

Опубликовано ср, 26/11/2008 - 07:23 пользователем СерыйМыш
ВложениеРазмер
Иконка электронной таблицы Office fb2-nfb relations.xls25.5 КБ
Иконка простого текстового файла NFB Specification_1.0.14_FR.txt32.42 КБ

начиная с 01.12.2008 ТЕМА НЕ МОДЕРИРУЕТСЯ
убедительно прошу воздержаться от нецензурных выражений, беспочвенных наездов и флейма.

изменено: 30.06.2009.
выложена четырнадцатая редакция спецификации

24.04.2009: работы временно приостановлены по субъективным причинам. возобновление планируется на середину мая этого года.
27.04.2009: жалкие попытки заняться полезным делом привели к очередной корректировке спецификации. выложена сравнительная таблица по взаимной совместимости fb2 и nfb.
05.05.2009: победил глюки оперы и залил-таки тринадцатую редакцию
30.06.2009: выложил 14 редакцию. изменений по сравнению с 13-й практически нет, уточнены отдельные мелочи, переведено в стадию "финал релиз".

формат разрабатывается как макcимально упрощенный альтернативный вариант хранения книг.

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

конвертор пока существует только из fb2 в nfb, планируется полная поддержка импорта и экспорта для формата fb2.

у кого есть конструктивные идеи/замечания/предложения - прошу высказаться.

Комментарии

Опубликовано чт, 30/04/2009 - 03:25 пользователем nonduc

Э-э, прости за мои постоянные потуги расширить «NFB_Info», но тут вот какое дело: на Либрусеке, насколько я понимаю, довольно активно используется механизм слежения за автором *.fb2 документа, поскольку некоторые авторы склонны к некоторым недоделкам и т. п. А у тебя автор *.fb2 лишается своего особого блока и помещается в общей секции для доп. сведений «INFO». Вопрос: сможет ли твой каталогизатор вытаскивать эту нужную информацию?

Опубликовано чт, 30/04/2009 - 05:08 пользователем СерыйМыш

при возникновении претензий к определенному "автору" на основании его определённой "работы", вполне возможно глазками разобрать поле INFO и сделать выводы. автоматизированно компоновать файлы по имени "автора" - явно лишнее, особенно учитывая, что подпись в поле "document-info.author" заполняется вообще абстрактно и как придётся, потому как человек в здравом уме не станет указывать подробно свои паспортные данные на "вещественном доказательстве".
в связи с этим настораживает гипотетическая вероятность предъявления претензий всякими копирастами к особо активным оцифровщикам. как-то подсознательно мне не хочется помогать всяким идейным борцам и желающим заработать не работая.
надо голосовать. если выяснится реальная полезность отдельного структурированного блока вида "document-info" - добавлю без вопросов.

Опубликовано пт, 01/05/2009 - 03:33 пользователем nonduc

Что-то типа совета. :)
Наверное, надо завести коллекцию образцов для разного рода документов (сборников, колл. монографий, изданий с многими сопроводительными материалами etc. — чтобы можно было наглядно иметь дело с разными «NFB_Info».

Опубликовано пн, 04/05/2009 - 22:33 пользователем СерыйМыш

выложил триннадцатую редакцию. попытался навести порядок и учесть последние пожелания.

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

Опубликовано чт, 07/05/2009 - 11:26 пользователем kass

Бегло и сумбурно, но…
У сборников часто бывают разные языки оригиналов отдельных произведений. И было бы неплохо иметь возможность указать язык для каждого произведения.
Стихи могут попадать в оглавление по первой строфе. Дублировать?
Неоднозначность сигнатуры ||. Просто придирка, но парсеру надо будет запоминать, что сейчас он, к примеру, сноску обрабатывает.
Дальше смешной вопрос -- сигнатуры типа === автоматически обозначают применение ~~ для последующего текста при наличии каких-то шрифтовых выделений в предшествующем тексте?

Опубликовано пт, 08/05/2009 - 02:01 пользователем СерыйМыш

kass написал:
У сборников часто бывают разные языки оригиналов отдельных произведений. И было бы неплохо иметь возможность указать язык для каждого произведения.

вот аццкий сотона. заметил-таки... а я так надеялся... ладно, впишем уже :)
я надеюсь, нет сборников, в которых тексты на разных языках? или всё-таки есть???

kass написал:
Стихи могут попадать в оглавление по первой строфе. Дублировать?

не, не дублировать. просто задать в начальной сигнатуре пустой заголовок нужного уровня:
[&]===
Лыжи у печки стоят
Не на что лыжам присесть.
[.]
отмечу в спецификации.

kass написал:
Неоднозначность сигнатуры ||. Просто придирка, но парсеру надо будет запоминать, что сейчас он, к примеру, сноску обрабатывает.

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

kass написал:
Дальше смешной вопрос -- сигнатуры типа === автоматически обозначают применение ~~ для последующего текста при наличии каких-то шрифтовых выделений в предшествующем тексте?

да. переход к следующему абзацу/блоку всегда сбрасывает шрифтовое выделение. заголовок выводится своим стилем, текст далее - своим, без выделения.

Опубликовано ср, 13/05/2009 - 13:04 пользователем kass

СерыйМыш написал:
kass написал:
У сборников часто бывают разные языки оригиналов отдельных произведений. И было бы неплохо иметь возможность указать язык для каждого произведения.

вот аццкий сотона. заметил-таки... а я так надеялся... ладно, впишем уже :) я надеюсь, нет сборников, в которых тексты на разных языках? или всё-таки есть???
Таки ты будешь смеяться! Как правило — это узкоспециальные научные издания, но я пару таких не просто видел, а ещё и верстал :)

СерыйМыш написал:
kass написал:
Стихи могут попадать в оглавление по первой строфе. Дублировать?
[...] не, не дублировать. просто задать в начальной сигнатуре пустой заголовок нужного уровня: отмечу в спецификации.
Ага! Это надо.

СерыйМыш написал:
kass написал:
Неоднозначность сигнатуры ||. Просто придирка, но парсеру надо будет запоминать, что сейчас он, к примеру, сноску обрабатывает.
на самом деле не придется. придется по разному обрабатывать маркер при выводе разных видов блоков, но этот вывод сейчас и так сделан с помощью перекрытых методов объектов, так что проблема не столь серьёзна.
опять же - количество символов ограничено, поэтому вразумительные сигнатуры на каждый отдельный случай сложновато придумать.
Вот тут ещё одна засада. Но это тема для большого поста никак не связанного с разметкой, а скорее о методах реализации. Как читалок, так и "библиотекарей".

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

Опубликовано ср, 13/05/2009 - 23:19 пользователем СерыйМыш

kass написал:
СерыйМыш написал:
я надеюсь, нет сборников, в которых тексты на разных языках? или всё-таки есть???
Таки ты будешь смеяться! Как правило — это узкоспециальные научные издания, но я пару таких не просто видел, а ещё и верстал :)
о майн год! как разнобразен мир! *бьётся головой об клавиатуру
kass написал:
Неоднозначность сигнатуры ||
... Но это тема для большого поста никак не связанного с разметкой, а скорее о методах реализации. Как читалок, так и "библиотекарей".
реализация - само собой, но изначальная идея заключалась в ремонтопригодности и полном сохранении структуры при открывании блокнотом. практически все сигнатуры подбирались с учетом того, чтобы их было несложно опознать визуально. поэтому все сигнатуры сделаны из читабельных символов.

kass написал:
СерыйМыш написал:
да. переход к следующему абзацу/блоку всегда сбрасывает шрифтовое выделение. заголовок выводится своим стилем, текст далее - своим, без выделения.
Я думаю, что в спецификации и это надо явно оговорить.

хм. вроде было указано ещё с первых версий:
Сигнатуры форматирования могут встречаться в любом месте текста. Все сигнатуры являются переключателями. Первое вхождение включает указанный формат символов, следующее - выключает. При отсуствии выключающего вхождения формат действует до конца текущего абзаца.
добавлю уточнение на всякий случай. действительно написано неочевидно.

Опубликовано вт, 23/06/2009 - 02:05 пользователем 1_абрам

JAW wrote:
Меня в Fb2 в реализации PocketBook не удовлетворила глубина вложенности Section.
Там, какжется, Title, Part, Section и вроде всё...
Всяких SubSection, SubSubSection, Par (с Inline заголовком) не предусмотрено?

Ладно... Нужно смотреть спецификацию внимательней.

А что делать, если мы в одном документе объединяем разные статьи со своими титламами, возможно разными авторами и т.п.
Типичный научный сборник... Там ещё к каждой статье свой индекс УДК болтается...

А потом всё это разбить среди множества таких томов по рубликации?

GribUser wrote:
Типичный научный сборник

Без шансов, fb2 это не переварит.

А nfb такое переварит?

Опубликовано ср, 24/06/2009 - 01:27 пользователем СерыйМыш

1_абрам написал:
JAW wrote:
Меня в Fb2 в реализации PocketBook не удовлетворила глубина вложенности Section.
Там, какжется, Title, Part, Section и вроде всё...
Всяких SubSection, SubSubSection, Par (с Inline заголовком) не предусмотрено?

уровней вложения заголовков изначально предусмотрено четыре, но в спецификации этот факт жетско не прописан. количество этажей рассчитывалось из соображений удобства пользования оглавлением и усредненной статистики - в основном содержание в книгах имеет два-три уровня деления - Книга первая/Часть первая/Глава первая. четвертый уровень взят для покрытия клинических случаев. вполне допустимо сделать хоть десять уровней вложения, только надо ли?
насчет Par и инлайновых заголовков можно обдумать. но вероятно результатом будет загромождение блока "содержание" и потеря удобства пользования.

1_абрам написал:

А что делать, если мы в одном документе объединяем разные статьи со своими титламами, возможно разными авторами и т.п.
Типичный научный сборник... Там ещё к каждой статье свой индекс УДК болтается...
А потом всё это разбить среди множества таких томов по рубликации?

сборники с разными авторами уже обсуждались: деление в файле идет на уровне текстовых секций - по отдельным публикациям/авторам, внутри секций - по заголовкам разного уровня.
подход к каталогизации такой - обрабатывается служебная секция "bookinfo", и из нее берутся сведенияоб авторах, названиях и т.п. если очень нужен поиск и систематизация по отдельным статьям - оформлять в виде отдельных секций и прописывать в bookinfo.

1_абрам написал:
GribUser wrote:
Типичный научный сборник
Без шансов, fb2 это не переварит.
А nfb такое переварит?

не вижу пока ни одной причины не переварить.

п.с. мне неимоверно стыдно, но никак не могу заставить себя доделать движок читалки. завал на работе плюс ремонт дома, в итоге сил и желания практически не остаётся. надеюсь, когда-нибудь ситуация поменяется.

Опубликовано пт, 26/06/2009 - 02:17 пользователем 1_абрам

СерыйМыш написал:

п.с. мне неимоверно стыдно, но никак не могу заставить себя доделать движок читалки. завал на работе плюс ремонт дома, в итоге сил и желания практически не остаётся. надеюсь, когда-нибудь ситуация поменяется.

Да одному все это поднять нелегко.

Вы и так сделали много.

По-хорошему, этот проект должен поддержать Ларин: деньгами или хотя бы заявлением о постепенном переводе либрусека на nfb.

Опубликовано пт, 26/06/2009 - 03:34 пользователем СерыйМыш

1_абрам написал:

По-хорошему, этот проект должен поддержать Ларин: деньгами или хотя бы заявлением о постепенном переводе либрусека на nfb.

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

по поводу денег - они не помогут. вряд ли у грибова на его работе мало платят, однако fb3 до сих пор не вышел из состояния драфта.
и вообще, я изначально объявил и буду в дальнейшем настаивать: моя разработка была и будет бесплатной и открытой. любого, кто попробует использовать её для зарабатывания денег, я предам анафеме и затаскаю по судам.
кстати, похоже самое время на всякий случай сделать фиксацию факта авторства и подумать, под какой лицензией жить дальше. скорее всего GNU GPL/FDL или СС-NC, надо перечитать и выбрать.
П.С. очень хочется присобачить СС BY-NC-SA, но в нашей стране нет адекватного закона на этот счет. буду думать.

Опубликовано пн, 29/06/2009 - 02:14 пользователем 1_абрам

< сразу две ошибки в одном предложении

<во-первых - Ларин никому из нас ничего не должен

Ну почему же, затеяв такой проект он несет перед нами определенную моральную ответственность. Например, кореец, drserj и др. разработали разработали замечательные программы, предполагая, что либусек не прекратит свою работу.

>по поводу денег - они не помогут. вряд ли у грибова на его работе мало платят, однако fb3 до сих пор не вышел из состояния драфта.

Ну деньги, иногда, штука очень полезная. Например, если бы ваш проект в какой-то степени финансировался, то вы бы побыстрее закончили ремонт и написали движок. Кроме тоо деньги пригодились бы для регистрации авторских прав и торговой марки на "nfb".

Опубликовано пн, 29/06/2009 - 04:50 пользователем СерыйМыш

1_абрам написал:
< сразу две ошибки в одном предложении
<во-первых - Ларин никому из нас ничего не должен

Ну почему же, затеяв такой проект он несет перед нами определенную моральную ответственность. Например, кореец, drserj и др. разработали разработали замечательные программы, предполагая, что либусек не прекратит свою работу.


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

1_абрам написал:
>по поводу денег - они не помогут. вряд ли у грибова на его работе мало платят, однако fb3 до сих пор не вышел из состояния драфта.
Ну деньги, иногда, штука очень полезная. Например, если бы ваш проект в какой-то степени финансировался, то вы бы побыстрее закончили ремонт и написали движок.

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

1_абрам написал:
Кроме тоо деньги пригодились бы для регистрации авторских прав и торговой марки на "nfb".

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

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

Опубликовано пн, 29/06/2009 - 14:01 пользователем kass

СерыйМыш написал:

п.п.с. в ближайший день-два выложу 14 редакцию спецификации, статус "релиз". хватит уже в кандидатах сидеть.

И таки хотелось бы увидеть «прозрачный» маркер «номер страницы в оригинальном издании». И, как вариант, сослаться на него из другой книги.
Т. е. довести до идеала: «Возможен переход по ссылке или вывод расшифровки в виде подсказки.
Допускается указание номера страницы после номера книги:
Подробнее данная тем описана в ["1,234]».

P. S. А поглядеть на исходники того, что было в самом начале в исполняемом виде с примером, можно? :)

Опубликовано пн, 29/06/2009 - 22:56 пользователем СерыйМыш

kass написал:
И таки хотелось бы увидеть «прозрачный» маркер «номер страницы в оригинальном издании». И, как вариант, сослаться на него из другой книги.
Т. е. довести до идеала: «Возможен переход по ссылке или вывод расшифровки в виде подсказки.

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

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

kass написал:
P. S. А поглядеть на исходники того, что было в самом начале в исполняемом виде с примером, можно? :)

легко. только надо учесть, что написано под дельфи7 без vcl, с использованием GDI+. если всё ещё интересно - скинь личным письмом асю/жабу, сконтачим.

Опубликовано вт, 30/06/2009 - 15:53 пользователем kass

Каюсь, действительно не вкурил про номера страниц :) Их надо сделать опционально отображаемыми.
А вот остальное и, в том числе, проблемы с лёгкой читалкой и серьёзным библиотекарем — надеюсь опишу. К сожалению у меня те же проблемы с работой, квартирой итд. Идей куча, а времени просто физически не хватает.

Но есть предложение :) Так как формат ушёл довольно далеко от «плоской» литературы — выбрать несколько эталонных книг, которые хотелось бы иметь в адекватном отображении (для начала без математики). И с ростом формата — увеличивать список :)

Опубликовано вт, 30/06/2009 - 23:15 пользователем СерыйМыш

kass написал:
Каюсь, действительно не вкурил про номера страниц :) Их надо сделать опционально отображаемыми.
это уже детали реализации читалки.
kass написал:
Но есть предложение :) Так как формат ушёл довольно далеко от «плоской» литературы — выбрать несколько эталонных книг, которые хотелось бы иметь в адекватном отображении (для начала без математики). И с ростом формата — увеличивать список :)
именно такая мысль и была. приоритетная задача на сегодня - читалка+редактор.
демку я форматировал руками, но для серьезных по объему текстов это неприемлемо.
математика пока не поддерживается, планируется всё это отдать на откуп плагинам.

Опубликовано пн, 29/06/2009 - 13:55 пользователем kass

До кучи :) Заголовок со сноской. Козьма Прутков сильно этим страдал :)

Опубликовано пн, 29/06/2009 - 08:08 пользователем 1_абрам

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

Очень рад от вас это слышать, хоть здесь коммунистические идеи побеждают.

>п.п.с. в ближайший день-два выложу 14 редакцию спецификации, статус "релиз". хватит уже в >кандидатах сидеть.

Здорово.

Опубликовано ср, 01/07/2009 - 00:47 пользователем СерыйМыш

в процессе написания парсера секции bookinfo в ум пришла и не уходит одна назойливая мысль: зачем я сделал разные ключи для названия одиночной книги и названия сборника?
по идее, само по себе наличие конструкции PART:000х ... ENDP: обоначает, что имеющийся файл содержит сборник. или же несколько самостоятельных частей - например собственно книгу, вступительную статью/предисловие, послесловие и т.п.

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

теперь вопрос такой: нужно ли отдельно указывать, что данный файл (книга) по сути является сборником?
теоретически этот факт можно обозначить в головном реквизите FORM: - форма произведения = сборник. вот как-то так.

я прав? или есть что-то, что я не заметил?

Опубликовано чт, 02/07/2009 - 15:30 пользователем kass

СерыйМыш написал:

я прав? или есть что-то, что я не заметил?

Может я и ошибаюсь, но спорно.
COLL однозначно говорил что это многосоставная книга. И уже не так важно, сборник это или издание с кучей допов.
Я предлагаю другой вариант: разделить нынешний BookInfo на два раздела. BookInfo и PartInfo. И тогда в первую часть попадают выходные данные об издании и тип издания. А потом мы имеем энное количество частей. И тогда там, если в букинфо стоит «самостоятельное произведение» -- мы уже на EDIC, к примеру, внимания не обращаем. Бо для одного издания редакторско-корректорский коллектив, как правило не изменяется. За редким исключением «Печатается по изданию такому-то». Заодно это упрощает парсинг. Для чтения данных «одночастёвой» книги не надо будет пробегать весь файл.
Ах да, ну и разные издания — тоже проще парсить :) Тело книги читать не придётся.

Опубликовано ср, 01/07/2009 - 00:55 пользователем СерыйМыш

в догонку:
автор допматериалов в отдельном реквизите в данном случае тоже становится не нужным. то, чот это допматериалы также можно выяснить из частного реквизита FORM, указанного для соответствующей секции.

вот такой блин финал релиз...
готовлю 15-ю редакцию.

Опубликовано чт, 02/07/2009 - 13:46 пользователем kass

Становится не совсем понятен смысл поля FORM. Для карты в допе это будет что? А для одной и той же статьи в журнале и в приложении? А когда это современная книжка и есть диск? Который вроде бы тоже часть книги? С ним как? :)

Опубликовано чт, 02/07/2009 - 14:26 пользователем kass

«Каждый реквизит в секции должен завершаться парой символов CR+LF»
Тоже ни разу не хорошо. Win и местами symbian. Большинству остальных хватает LF :) Они не от печатных машинок произошли :)))

P. S. СерыйМыш, а нет желания или на адобовскую или на гугловскую площадку вынести обсуждение? С возможностью хотя бы коллективных комментариев к документу?
И коллективно в стиле rfc оформить.

Опубликовано чт, 02/07/2009 - 15:45 пользователем kass

«Например:
LANG:RU
SRCL:EN
AUTH:Брэдбери, Рэй, Дуглас
AUTH:Bradbury, Ray, Douglas
TITL:Марсианские хроники
TITL:The Martian Chronicles»

Хм, а не так:
«LANG:RU
AUTH:Брэдбери, Рэй, Дуглас
TITL:Марсианские хроники
ISBN: x-xxxxx-xxx-x
SRCL:EN
AUTH:Bradbury, Ray, Douglas
TITL:The Martian Chronicles
ISBN: x-xxx-xxxxx-x»
Пока у нас LANG=RU -- наше всё. Остальное -- надо, скорее, для библиотекарского софта и поиска. Заодно блоком парсить проще, чем чётные и не очень строки. Я уж не говорю, про издания в которых имя автора даётся на языке оригинала, в англицкой транскрипции и в русском звучании.

А потом мы дойдём до того, что будем говорить о конкретной книге BOKL:RU, SRCL:EN. И добавлять кучу PNTL:XX для поиска по изданиям на других языках.

Опубликовано чт, 02/07/2009 - 15:56 пользователем kass

Немного пропускаем и переходим к картинкам.
Я уже почти верю в коллективный разум, но когда-то найдётся гений, оформивший горизонтальную картинку межабзачного узора высотой в 15 строк. И при этом с шириной 30% и обтеканием справа. Кажется нужны более жёсткие правила.
Потом найдётся картинка, в которой подпись больше, чем графика. Собственно уже :) Я на досуге пытаюсь первую Тесловскую книжку во вменяемый вид из djvu перевести. Там такие есть :)
Бэг пардон, что наскоками и сумбурно :) Я в кои-то веки дома до компа добрался не заснув по дороге :)

Опубликовано пт, 03/07/2009 - 17:05 пользователем kass

Случайно ткнулся в Серия в Либрусеке. Нужно что-то делать. и оху… мрачно.

Там, ближе к нынешней дате, даже таки звучат слова не мальчиков, но мужей :)
Надо срочно учиться на их ошибках :)

Опубликовано пн, 06/07/2009 - 01:50 пользователем СерыйМыш

отвечаю оптом:
насчет CR+LF согласен. вроде уже обсуждалось, однако почему-то в спецификации остался первоначальный вариант.
с реквизитом FORM надо поработать, но суть его не меняется. форма произведения вполне поддается классификации. а то что не поддается - сгибается по месту и классифицируется по общим правилам.
присобачивать диск внутрь файла с книгой - имхо перебор. пусть уже лежит отдельно.

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

с языками текста и оригинала, и определением, на каком языке задан реквизит, возникло некоторое затруднение. возможна ситуация, когда указаны, например, две издательские серии, каждая на двух языках - итого 4 одинаковых реквизита. как их тасовать и компоновать - не совсем очевидно.

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

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

Опубликовано чт, 09/07/2009 - 07:28 пользователем 1_абрам

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

После 14-ой версии спецификации и ее годичного обсуждения так сделать уже не получится :).

Опубликовано чт, 09/07/2009 - 13:01 пользователем kass

1_абрам написал:

После 14-ой версии спецификации и ее годичного обсуждения так сделать уже не получится :).

Эмм? А почему? Пользуемся мы-же браузерами или офисными пакетами. И там энная версия или год обсуждения — это просто очередной верстовой столбик на дороге.

Опубликовано сб, 11/07/2009 - 07:08 пользователем СерыйМыш

1_абрам написал:

После 14-ой версии спецификации и ее годичного обсуждения так сделать уже не получится :).

ещё как получится :)
на данный момент не существует ни одной программы, поддерживающей формат nfb, поэтому изменения никому не создадут проблем.
к тому же, конструктивных/идеологических изменений не будет, будет косметическая доработка по месту напильником.

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

Страницы
X