Формат NFB
Опубликовано ср, 26/11/2008 - 07:23 пользователем СерыйМыш
начиная с 01.12.2008 ТЕМА НЕ МОДЕРИРУЕТСЯ изменено: 30.06.2009. 24.04.2009: работы временно приостановлены по субъективным причинам. возобновление планируется на середину мая этого года. формат разрабатывается как макcимально упрощенный альтернативный вариант хранения книг. работы над спецификацией формата практически закончены. конвертор пока существует только из fb2 в nfb, планируется полная поддержка импорта и экспорта для формата fb2. у кого есть конструктивные идеи/замечания/предложения - прошу высказаться.
|
|||||||
Комментарии
Отв: Формат NFB
СерыйМыш писал:
СерыйМыш писал:
СерыйМыш писал:
СерыйМыш писал:
СерыйМыш писал:
Отв: Формат NFB
для тех, кто не потерял интерес к теме, выложена восьмая версия спецификации, практически release candidat.
учтено большинство пожеланий, встречавшихся в обсуждениях.
в связи с личным интересом добавлена поддержка билингвальных книг.
ведутся работы над разделением движка на независимые части, одна из которых отвечает за парсинг, другая за визуализацию, с целью облегчить в дальнейшем портирование и замену механизма отрисовки при возникновении такой необходимости.
Отв: Формат NFB
Надо бы добавить в спецификацию "Ключевые слова", а так все здорово.
Для продвижения формата необходимо:
создать редактор для создания nfb книг или написать плагин для имеющегося редактора (например, emeditor);
написать читалку для чтения на мобильных устройствах, либо конвертер nfb->lrf и nfb->wol.
Отв: Формат NFB
полагаю, запись вида
KEYW:ключевые слова, много и разные
должна справиться с задачей.
на первом месте - читалки для WinCE, WinMobile и Symbian.
затем конвертеры.
спецификацию на .lrf нашел, буду ковырять.
!!! ищу спецификацию на формат .wol, у кого есть, прошу поделиться.
Отв: Формат NFB
Отв: Формат NFB
С ISNB не так просто: их может быть несколько, например:
http://www.glencook.org/index.php/The_Books_of_the_South
* 0-765-32066-5 (ISBN-10)
* 978-0765-32066-7 (ISBN-13)
Отв: Формат NFB
на самом деле всё гораздо проще, чем кажется:
NFB_Info:
...
ISBN:0-765-32066-5
ISBN:978-0765-32066-7
в большинстве случаев эта инфа пригодится только при визуальном сравнении двух разных версий файла. ну или для поиска, что маловероятно, но вполне реализуемо программно.
Отв: Формат NFB
Пытаюсь читать и обрабатывать "Чёрную пешку" Лукьянова. Есть идея - включить в формат поддержку звука и видео (звук - воспроизводить в пределах главы, видео - показывать первый кадр как обычную картинку, а воспоизводить при щелчке или mouseover'е).
Если звук не поддерживается читалкой - можно игнорировать, если не поддерживается видео - показывать вместо него статичную картинку (в т.ч. и задавать альтернативную картинку при подготовке документа).
Ещё одно не помешало бы - поддержка CSS. Как именно - пока не знаю, во всяком случае, в виде внешнего форматтера должно быть холерно неудобно. :(
Отв: Формат NFB
извини за категоричность, но в рамках предлагаемого формата - однозначно нет.
для компоновки в книге разных типов медиа-контента больше подходят контейнеры типа разрабатываемого fb3, матрешки, огг и т.п.. формат nfb ориентирован на простое текстовое содержимое и статичные картинки. размер звука/видео на несколько порядков превышает размер текста, что в данном случае весьма критично. одно дело положить в телефон/читалку архив в 200-300 кб, или ту же книгу, но обвешанную звуком и видео общим весом в 100 мб.
как говорится - "почувствуйте разницу".
имхо поддержка css должна делаться не внутри файла, а в параметрах читалки. формат nfb (как впрочем и fb2) - это логическая разметка. а как отображать разные элементы текста - это должен решать движок визуализации. теоретически прорабатывался вопрос со стилями оформления, но поскольку основная задача была сделать платформо-независимый формат, который можно без переконвертации использовать и на компе, и на пда, и на телефоне, встраиваемыми стилями пришлось пожертвовать.
для тех, кто хочет однозначности в оформлении - tex, html или pdf.
Отв: Формат NFB
Ещё одно удобство было бы - сборка и "отладка" книги с картинками: на время подгонки разместить картинки снаружи и править их как угодно (размеры, форм-фактор, яркость=-контрастность и т.д.), а потом, когда всё подогнано, "лёгким движением руки" в редакторе собрать картинки внутрь тела документа.
...С моими запросами придётся перебираться на fb3... :(
Отв: Формат NFB
Не стоит преумножать сущности. В твоей задумке нет абсолютно никаких новых идей. Не стоит "шпынять" fb2 и GribUser-а за литресовское настоящее. Не нужен "альтернативный" формат "на зло врагу".
СерыйМыш, новый формат для fiction book - штука достаточно сложная. На голом "энтузизизме" здесь не прокатишь, не найти дешевой популярности. Думай больше.
Отв: Формат NFB
* (неконструктивный флейм)
про умножение неоплачиваемых сущностей мы уже слышали.
к fb2 и грибову у меня политических претензий нет, исключительно технологические. новый формат делаю не "на зло врагу", а "на радость другу".
а кто сам ничего сделать не может - пусть думает.
устал я от вас. по десять раз одно и то же.
Отв: Формат NFB
Вот, честно говоря, любопытно услышать - а что же ты сделал? eBook-остроению уже не один год. Список разработанных программ, форматов, оцифрованных книг - в студию, плиз.
P.S. Видали мы пионэров...
Отв: Формат NFB
Уважаемый СеНс, хотел бы заступиться за серую мышь. С чего вдруг такая агрессия с Вашей стороны. Человек старается, а вы его пионэром обзываете, прям по известной пословице: "За свои пирожки - ты еще и пидорас"
Над новым форматом работать нужно - недостатки фб2 очевидны и не раз обсуждались .
Новый формат во-многом устраняет эти недостатки.
Серой мышью сделано немало: спецификация, пример, конвертор фб2-нфб, читалка. Посмотрите текст примера, какая простая разметка текста, как замечательно отображаются стихи.
ЗЫ. Пользуясь случаем хочу поблагодарить СеНса за замечательную программу JAP.
Отв: Формат NFB
Сорри за мегаоффтоп, но можно поподробнее о программе JAP?
Отв: Формат NFB
читай http://www.the-ebook.org/forum/viewtopic.php?t=5366
там подробно.
Отв: Формат NFB
Спасибо.
Отв: Формат NFB
По всем пунктам полностью с тобой согласен.
1. ты абсолютно прав, я ничего не сделал. нет никакого списка разработанных программ и форматов. единственное, что я написал в своей жизни - это спецификация на нфб-формат (см. выше) и демка читалки для этого формата (см. в ветке про fb3, если не потёрли). ни одной художественной книги я за свою жизнь не оцифровал, и никакой пользы людям не принёс.
2. да, я пионэр. и хрен с ним, что уже 18 лет с компами работаю, я ничего не умею и ничего не знаю, только всем голову морочу.
3. твои предыдущие посты являются конструктивными и полностью соответствующими тематике данного обсуждения.
Отв: Формат NFB
Прошу прощения за оффтоп, но раз здесь комментарии теперь не трут, то выскажу свое ИМХО :)
Прочитав страстный многословный пиар своего формата от СерыйМыш'а в левой теме, понятно было , что все это в принципе повторение того, что уже есть, ничего нового и т.п. Поэтому когда его турнули оттуда, подумал, что логично, НО! положил в закладки эту тему, чтобы периодически смотреть. Зачастую как раз параллельное развитие программных продуктов (изначально одинаковых) и позволяет остаться лучшему. Или продолжать развиваться каждая в своей нише (FreeBSD, OpenBSD, NetBSD).
Может быть и здесь получится что-то стоящее, чем я сам буду потом пользоваться, СерыйМыш мне показался достаточно квалифицированным спецом. Если нет - так нет, значит не судьба.
Но лезть сюда с комментариями "да это все было, нет новых идей, надо только новые технологии внедрять, думай больше"... Прочитали описание формата и цель его создания? Не нравится, не будете пользоваться? Проходите мимо, в те темы, в которых обсуждают то, что вам интересно, может пока вы тратили здесь время на написание никому ненужного комментария, там без вас уже пропадает какая-то гениальная идея, которую нужно поддержать...
ЗЫ. Собственно говоря зачем _я_ это пишу? Задел меня такой момент - SeNS, я так понимаю уважаемый человек в в мире е-бук,
создатель программы JaP, на страничке этой программы, указанной выше, позволяет себе размещать такой текст:
А вежливую просьбу создателя этого топика "у кого есть конструктивные идеи/замечания/предложения - прошу высказаться" почему то игнорирует.
Неприятно как-то получается (кто не понял почему неприятно, сходите на страничку, куда посылает уважаемый товарищ/господин SeNS)
Отв: Формат NFB
в спецификации:
* ISBN: - издательский код книги. Блок должен быть один или отсутствовать.Отв: Формат NFB
подправим. кстати, как тогда быть в случае с переизданными книгами? указывать последний код, или все коды складывать в кучу? вроде бы логично предположить, что электронная книга сделана на основе какого-то конкретного варианта бумажного издания. хотя...
Отв: Формат NFB
ISBN нужен в первую очередь для идентификации книги.
Книга изначально может содержать несколько идентификаторов. например:
http://www.ozon.ru/context/detail/id/4251925/
ЕСЛИ УКАЗАНО НЕСКОЛЬКО ISBN, ЭТО ОЗНАЧАЕТ, ЧТО...
книга — один из томов многотомного издания. - Соответственно указывается ISBN многотомника и отдельно ISBN для каждого тома.
- это переводное издание — первый ISBN для данного перевода, а второй ISBN для оригинала.
- книга одновременно выпущена несколькими издательствами
насколько я знаю сейчас принято решение присваивать ISBN и электронным изданиям.
вот нашел:
Международная стандартная нумерация книг распространяется на книги и брошюры; альбомы и атласы; комплектные издания; аудио-, видеоиздания; электронные издания; издания на микроносителях; издания для слепых шрифтом Брайля.
Сериальные и нотные издания нумеруют специальными идентифицирующими системами ISSN (International Standard Serial Number) и ISMN.
кстати ISSN и ISMN логично сразу предусмотреть - типа если будет то сразу и поддерживаться будет. :)
Отв: Формат NFB
убедил :)
включить ISSN и ISMN в набор поддерживаемых ключей проблемы не составляет.
по поводу поддержки нотнной записи средствами формата вопрос я не стал задавать, хотя и думал об этом. вполне возможно реализовать поддержку нот средствами подключаемого форматера, но только надо ли? полагаю, что всё-таки не стоит сваливать всё в кучу, пытаясь "объять необъятное и впихнуть невпихуемое" (с).
есть MusicXML, который при всей своей чудовищности всё-таки завоевал популярность и поддерживается многими программами. вот пусть в него и загоняют ноты.
Отв: Формат NFB
выложена девятая редакция спецификации, которой присвоен статус release candidat.
возобновлена работа над движком.
паралельно ведутся исследования Symbian OS и попытки писать под нее программы. пока результаты обнадёживающие.
Unicode vs cp1251 - кто победит?
суть вопроса такая:
есть ли смысл переводить все книги в юникод?
понятное дело, что в win-1251 файлы занимают меньше места, но в связи с повальным переходом нового софта на юникод возникла дилема - пожертвовать размером и производительностью ради универсальности, либо продолжать поддержку национальных кодовых страниц.
для теоретиков дополнительная инфа:
в идеале, файл, содержащий _только_ национальные символы, в utf-8 весит ровно в два раза больше такого же файла в cp1251.
НО! при архивировании одинаковых по содержанию файлов, один из которых в cp1251, а второй в utf-8, разница уже не столь существенна. архив с юникодом весит всего лишь на 20% больше.
при наличии в файле картинок в base64 или большого количества латиницы, эта разница становится ещё меньше - порядка 10-15%.
c utf-16 картина похожая, но разница в упакованном виде несколько больше.
при работе программы соответственно для юникода требуется вдвое больше памяти, чтение данных из utf-8 в 2-3 раза медленнее, парсинг оптимизированными алгоритмами тоже в 2-5 раз медленнее.
стоит ли овчинка выделки?
кто что думает на этот счёт?
Отв: Unicode vs cp1251 - кто победит?
IMHO
Системно - за юникодом будущее. Тексты невелики объёмом и даже и двукратный рост размера библиотеки не критичен для нынешних хардов - всё равно вся литература рунета на один комп влезет...
Только если делать юникод - то жёстко. Чтобы даже опции "сохранить в ... кодировке" не было. Юникод так юникод.
/IMHO
Отв: Unicode vs cp1251 - кто победит?
в очередной раз сорвался перевод спецификации в состояние "release" :)
для формата .nfb в качестве кодировки выбирается utf-8.
после перечитывания матчасти решено обеспечить в редакторе корректную поддержку диакритических знаков, посему вопрос первый - нужен ли механизм автоматической/полуавтоматической трансляции "фиктивных" знаков ударения, организованных с помощью монолитных символов (типа: "á" - $00E1), в реальные пары - кириллический символ ("а" - $0430) + знак ударения ("´" - $00B4) ?
вопрос второй - нужна ли полная нормализация?
ну и до кучи, нужен ли контроль диапазона символов, и поиск слов, содержащих символы из разных национальных кодировок для отлова случайной или намеренной подмены символов с похожим начертанием (например латинская "A" и русская "А") ?
Отв: Unicode vs cp1251 - кто победит?
Если подходить фундаментально, а на мой вкус со спеками только так и надо, то надо все. Диакритику можно смело относить к стилистическим элементам. Да и потом, при корректном лингвоанализе проще будет выделять подоснову при разделении символа и диакрита. А то как бы не пришлось мучится как с непарными кавычками "Открывающая она или нет?". То же и по поводу контроля диапозона. С ним улучшится автокорректура.
Отв: Unicode vs cp1251 - кто победит?
Отв: Unicode vs cp1251 - кто победит?
википедия на этот счёт говорит следующее:
Для определения формата представления Юникода в текстовом файле используется приём, по которому в начале текста записывается символ U+FEFF (неразрывный пробел с нулевой шириной), также именуемый меткой порядка байтов (англ. Byte Order Mark, BOM). Этот способ позволяет различать UTF-16LE и UTF-16BE, поскольку символа U+FFFE не существует. Также он иногда применяется для обозначения формата UTF-8, хотя к этому формату и неприменимо понятие порядка байтов. Файлы, следующие этому соглашению, начинаются с таких последовательностей байтов:
UTF-8
EF BB BF
UTF-16BE
FE FF
UTF-16LE
FF FE
так вот, наличие метки BOM в принципе оправдано для поддержания "дружественности" к редакторам типа notepad. при этом наличие собственной сигнатуры для формата и жесткое указание использовать utf-8 делает наличие метки необязательным.
ИСПРАВЛЕНО:
решение такое: метку EF BB BF использовать настоятельно НЕ рекомендуется, но независимо от ее наличия или отсутствия идентификация формата производится на основании собственной сигнатуры, и в качестве кодировки всегда используется utf-8.
использовать UTF-16LE и UTF-16BE в данный момент смысла не вижу, тем более, что это afaik изобретение майкрософта, и стандартом не является.
ДОБАВЛЕНО ПОЗЖЕ:
товарищи пингвиноиды, скажите своё веское слово, как к метке BOM относятся ваши любимые текстовые редакторы? стоит ее добавлять в файл или нет?
Отв: Unicode vs cp1251 - кто победит?
У меня локаль utf-8, поэтому что с меткой, что без неё - разницы никакой. Всё нормально открывается.
А вот если файл в cp1251, то приходится ручками выбрать кодировку.
Собственно, utf-8 сейчас самая распространённая локаль, по крайней мере в русскоязычных странах.
Тут надо больше виндовыми редакторами интересоваться, ИМХО.
Отв: Формат NFB
стадия Release Candidat окончательно достигнута.
выложена 10 редакция спецификации.
хотелось бы услышать мнение по поводу явного указания размеров иллюстраций в процентах от ширины страницы и в "строках", потому как это изменение было внесено в последний момент, и до этого не обсуждалось.
в читалке(движке) планируется реализовать "адаптивное" масштабирование - то есть подгонку масштаба с учетом кратности получаемой картинки к исходному размеру, что по идее должно позволить получить максимум качества.
кроме этого, обдумывается необходимость/возможность "подрезать" вставляемую картинку под размер, кратный по высоте/ширине 16 пикселям, что даст возможность использовать готовые алгоритмы/процедуры сглаживания и минимально "замыливать" картинку при изменении масштаба.
интересно отношение уважаемой публики к масштабированию иллюстраций, как таковому, и к иллюстрациям вообще.
Отв: Формат NFB
Бросилось в глаза:
считаются навными 100%
*Якоря не мо
Вы вроде бы согласились добавить в спецификацию ключевые слова, передумали?
Отв: Формат NFB
пофиксено.
вроде бы все основные моменты учтены, мелочёвку можно добавить по ходу дела.
теперь осталось перебороть лень, и заново написать движок для читалки.
Отв: Формат NFB
Есть несколько вопросов по спецификации.
1) Выравнивание:
По ширине не предусмотрено совсем - это косяк или по умолчанию (без выравнивания попалось в описании) оно само будет по ширине?
|> - выравнивание по правому краю
|< - выравнивание по левому краю (без абзацного отступа)
|= - выравнивание по центру строки
2)По поводу выделения текста:
**полужирный
//курсив
__подчеркнутый
--зачеркнутый
~~обычный - отмена любого выделения
т.е. для куска текста курсивом имеем следующий синтаксис:
Тут обычный текст, а дальше курсив от сих и до сих. Тут опять обычный...
Тут обычный текст, а дальше //курсив от сих и до сих.~~ Тут опять обычный...
И аналогично для остальных стилей?
Если нужно сделать курсивом (болдом, не суть) весь абзац, надо ли закрывающий тэг-символ в конце абзаца ставить или автоматически в конце абзаца предусмотрен переходить в режим "обычный текст"?
По идее экономичнее автоматом снимать выделение в конце абзаца.
Предусмотрена ли комбинация выделений? Например болд+курсив,курсив+ подчеркивание, болд+курсив+подчеркивание?
И комбинация этих болдов-кусивов с разрядкой-уплотнением, индексами?
3) По оформлению таблиц:
Часто в таблицах выделяется жирным целая строка (чаще шапка) или столбец.
Может ввести дополнительный вариант распространения выделения жирным на всю строку (и/или столбец) неким указателем?
Например так:
$>>*|>|>|>|>$|
где >>* указание на жирность всей строки (синтаксис может быть другой),
для жирного (первого) столбца что-нить вроде:
$|v*>|>|>|>$|
4) По поводу картинок:
Использование инлайновых картинок планируется? Раз уж формат для "нехудлита"?
Формулы там всякие ( в виде картинок внутри абзаца, строки? Прочие мелкие графические элементы, высотой максимум в 2 строки тоже внутри абзаца?
Свои средства написания формул (подключаемые плагины, форматеры) - хорошо, но при наличии готовых решений, которые делают формулу картинкой (типа маттайпа), да и готовых текстов, где формулы уже вставлены мелкими картинками, имхо, надо предусмотреть подобную возможность.
Если я где чего в спеках не углядел по перечисленным вопросам, прошу сильно ногами не пинать )
Буду еще поглядеть спеки, может еще какие комментарии по ним появятся...
Отв: Формат NFB
вернул в спецификацию комментарии, в которых этот момент описан.
по умолчанию выравнивание обычного текста - по ширине страницы, заголовков - по центру, текстовых блоков - по ширине блока, стихи ровняются отдельно по типографским принципам.
в пятой и шестой редакциях было описано подробно, в остальных было убрано ради уменьшения размера текста. сейчас вернул в спецификацию и это.
Допустимы варианты:
Обычный //курсив// снова обычный
Обычный //курсив ~~снова обычный
Обычный //курсив **полужирный курсив// просто полужирный **обычный
Обычный //курсив **полужирный курсив __подчеркнутый полужирный курсив ~~обычный
с таблицами планирую позаниматься отдельно. в процессе написания парсера будет видно, как удобнее реализовать такую фичу. пока вполне возможно задать выделение для всей строки так:
$|*|*|*|*$|ячейка 1|ячейка 2|ячейка3|ячейка 4
картинки, вставленные между абзацами, в настоящий момент реализованы. подгонка высоты/масштаба картинки в привязке к высоте строки текста также предусмотрена.
насчет врезки катринок в строку (по типу строчного форматера) думал. не нравится тот факт, что картинки в основном растровые и фиксированного цвета. в результате получается, что основной текст выглядит прилично, а картинка, вклинивающаяся в текст, всё портит.
теоретически возможно сделать для картинок прозрачный фон и изменяемый основной цвет, но полюбому большого качества при масштабировании растра ожидать не стоит.
поэтому либо городить вектор (svg вероятно в будущем всех победит), либо рисовать подключаемым плагином по месту.
хорошо бы
Отв: Формат NFB
Вроде бы весь тред прочитал, но есть один вопрос...
Почему файл должен быть правильным по формату только если
И еще, не проще ли применять традиционное отображение hex-символов типа 0х0000 или 0000h?
Отв: Формат NFB
1. по сигнатуре формата (FormatID) программы будут определять принадлежность файла к формату NFB и его версию. поэтому однозначно в начало файла. вас же не удивляет наличие сигнатуры "Rar!" в начале рар-архива? или сигнатуры %PDF в начале файла .pdf?
2. секция BookInfo содержит информацию о книге, которая нужна при обработке файла каталогизаторами, или при отображении свойств файла с помощью расширения для проводника. чем ближе эта секция к началу, тем быстрее она будет прочитана. то же самое и с аннотацией, и с обложкой. рыскать по всему файлу в поисках отдельных кусочков - тормозно и некошерно. именно поэтому кстати было принято решение перенести блок Cover в начало.
3. друг за другом они следуют, чтобы обеспечить однозначность при чтении этих данных. если после секции BookInfo встретилась секция Text, то понятно, что секций с аннотацией и обложкой в файле нет, и дальше лопатить файл не стоит. кроме того, как-то принято во многих программах использовать более-менее фиксированную структуру данных.
4. традиционное написание hex-символов может и имеет смысл, чтобы отличать десятичные числа от шестнадцатиричных, но совершенно не помогает в обработке этих самых символов. если и так заранее известно, что эти четыре символа обозначают шестнадцатеричную запись номера картинки/якоря/секции, то нет никакого смысла вводить дополнительные опознавательные знаки.
убедил?
Отв: Формат NFB
Хотелось бы включить в спецификацию возможность отображения текста в таком вот виде:
1 А ...... . Б .......
......... С ........
2 ........ D ........
.......... . E ......
3 G...............
В первой позиции соят цифры (на них ссылаются в комментариях к тексту), привязанные к цепочке слов. Текст отображается со сдвигом вправо на несколько позиций. Такие форматироване текста часто встречается в текстах с многочисленными комментариями: библия, литпамятники, патенты. М.б. такой текст можно отобразить и в рамках существующей спецификации.
Поддерживаю введение в формат инлайновых картинок.
Отв: Формат NFB
киньте ссылку или пример такого текста в pdf/djvu, хоть посмотрю как оно реально выглядит.
пока протестую обеими руками, но в дальнейшем скорее всего сделаю.
смысл несомненно есть. тем более, что по сути конструктивно картинка в тексте не отличается от строчного форматера. как дойдет до реализации, будет видно.
Отв: Формат NFB
>киньте ссылку или пример такого текста в pdf/djvu, >хоть посмотрю как оно реально выглядит.
Вот пример:
http://rapidshare.com/files/190632982/__1050___1057___1045___1053___1054___1060___1054___1053___1058__-___1050___1048___1056___1054___1055.html
Посмотрите, кстати, как плохо подобные книжки выглядят в фб2:
http://lib.rus.ec/b/110630
Отв: Формат NFB
душераздирающее зрелище. но идея в целом понятна. добавлю в спецификацию.
хотелось бы уточнить:
1. нужна какая-либо навигация по этим номерам, или достаточно показывать их просто для интерьера?
2.
нумеруется начало конкретного предложения или номер может стоять где-то посередине напротив произвольного слова в строке? мне всё-таки показалось, что номер привязан к началу предложений.разобрался. номер может стоять перед любым конкретным словом, независимо от того, начало это абзаца, начало предложения, или середина. номер будет прилеплен к слову, следующему за ним, и отображаться напротив той же строки, в которой находится слово.
попутно обнаружил совершенно упущенное из виду - форматирование пьес. в смысле с указанием в начале строки имени действующего лица, и затем его реплики.
тоже добавлю в 11 релиз.
какие ещё есть варианты оформления, о которых я не знаю?
по поводу "инлайновых" картинок - либо картинка занимает по высоте одну строку, либо вставляем её между абзацами. ибо обтекание картинки текстом с двух сторон - это имхо будет уже перебор.
Отв: Формат NFB
Как-то вы так спонтанно добавляете разные свистелки и перделки... Не боитесь, что из формата получится монстрик на костылях?
Отв: Формат NFB
боюсь. но гораздо больше боюсь упустить что-нибудь важное.
добавить на этапе проектирования гораздо проще, чем потом обвешивать доделками (костылями?) и обеспечивать совместимость.
пока что всё, за исключением форматеров, таблиц и картинок, укладывается в простую и понятную структуру. добавление всяких оформительских изысков не сильно влияет на ту часть движка, которая отвечает за текстовые блоки.
возможно, на этапе реализации придётся поскрипеть мозгом над таблицами и плагинами, но в остальном всё достаточно тривиально.
Отв: Формат NFB
1. Не нужно их смысл - облегчение цитирования текста.
Насчет "инлайновых" картинок - предложенного вами вполне достаточно.
Жду с нетерпением программной реализации формата.
Отв: Формат NFB
Проект умер?
Отв: Формат NFB
не то что бы умер... так, впал в кому по причине недостатка свободного времени и наличия некоторых траблов на работе.
на май запланирован отпуск, надеюсь будет время позаниматься.
Отв: Формат NFB
Здорово.
Необходимое условие для продвижение nfb - это возможность чтения таких файлов на КПК и специализированных устройствах. Возможность экспорта в фб2 паллиатив,- геморрой с конвертацией, потеря доп. преимуществ нфб (формулы, форматирование и.т.д.).
Оптимально было бы сделать что-то вроде cr3 для nfb.
М.б. стоит взять его за основу (На http://sourceforge.net/projects/crengine доступны исходники, включая source package для Debian.
Проект можно строить с помощью automake/autoconf) и модифицировать для nfb?
Отв: Формат NFB
выложена дополненная и исправленная одиннадцатая (RC) редакция спецификации.
ведутся работы над приведением в понятный вид таблицы, описывающей соответствие тегов формата fb2 и сигнатур формата nfb. заодно прояснится степень прямой и обратной совместимости.
на более конструктивные действия времени пока не хватает. :(
Отв: Формат NFB
выложена двеннадцатая редакция спецификации и сравнительная таблица по взаимной совместимости fb2 и nfb.
в процессе работы над таблицей выправлены опечатки и неточности в спецификации, добавлены незначительные уточнения.
добавлены бантики в оформление таблиц. в принципе, осталась теоретическая возможность сделать несложную таблицу вручную, но с помощью редактора со специальными кнопочками/менюшками управлять рамками, выравниванием и оформлением явно будет на порядок проще. осталось только написать редактор :)
Страницы