Формат NFB
Опубликовано ср, 26/11/2008 - 07:23 пользователем СерыйМыш
начиная с 01.12.2008 ТЕМА НЕ МОДЕРИРУЕТСЯ изменено: 30.06.2009. 24.04.2009: работы временно приостановлены по субъективным причинам. возобновление планируется на середину мая этого года. формат разрабатывается как макcимально упрощенный альтернативный вариант хранения книг. работы над спецификацией формата практически закончены. конвертор пока существует только из fb2 в nfb, планируется полная поддержка импорта и экспорта для формата fb2. у кого есть конструктивные идеи/замечания/предложения - прошу высказаться.
|
|||||||
Комментарии
Отв: Формат NFB
Слово "FotmatID" является зарезервированным? Или очипяткой?
для конца строки я бы предложил
EOL ::= < CRs> < LF>
CRs ::= < empty> | < CR> | < CR> < CRs>
CR ::= ascii '\r'
LF ::= ascii '\n'
т.е. CR'ы просто игнорировать.
в эту схему уложится и "юниксный" и "досовский" концы строк.
метод проверенный и довольно удобный.
иначе - геморрой какой-либо категории пользователей гарантирован.
Дальше... Если уж хочется "простых заголовков" и нехочется XML, то чего бы не взять формат MIME Multipart?
Пусть даже со специфичной сигнатурой в первой строке?
В духе RFC 2822 (ну, понятно, со всеми RFC2045, RFC2046, RFC2048, RFC2049)? Там уже предусмотрено куча всего. И - простой, почти как RFC822 :D
А самое главное - парсеров к нему уже прорва написана.
Что нам не хватает? Внутренней "красивой" разметки - вот её и добавить. Ну и custom-заголовки на тему тех же жанров и т.п. Замечу, что про разделители, кодировки, форматы и т.п. думать уже будет ненадо.
Действительно, что такое книга? Это - письмо автора читателю!
Значит, формат письма - самый подходящий.
Получится MIME+WackoWiki = NFB :)
Отв: Формат NFB
проблема приближающегося перехода на fb3 как раз в том, что его кажущаяся (некоторым) простота выльется в невозможность простой реализации и отсутствие стороннего бесплатного софта. и все подсядут на коммерческие читалки, как это произошло с MSOffis-ом.
Отв: Формат NFB
Форматирование шрифта **полужирный** и --зачеркнутый-- кажутся мне не очень удачными. В текстах полно мест, где "--" используется вместо тире, и сдвоенные-строенные-смноженные звёздочки встречаются очень часто. Да и вообще форматирование шрифта всего лишь парами таких распространённых символов будет иметь проблемы, КМК... (снова подумал об HTML-ных тегах, вздохнул и заткнулся)
К стилям "Цитаты, эпиграфы и стихи" я бы предложил добавить что-то вроде стиля "Код" или "AsIs": текст внутри такого блока отображается без никакого парсинга спецсимволов, as is.
Непонятно почему нельзя иметь несколько картинок-обложек.
Из возни с fb2-книжками я вынес, что на практике довольно полезен блок "Programs-used", именно отдельный от "History". То же самое - блок "Version".
Из того же fb2 представляется довольно разумным разнесение информации о книге и информации о документе (этом файле) в две разные секции. Вообще секция "BookInfo" выглядит очень уж аскетично, подозреваю что в реальной работе библиотечных программ этих блоков будет недостаточно.
Ещё я не увидел в описании "Содержания", собираемого из "Заголовков" и, желательно, кликабельного. Правда, кликабельность сразу требует гиперссылок и анкоров, но этот механизм может быть полезен и не только для "Содержания"... (опять подумал об HTML, опять вздохнул и опять заткнулся)
Отв: Формат NFB
признаюсь прямо - методика с парными тегами очень просто ложится на парсинг с приведением к двухбайтовому целому числу, что работает значительно быстре, чем посимвольное сравнение двух строк или поиск подстроки. и именно из-за простоты реализации и высокой скорости она и была выбрана. трехсимвольные теги в начале строки также имеют своё обоснование - при проверке на наличие сигнатуры достаточно сначала проверить один первый байт, и если это "[", взять следующие два символа как двухбайтовое число и сделать выбор case. в общем, многие моменты появились именно из-за программерского подхода, ориентированного в первую очередь на простоту реализации. ещё хотел ключи в секции info сократить до трех символов, но получилось совсем коряво :) приходится дополнительно проверять наличие знака ":" в пятом байте.
теоретически можно было бы сделать все сигнатуры четырехсимвольными, но как-то не легла душа.
если набора ключей будет недостаточно - их можно легко добавить, и включить в очередную версию спецификации. там не зря указано - всё, что программа не знает, как обработать, она пропускает. редактор с такими ключами вообще должен обходиться просто - показывать как есть, и сохранять на то же место. а не как некоторые fb2-редакторы: не смог понять - выкинул.
версия будет добавлена как отдельный ключ, чтобы можно было в каталогизаторе сравнивать и показывать. главное, чтобы это поле, а также все остальные, были правильно заполнены. а то распознают люди одну и ту же книгу в разном переводе, не указывают переводчиков, прилепляют к файлу одну и ту же обложку, и каждый гордо ставит у себя версию 1.0. выясняй потом, куда кому чего. (реальный пример - Терри Пратчетт "Стража! Стража!")
Отв: Формат NFB
Кстати, тот же AUTH, расчитанный на ФИО...
Как в него вписать имя (вполне реального человека) Clifford James Arthur Gauntlet?
Отв: Формат NFB
Да, точно, я пропустил... Без раздельных ФИО невозможен поиск только по имени, чем я на Либрусеке, к примеру, постоянно пользуюсь.
Отв: Формат NFB
для примера возьмем: Остап Сулейман Берта Мария Бендер-бей.
-бей, конечно, перебор, но всё остальное ложится как надо: Бендер, Остап, Сулейман Берта Мария.
ну или Александр Сергеевич Пушкин = Пушкин, Александр, Сергеевич
первое слово до запятой всегда фамилия, второе слово - первое имя (first-name), а то, что дальше - отчество, оно же middle-name, оно же всё остальное. при выводе в титуле книги автор собирается по общим правилам - Имя Отчество Фамилия, или Фамилия Имя Отчество - кому как нравится.
Отв: Формат NFB
Бедняжка. Захотелось поиграть в модератора? Ну успехов в поднятии самооценки.
Отв: Формат NFB
ЛЮЮЮДИИИИ! АУУУУ!
1. я не пытаюсь никого лично оскорбить или принизить, удаляя посты, которые идут перпендикулярно обсуждаемой теме.
2. в самом начале я перечислил темы, которые мне не интересны, поэтому если кто-то непреодолимо хочет их помусолить - открывайте собственные ветки и развлекайтесь там. с меня хватило бодалки в ветке про fb3.
3. вряд ли кого-то радует, когда тред занимает 10 страниц, из которых полезной информации меньше трети. поэтому периодически буду объединять полезную инфу, собирать в отдельные посты, а разросшиеся хвосты вырезать.
4. повторяю первоначальную просьбу: если есть что сказать конструктивно - прошу высказаться. если сказать нечего, или тема вам неинтересна, или вы идейный противник и борец за возможность поспорить на пустом месте - никто не обидится, если вы промолчите.
Отв: Формат NFB
А, значит пост бы действительно удалён... ну что ж.
Неуважаемый господин СерыйМыш. На этом я прекращаю моё общение с Вами. Потому что, во-первых, зоологически не терплю модераторов, и во-вторых, не собираюсь ничего писать там, где любой мудак может написанное стереть.
Отв: Формат NFB
***
будь счастлив, уважаемый.
Отв: Формат NFB
Отв: Формат NFB
жаль, что большинство делает выводы на основании собственных фантазий.
получается как обычно - спросишь который час, а в ответ можно услышать всё, начиная от "купи часы" и до "любая попытка определить текущее время бесполезна, так как время продолжает движение вперед, и любой полученный результат сразу же становится неактуальным".
всего-то делов, что попросил не переливать из пустого в порожнее, так мало того, что не услышали, еще и обижаются, когда им повторно напомнили.
Отв: Формат NFB
А вот это по делу - удалишь?
Я лично в Сети 15 лет, и считаю, что умножение форматов (будь они хоть золотыми ;) - самое страшное, что можно сделать, чтобы загубить любое дело. Счастливых исключений очень мало, одно из них - fb2. Библиотекам и так не сладко, давайте еще войну форматов устроим :(. А по спецификации никаких особых преимуществ нового формата не увидел.
Отв: Формат NFB
Извините, но это глупость! Война форматов единственный источник прогресса.
По делу: мне кажется, стоит разделить спецификацию на две группы, обязательная часть и перспективная. В перспективную отправить все эти формулы и интегралы и приближенное к ним продвинутое форматирование. И реализовывать эту перспективную часть когда-нибудь совсем потом, когда отладится основная часть. Не только потому, что эта часть практически не востребована, но и потому, что вообще непонятно, имеет ли смысл использовать формулы (длинные формулы, а не mc квадрат) на малом экране и как это может выглядеть.
Отв: Формат NFB
Война форматов в хорошем смысле предполагает все же полный комплект инструментов и взаимную конвертируемость, чего в данном случае автор сугубо не обещает ;). Посмотрите на формат docx - сколько проблем у людей, которые им пользуются, точнее, сколько проблем они создают другим! Недаром тотчас появились конверторы в doc. Невольно возникает вопрос - зачем? (с форматом docx знаком, и вопрос - риторический, в смысле социальном, а не программном ;).
По делу - полностью согласен, вполне конструктивное предложение. Создать сначала ядро и предусмотреть расширение, лучше всего, если бы это были плагины, а не встроенные модули, хоть это куда труднее сделать достаточно изящно.
ЗЫ. Источник прогресса - не война, а совместимость и конвертируемость спектра форматов. И еще - альтернативное ПО.
Отв: Формат NFB
Отв: Формат NFB
Автор формата наверняка не обнимет необъятное :), поэтому часть совершенно необходимой работы сделают и другие, если формат покажет себя. А для этого его нужно таки внедрить в базовом варианте и пощупать юзабельность. Собрать всякие разные пожелания - дело тоже очень нужное и важное, но пытаться их все воплотить, тем более сразу, не стоит. Во-первых, не получится, во-вторых, отложит реализацию формата на неопределенный срок. Кроме того, сейчас нет ни одной читалки для КПК, которая реализовывала бы все средства формата fb2. Тоже самое с большей силой будет с fb3. Так зачем в формате эти средства? Плод чистого разума?
О войне. Мы априори говорим о войне открытых форматов. Это далеко не то, что война закрытых. Конвертируемость у таких форматов будет по определению, а совместимость - на совести авторов читалок.
На мой взгляд на первом этапе внедрения формата nfb сыграла бы комбинация:
1. читалка nfb для КПК (читалка для ПК в разы менее интересна и погоды не сделает никогда)
2. конвертор для fb2, txt, html -> nfb.
И уже можно было бы накапливать сторонников формата, обкатывать технологии, постепенно наращивать всякое ПО.
Мне формат нравится (по разным причинам), но гарантировать ему светлое будущее я бы не стал. Так что создавать полный комплекс ПО, чтобы потом обнаружить, что задумка не сыграла и все ушло в песок - не вполне разумно.
Отв: Формат NFB
я не агитирую никого прямо сегодня отказаться от fb2, rtf, html, doc, pdf, djvu и прочих ТеХов в пользу нового формата.
я всего лишь надеюсь, что когда будет создан "еще один" формат, в нем будут учтены все плюсы и все минусы, которые народ обнаружил в имеющихся форматах. пусть даже это будет не nfb, а, скажем, fb3. только мне почему-то кажется, что при разработке fb3 учитывается мнение не тех, кто будет пользоваться, а тех, кто на нём будет зарабатывать.
согласен, особых видимых преимуществ у нового формата нет. но в нём учтены некоторые моменты, которые в дальнейшем позволят не упереться в ограничения реализации. самая основная идея - это упрощение. а упрощение потянет за собой простоту программной реализации. многие жалуются, что нет читалок под линух/симбиан. так их и не будет до тех пор, пока сложность реализации превышает возможности имеющихся программных средств и способности программистов.
Отв: Формат NFB
Вот это уже конструктивно и по делу тоже. При таком подходе и я не против :). А то развели тут драчку:
Отв: Формат NFB
Отв: Формат NFB
Помнится, некий пост в теме fb3!!! был злостным оффтопом. Жаль, что в свое время его не удалили...
Отв: Формат NFB
***
Отв: Формат NFB
Я - не вы, "хозяин треда" - не барин, обсуждение - не монолог. Удачи.
Отв: Формат NFB
ПОчитал написанное и здесь и в указанном посте про фб3. Значительно поднял свою эрудицию и выучил новое слово "парсить". Спасибо!
Теперь к делу:
1) Как быть с использованием различных знаков, например, греческого алфавита, арабского, иврита, а также всяких испанских нь, кириллических ль, нь, французского и португальского ç, умляутных и прочих диакритических знаков существующих в юникоде?
2) Почему нельзя сделать 2 версии читалки - для компа и для кпк. В таком случае прога для компа могла бы сохранять полюбившиеся способности кулридера и др. программ в частности в размере шрифта.
3) Не кажется ли разумным создание универсальной читалки, которая понимала бы все существующие кпк-ашные форматы без преобрахования, потому что искать под каждый формат свою читалку неудобно...
Отв: Формат NFB
вообще мы тут обсуждаем не программы для просмотра, а формат, который бы позволил выжать максимум из электронной книги.
Отв: Формат NFB
Сделать ввод формул как в tex:
Вместо @@math|\integral@@ - $\integral_0^1 e^x dx $,
^^надстрочный индекс^^ - $a_i$, \/подстрочный индекс\/ - $a^j$. Знак $ изображается \$.
Греческие буквы тоже как в тех : $\beta$.
На первом этапе вызываемый форматер (плагин) может рисовывать только простейшие формулы, теховская нотация наглядна и понятна в своем исходном виде.
Отв: Формат NFB
реализовывать поддержку всех команд ТеХа внутри книжного формата - это перебор, а вот в виде плагина - вполне.
при этом использовать безусловно плагин теха для вывода надстрочных/подстрочных индексов - явно лишнее.
две встроенные команды - "^^" и "\/" против плагина полюбому побеждают, но с изменениями.
чтобы избежать лишних повторов, команды будут действовать на часть строки до пробела.
таким образом, пифагор a2 + b2 = c2 будет выглядеть так: a^^2 + b^^2 = c^^2 , или так: $$TeX|a^2 + b^2 = c^2$$
чтобы принудительно сбросить атрибуты шрифта будет использоваться команда "~~",
потому как x=y^^2+c это x=y2+c, а x=y^^2~~+c это x=y2+c.
аналогично и с подстрочным индексом.
а вот степень в степени - это уже задача для плагина. кто бы ещё взялся его написать?
Отв: Формат NFB
Для блоков цитата/эпиграф/стихи предлагаю добавить необязательные заголовок и подпись - в таком например виде:
[!]
Быть или не быть...
[!]Шекспир, Гамлет
[&]Узник
Сижу за решеткой в темнице сырой
[&]1822
Подпись позволит не потерять тег text-author из fb2, да и вообще, вполне стоящий выделения структурный элемент. Заголовок большей частью полезен для стихов, в остальные блоки - для единообразия.
Отв: Формат NFB
очевидное решение, но сам не додумался. включаю в спецификацию.
Отв: Формат NFB
1. Очень хотелось бы увидеть читалку.
2. По моему скромному мнению, до тех пор, пока этот формат не будет читаться хотя бы на winmobile-КПК, популярность его будет не очень большой.
3. Конечно, хотелось бы видеть версии читалки и для более других платформ. Например, для виндовых и симбиановых смартфонов, для настольного линукса, для lbook. Дело в том, что в на настольной виндовой машине и так можно прочитать что угодно — от сколь угодно сложного HTML и до дежавю. Хороший, «лёгкий», переносимый формат хочется иметь именно для карманных устройств.
Отв: Формат NFB
СерыйМыш писал в теме fb3!!! :
Хотелось бы увидеть тоже самое в отношении портирования на другие платформы GDIPlus.dll (через которую производится вся отрисовка в разрекламированной маленькой читалке).
Отв: Формат NFB
портирование GDI+ на другие платформы особого смысла не имеет. движок сделан так, что для вывода можно использовать те средства, которые предоставлены платформой, с минимальными изменениями в коде.
единственный имеющийся минус - реализовано всё на паскале. поэтому могут возникнуть проблемы с поиском совместимых паскаль-компиляторов для конкретных платформ.
P.S. переводить проект на си пока не планируется.
Отв: Формат NFB
Lazarus
Отв: Формат NFB
Зря. Всё равно придётся.
Отв: Формат NFB
Если уж припёрло портабельный гуй поюзать, то Qt вам в руки...
wxW - вроде, недостаточно портабелен.
а больше как-то ничего в голову и не приходит.
а мечтать, что все кинутся портировать проприетарное закрытое угробище GDIplus... Ну, мечтайте. Или получите просто ещё одну форточную читалку, коих и так уже дох..я. Вот недавно уже требовали формат айсбукридера "поддержать".
Отв: Формат NFB
Формат это конечно хорошо. но уж больно много времени нужно на появление более ли менее нормальных программ редакторов и вьюверов, может имеет смысл, попробовать с другой стороны, есть достаточно удобный openoffice редактор почему бы не сделать совместимый с ним формат, учитывающий наши требования. Назвать к примеру ofb - модифицировать odt, добавить дескрипшен, еще что-то, добавить соответствующее расширение openoffice для его чтения редактирования.
Отв: Формат NFB
Выложена новая редакция спецификации.
http://lib.rus.ec/sites/default/files/NFB%20Specification_1.0.6.txt
Спецификация практически готова к переводу в стадию "прототип" и внутреннему тестированию. тестовые версии читалки и конвертера будут выложены после их доработки.
Отв: Формат NFB
jno писал:
Отв: Формат NFB
а вот MSXML - это реально дополнительная длл, потому как например FBEditor отказывается работать при ее отсутствии, а по дефолту она в системной поставке не идёт.
Отв: Формат NFB
СерыйМыш писал:
СерыйМыш писал:
Относительно нового формата У меня возникло 3 вопроса. Вопрос 1: Архивировать или не архивировать? Считаю что архивировать, потому что: Большинство пользователей хранят книги в архивированном виде. Хранить текстовый файл неупакованным - очевидное расточительство. Большинство читалок, которые я видел, в качестве одной из фич указывают прозрачную работу с архивами zip. Реализации zip существуют практически под любую платформу (www.sourceforge.net).
Вопрос 2: Кодировать картинки в base64? Считаю, что нет, потому что: Картинки изначально существуют в бинарном виде. Сохранение в формате base64 вызвано необходимостью впихнуть бинарные данные в текстовый файл, чтобы вся книга хранилась в одном файле. Если использовать архивирование (см. выше), необходимость в этом отпадает. Отрисовка картинок производится портабельными библиотеками работы с изображениями, непосредственно хранящихся в архиве в бинарном виде без сжатия (stored) (www.sourceforge.net). Использовать base64 опять же расточительно и перед выводом требует раскодировки.
Вопрос 3: XML or not XML? (Подражание Шекспиру) Вот тут сложнее. Сам формат XML мне тоже не шибко нравится. Но книга по своей структуре хорошо ложится в древовидную структуру, хорошо разбираемую XML. Поэтому думаю, что оглавление книги должно содержаться в отдельном файле в виде разметки XML (или XML-подобной поддерживающей древовидную структуру) с указателями на смещения различных глав и секций в текстовом файле и указателями на смещения картинок в файле книги. А вот конкретно текст книги хранить отдельно. Идея СерыйМыш отделить форматирование текста от XML мне нравится. Даже очень нравится! Мне кажется, что такое сочетание будет удачным. Не нужно проходить по всему текстовому файлу, чтобы получить оглавление книги и указатели на картинки. Произвел разбор оглавления, получил смещение в текстовом файле на нужное место в книге, а дальше вывод по той схеме, что предложил СерыйМыш. К тому же, хранение текста отдельно от оглавления и картинок (с использованием zip -архива), позволяют при необходимости разбить текстовый файл на несколько частей (в случае если он слишком большой – к примеру, какая-нибудь энциклопедия или книга с большим содержанием картинок) и работать с частью файла.
Отв: Формат NFB
!!! Осторожно, очень много букв! :)
вопрос не в этом. архивировать однозначно. вопрос в другом - архивировать книги по одной, чтобы в архиве можно было разместить файлы с зарезервированными именами content.xml, cover.jpg и т.п. или архивировать библиотеку целиком. тогда в одном архиве будет лежать много файлов, и наступает filename hell - то есть обязательно надо, чтобы все файлы назывались по-разному, или хотя бы лежали в разных подкаталогах при архивировании с путями.
откровенно говоря, идея "всё в одном файле" как раз сделана с предпосылкой к созданию архива-библиотеки.
вопрос непринципиальный. кодирование сделано исключительно для обеспечения "ремонтопригодности" текстового файла, возможности при острой необходимости открыть его обычным редактором типа "блокнот", и не испортить при сохранении. при архивировании base64 картинка снова возвращается практически к изначальному размеру.
расточительно, но не настолько, как кажется. потоковое чтение по три символа, сдвиговые преобразования и запись в буфер уже по два символа - не такой страшный перегруз, как кажется. всё уже давно обкатано и работает. та же разархивация в программном плане сложнее на несколько порядков, и требует гораздо больше памяти и производительности.
*вздохнул горестно
в формате fb3 грибов пошел по сходному принципу, но оставил текстовые секции в xml-обвязке. для сборки индексной таблицы в принципе не обязательна древовидная структура, книга по большей части всё-таки линейный материал. таблицу смещений можно составить заранее, и даже записать хоть в текстовый файл, хоть в бинарный, но возникает одна сложность - при редактировании/правке необходимо заново вычислять смещения, и синхронно их заменять в индексном файле. опять же, незначительное расхождение между адресом в индексе и адресом в файле может в момент уронить и читалку и редактор.
однократный пробег по файлу с поиском нескольких вариантов тегов, и составление временного индексного файла гарантированно стабильнее.
я принципиально старался организовать формат так, чтобы исключить из использования xml. сделал это для того, чтобы программа могла обойтись без xml-парсера вообще. соответственно: нет функции - нет лишнего кода, нет потребности в лишней памяти и в лишних тактах процессора.
опять же см. выше. если файл книги - архив, то теряется смысл в библиотеке-архиве. иначе получаем архив в архиве, и лишние накладные расходы. хранение в библиотеке методом store (без компресси) практически не роляет. разбивка файла на части, и укладывание этих частей в архивированный контейнер, с последующей упаковкой его в бибилиотеку принципиально никак не отличается от хранения всего файла одним куском, так как для извлечения одного фрагмента всё равно сначала надо извлечь из бибилиотеки весь контейнер. так не всё ли равно, один там непрерывный файл, или много отдельных кусков. если парсер блочный (а xml именно блочный), то для разбора файла его приходится читать весь. или как минимум участок, ограниченный парными тегами. а если парсер потоковый, то он получает на вход _любой_ фрагмент файла, и может сразу его обработать, что позволяет начать чтение с любого места произвольно.
короче, вопрос очень спорный и замороченный. надо придумывать какое-то простое решение. вплоть до попытки деления архивированного потока на секции, индексирования этих секций и организации произвольного доступа по индексу.
NB! вопрос совершенно не теоретический, и может быть решён только проработкой на прототипе. заявления некоторых товарищей вида "мне кажется, что программистам будет проще" во внимание не принимаем, так как "кажется" - это одно, а "пробовал сделать и
заебался до полусмертиизмучился весь" - совершенно другое.вобщем темы на сегодня такие:
1. довести до ума управление разметкой на основе "непарных" тегов - так, как сейчас описано в спецификации. это позволит однозначно упростить парсинг и форматирование. плюс "ремонтопригодность" - при случайном включении в текст управляющих комбинаций произойдет только лишнее "переключение" форматирования, и ничего более, структура всего файла не пострадает.
2. разобраться с картинками. кстати, упаковка jpg/png в архив с попыткой сжатия абсолютно бессмыслена - не упаковываются они по своей природе. хранение картинки в текстовом файле в base64 позволяет не заморачиваться, и архивировать весь файл целиком. текстовая часть сожмется лучше, картинки сожмутся хуже, но всё равно не менее чем на 20% - такова суть base64. опять же отпадет заморочка с "архивом в архиве".
3. разобраться с необходимостью и способом построения индекса. на этот счёт была мысль такая - читалка/библиотекарь при первом открытии или при импорте файла создаёт для себя _отдельный_ индексный файл (или общую индексную таблицу для всей библиотеки), и пользуется им. там же рядом читалка держит свои закладки, пометки и прочие удобства. при экспорте книги наружу передаётся только информативная часть - собственно текст с картинками. при острой необходимости, можно сделать экспорт закладок/пометок/правок, и таскать его в паре с основным файлом, но это принципиально вредно, потому как отдельные файлы имеют обыкновение распараллеливаться и теряться.
4. разобраться с "портабельностью". мнение на этот счёт однозначное - для платформ со сходными характеристиками можно делать "переносимый" код, и сохранять единство конструкции. для платформ WinMobile/Symbian/Android нужна своя ветка программы, учитывающая ограничения размера экрана и особенности управления - стилусом/пальцами/кнопками. внутреннее устройство программы при этом может совершенно не отличаться, но вот визуальная часть должна быть у каждого своя. для устройств типа e-book - третий вариант интерфейса, а может и не только интерфейса.
5. ?????
6. PROFIT (c) :)
Отв: Формат NFB
После FormatID добавить секцию стиль, указывающий читалке способ отображения документа. Что-то вроде этого:
documentstyle[12pt,a4,landscape]{Poerty}.
Ну и соответвенно убрать ключ CONT.
Отв: Формат NFB
про стили думал много, долго и разнообразно.
и пришел к такому выводу:
ширина сраницы и размер используемого шрифта при отображении книги относится к области личных предпочтений и аппаратных ограничений. поэтому задавать в книге, что она должна отображаться в размер А4 альбомной ориентации 12-м пунктом - по меньшей мере некорректно. то, что имеет смысл для вывода на экран компа или на бумагу, совершенно теряет смысл при отображении на экране смартфона.
а ключ CONTent (содержимое (англ.)) - вполне подходит для общего управления обработкой в зависимости от содержимого документа.
о стилях отображения вообще: было бы идеально конечно задавать одной командой правила вёрстки заголовков, абзацев и прочих частей документа, но всё это опять же будет бесполезно при попытке читать такую книгу на устройстве с маленьким экраном.
надо думать, как выкручиваться.
Отв: Формат NFB
Согласен, но ведь читалка знает на каком устройстве оно установлена и соответвенно может адаптировать, упращать указанный стиль к заданному устройству: 12pt преобразуется во что-то подходящее для смартфона и.т.р. А documentstyle определяет оптимальный стиль, который может быть отображен на большем экране. А устройства для чтения с большими (>=A3) экранами появятся очень скоро и nfb должен использовать их возможности.
Отв: Формат NFB
Предлагаю рассмотреть следующий вариант:
По-моему архивирование библиотеки целиком идея не очень удачная. Если библиотека будет содержать большое количество книг, ее обслуживание (добавление, удаление и т.д.) превратится в настоящий геморрой.
Архивирование книги по одной на архив, на мой взгляд, оптимальный вариант.
Структура архива могла бы быть такой:
-- content.nbf <- сжато (deflated)
-- text.nbf <- сжато (deflated)
--0000.jpg <- без сжатия (stored)
--0001.png <- без сжатия (stored)
--и т.д.
Содержание файла text.nbf: Cекция "Text"
Содержание файла content.nbf :
Секция "FormatID"
Секция "BookInfo"
Секция "Annotation"
В секцию BookInfo добавить тег MaxImgIdx (максимальный индекс картинки) – для валидации.
Добавить секцию "Content": (к примеру)
[c] Мир и война = 000000 // заголовок=смещение в текстовом файле
[c] Часть 1 = 00003F
[c] Глава 1 = 00005E
[.] // конец главы 1
[c] Глава 2 = 001F5
[.] // конец главы 2
[.] // конец части1
[c] Часть 2 = 00055F
[c] Глава 3 = 00155F
[.]// конец главы 3
[c] Глава 4 = 00355F
[.]// конец главы 4
[.] // конец части 2
[.] // конец секции "Content"
Проверка корректности смещений в тексте производится сравнением максимального смещения и размера распакованного файла text.nbf из заголовка zip-архива. Не факт что перейдешь в нужное место, но читалка не упадет.
При чтении распаковываешь text.nbf, переходишь на нужную главу по смещению – и далее потоковый вывод.
Встречается картинка – из оглавления zip файла берем смещение в архиве на соответствующий файл изображения, а он хранится без сжатия (zip для jpg и png практически не дает выигрыша), считываешь в память – и далее вывод стандартными функциями.
Плюс к этому программа-библиотекарь может работать только с файлом content.nbf.
Отв: Формат NFB
сегодня внимательно изучал "конкурирующий продукт" - ALReader.
всё вроде ничего, но уж слишком перегружен интерфейс. и клики по углам страниц работают как-то неадекватно - при быстром нажатии более двух раз переходит фиг знает куда.
но больше всего выбесило то, что количество предполагаемых страниц для него при любом размере шрифта всегда одинаковое. и при мелком шрифте номер текущей страницы перепрыгивает через две-три, хотя на экране всё ровно.
вот я и думаю, нужен ли реальный показатель страниц? или достаточно достаточно грубой полосы текущего положения и величины в процентах?
и вопрос этот восходит к следующему моменту реализации - если обрабатывать весь файл целиком, то можно посчитать совершенно точно количество строк и страниц. а если обрабатывать посекционно, то как раз и получаются "условные страницы", которые не совпадают с действительностью.
на аппарате с ограниченной памятью и быстродействием вполне оправдана посекционная обработка. на обычном компе, пусть и не самом навороченном, полный обсчёт книги весом в два мегабайта сейчас занимает менее одной секунды. а учитывая, что обсчёт выполняется в фоновом треде, человек даже не заметит, что маркер страницы появился с некоторым опозданием. главное, что с момента старта до момента отображения текста на экране проходит менее 0.2 секунды.
всё это я пишу к тому, что в настоящее время для программы под Win32 посекционная обработка текста не очень оправдана.
по большому счёту, библиотекарь на несколько тысяч книг - это скорее всё-таки прога для персонарки, а не для смартфона. и если время реакции у нее будет приемлемое, то в принципе пофиг, как у нее устроена база. проблемы обычно начинаются в тот момент, когда что-то сбойнуло, и нужно отремонтиовать. в этом плане отдельные файлы надёжнее, чем монолитный архив. в общем, есть над чем подумать.
в принципе лично к нему у меня претензий нет, но как-то не хотелось бы обезьянничать и делать "те же файлы, только в профиль".
файл индекса должен позволять получить практически мгновенный доступ к произвольному участку текста. в идеале индексироваться должен не текст, а уже сжатый файл. в принципе, при использовании блочной архивации можно значительно увеличить скорость за счёт того, что распаковываться будет не весь файл с текстом, а небольшой фрагмент. тут нужно опять же исходить из того, что важнее - минимальные затраты памяти, или скорость доступа, потому как непосредственное чтение из файла и распаковка секций "на лету" медленнее, чем однократная распаковка в буфер.
мысль по поводу бинарного контейнера с нестандартным внутренним форматом я уже обсуждал, и подробно рассказывал, почему это плохо. хоть это и самый эффективный вариант, сложность в обработке убьет на корню все преимущества. понимать этот формат будут от силы несколько человек, а написать для него поддержку вообще может не найтись желающих.
при обдумывании всего этого у меня возникают следующие противоречия:
1. если распаковка файла делается целиком, и результат остаётся в памяти, то зачем для него заранее делать индекс? доступ к файлу - медленно, доступ в памяти - гораздо быстрее. и индекс строится в один проход.
2. если данные уже в памяти, то зачем каждый раз выполнять парсинг отдельных участков перед выводом на экран? гораздо проще один раз преобразовать данные в разобранную структуру, и в дальнейшем использовать её, а память буфера освободить.
3. есть ли смысл каждый раз читаль картинку из файла перед выводом ее на экран, или достаточно один раз прочитать данные в буфер, а распаковку jpeg-bmp делать перед самым выводом на экран?
подозреваю, что для программ под Win32 и WinMobile ответы на эти вопросы будут разными.
Содержание файла text.nbf: Cекция "Text"
Отв: Формат NFB
А если посмотреть CoolReader3? Минималистский интерфейс, динамические страницы, стили, таблицы, мультиплатформенный движок ... проект в развитии. Мне он почему-то больше импонирует чем AlReader.
Отв: Формат NFB
CoolReader разве на КПК работает? И весит он сколько?
Отв: Формат NFB
Распакованная win-версия - 2,5 М
Страницы