Формат 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.

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

Комментарии

Опубликовано ср, 26/11/2008 - 08:44 пользователем jno

Слово "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 :)

Опубликовано чт, 27/11/2008 - 09:19 пользователем СерыйМыш

jno написал:
Слово "FotmatID" является зарезервированным? Или очипяткой?
очипяткой, растиражированной методом copy-paste. слово это кстати вообще само по себе, оно в качестве тега не используется :)

jno написал:
Дальше... Если уж хочется "простых заголовков" и нехочется XML, то чего бы не взять формат MIME Multipart?
Пусть даже со специфичной сигнатурой в первой строке?
В духе RFC 2822 (ну, понятно, со всеми RFC2045, RFC2046, RFC2048, RFC2049)? Там уже предусмотрено куча всего. И - простой, почти как RFC822 :D
почитал я эти RFC. не понравилось.

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

Опубликовано ср, 26/11/2008 - 09:43 пользователем pkn

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

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

Форматирование шрифта **полужирный** и --зачеркнутый-- кажутся мне не очень удачными. В текстах полно мест, где "--" используется вместо тире, и сдвоенные-строенные-смноженные звёздочки встречаются очень часто. Да и вообще форматирование шрифта всего лишь парами таких распространённых символов будет иметь проблемы, КМК... (снова подумал об HTML-ных тегах, вздохнул и заткнулся)

К стилям "Цитаты, эпиграфы и стихи" я бы предложил добавить что-то вроде стиля "Код" или "AsIs": текст внутри такого блока отображается без никакого парсинга спецсимволов, as is.

Непонятно почему нельзя иметь несколько картинок-обложек.

Из возни с fb2-книжками я вынес, что на практике довольно полезен блок "Programs-used", именно отдельный от "History". То же самое - блок "Version".

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

Ещё я не увидел в описании "Содержания", собираемого из "Заголовков" и, желательно, кликабельного. Правда, кликабельность сразу требует гиперссылок и анкоров, но этот механизм может быть полезен и не только для "Содержания"... (опять подумал об HTML, опять вздохнул и опять заткнулся)

Опубликовано чт, 27/11/2008 - 10:21 пользователем СерыйМыш

pkn написал:
Форматирование шрифта **полужирный** и --зачеркнутый-- кажутся мне не очень удачными. В текстах полно мест, где "--" используется вместо тире, и сдвоенные-строенные-смноженные звёздочки встречаются очень часто. Да и вообще форматирование шрифта всего лишь парами таких распространённых символов будет иметь проблемы, КМК... (снова подумал об HTML-ных тегах, вздохнул и заткнулся)
откровенно говоря, мне тоже не очень нравится перспектива получить в чистом исходном тексте случайно попавшие туда символы форматирования, но скажу сразу: двойные дефисы вместо тире и тройные звездочки, не разделенные пробелами - это нарушение общепринятых типографских правил. и если мы хотим, чтобы книги у нас были максимально качественные, то надо их при сборке приводить в порядок. заменять где надо дефисы на настоящие тире (n-dash или m-dash), звездочки в конце главы рисовать как принято - через одинарный пробел. ну и многое другое. в любом случае, работа по сборке и вычитке книги требует определенных усилий, и направлена она в первую очередь на приведение материала в максимально качественный вид.

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

pkn написал:
К стилям "Цитаты, эпиграфы и стихи" я бы предложил добавить что-то вроде стиля "Код" или "AsIs": текст внутри такого блока отображается без никакого парсинга спецсимволов, as is.
есть смысл. добавим.

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

pkn написал:
Из возни с fb2-книжками я вынес, что на практике довольно полезен блок "Programs-used", именно отдельный от "History". То же самое - блок "Version".
Из того же fb2 представляется довольно разумным разнесение информации о книге и информации о документе (этом файле) в две разные секции. Вообще секция "BookInfo" выглядит очень уж аскетично, подозреваю что в реальной работе библиотечных программ этих блоков будет недостаточно.
как правильно подобрано слово - возня. как раз из-за того, что для fb2 нет простого и удобного редактора, и результат работы разных редакторов может отличаться, приходится придумывать поля типа Programs-used. не хотите писать их в "хистори" - запишите в "инфо". в любом случае эта информация там нужна исключительно в рекламных/антирекламных целях, чтобы было ясно, чем это так удалось испохабить книгу.
если набора ключей будет недостаточно - их можно легко добавить, и включить в очередную версию спецификации. там не зря указано - всё, что программа не знает, как обработать, она пропускает. редактор с такими ключами вообще должен обходиться просто - показывать как есть, и сохранять на то же место. а не как некоторые fb2-редакторы: не смог понять - выкинул.
версия будет добавлена как отдельный ключ, чтобы можно было в каталогизаторе сравнивать и показывать. главное, чтобы это поле, а также все остальные, были правильно заполнены. а то распознают люди одну и ту же книгу в разном переводе, не указывают переводчиков, прилепляют к файлу одну и ту же обложку, и каждый гордо ставит у себя версию 1.0. выясняй потом, куда кому чего. (реальный пример - Терри Пратчетт "Стража! Стража!")

pkn написал:
Ещё я не увидел в описании "Содержания", собираемого из "Заголовков" и, желательно, кликабельного. Правда, кликабельность сразу требует гиперссылок и анкоров, но этот механизм может быть полезен и не только для "Содержания"... (опять подумал об HTML, опять вздохнул и опять заткнулся)
содержание должна собирать читалка, и она это уже умеет. доделаю "кликабельность" - выложу очередную демку для ознакомления. а вот якоря и ссылки однозначно пришлось добавить. потому как бывает в книгах такая ерундень, как алфавитный указатель, и её без якорей и ссылок сделать никак. да и вообще - электронная книга тем и удобна, что ее не надо листать - ткнул мышой, и оказался где надо.

Опубликовано ср, 26/11/2008 - 10:13 пользователем jno

Кстати, тот же AUTH, расчитанный на ФИО...
Как в него вписать имя (вполне реального человека) Clifford James Arthur Gauntlet?

Опубликовано ср, 26/11/2008 - 10:18 пользователем pkn

jno написал:
Кстати, тот же AUTH, расчитанный на ФИО...
Как в него вписать имя (вполне реального человека) Clifford James Arthur Gauntlet?

Да, точно, я пропустил... Без раздельных ФИО невозможен поиск только по имени, чем я на Либрусеке, к примеру, постоянно пользуюсь.

Опубликовано чт, 27/11/2008 - 10:16 пользователем СерыйМыш

jno написал:
Кстати, тот же AUTH, расчитанный на ФИО...
Как в него вписать имя (вполне реального человека) Clifford James Arthur Gauntlet?
к моему стыду, понятия не имею, какое из этих слов фамилия, а какое первое имя, а так бы написал :)
для примера возьмем: Остап Сулейман Берта Мария Бендер-бей.
-бей, конечно, перебор, но всё остальное ложится как надо: Бендер, Остап, Сулейман Берта Мария.
ну или Александр Сергеевич Пушкин = Пушкин, Александр, Сергеевич
первое слово до запятой всегда фамилия, второе слово - первое имя (first-name), а то, что дальше - отчество, оно же middle-name, оно же всё остальное. при выводе в титуле книги автор собирается по общим правилам - Имя Отчество Фамилия, или Фамилия Имя Отчество - кому как нравится.

Опубликовано чт, 27/11/2008 - 17:20 пользователем Bullfear

Цитата:
2. пост Bullfear от November 27th, 2008 удален за использование ключевой фразы "Смысла переходить на новый формат нет,..."

Бедняжка. Захотелось поиграть в модератора? Ну успехов в поднятии самооценки.

Опубликовано пт, 28/11/2008 - 10:58 пользователем СерыйМыш

Bullfear написал:
Цитата:
2. пост Bullfear от November 27th, 2008 удален за использование ключевой фразы "Смысла переходить на новый формат нет,..."

Бедняжка. Захотелось поиграть в модератора? Ну успехов в поднятии самооценки.

ЛЮЮЮДИИИИ! АУУУУ!
1. я не пытаюсь никого лично оскорбить или принизить, удаляя посты, которые идут перпендикулярно обсуждаемой теме.
2. в самом начале я перечислил темы, которые мне не интересны, поэтому если кто-то непреодолимо хочет их помусолить - открывайте собственные ветки и развлекайтесь там. с меня хватило бодалки в ветке про fb3.
3. вряд ли кого-то радует, когда тред занимает 10 страниц, из которых полезной информации меньше трети. поэтому периодически буду объединять полезную инфу, собирать в отдельные посты, а разросшиеся хвосты вырезать.
4. повторяю первоначальную просьбу: если есть что сказать конструктивно - прошу высказаться. если сказать нечего, или тема вам неинтересна, или вы идейный противник и борец за возможность поспорить на пустом месте - никто не обидится, если вы промолчите.

Опубликовано пт, 28/11/2008 - 11:00 пользователем pkn

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

...удаляя посты, которые идут перпендикулярно обсуждаемой теме.

А, значит пост бы действительно удалён... ну что ж.

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

Опубликовано пт, 28/11/2008 - 11:39 пользователем СерыйМыш

***

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

будь счастлив, уважаемый.

Опубликовано вс, 30/11/2008 - 11:21 пользователем computers

Цитата:
будь счастлив, уважаемый
Будь счастлив и ты, игрок в крутого программера ;). Кому ты нужен, если не хочешь / не можешь слушать любое мнение других? А свое ты уже высказал: новый формат будет, - и зачем же тебе мы тогда нужны? За тебя твою работу делать? Или второго грибузера растить? Расти сам. И удаляй чужие посты. Этот смотри не забудь удалить! ;D

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

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

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

Опубликовано вс, 30/11/2008 - 21:29 пользователем computers

А вот это по делу - удалишь?
Я лично в Сети 15 лет, и считаю, что умножение форматов (будь они хоть золотыми ;) - самое страшное, что можно сделать, чтобы загубить любое дело. Счастливых исключений очень мало, одно из них - fb2. Библиотекам и так не сладко, давайте еще войну форматов устроим :(. А по спецификации никаких особых преимуществ нового формата не увидел.

Опубликовано вс, 30/11/2008 - 22:18 пользователем oldvagrant

computers написал:
Я лично в Сети 15 лет, и считаю, что умножение форматов (будь они хоть золотыми ;) - самое страшное, что можно сделать, чтобы загубить любое дело.

Извините, но это глупость! Война форматов единственный источник прогресса.

По делу: мне кажется, стоит разделить спецификацию на две группы, обязательная часть и перспективная. В перспективную отправить все эти формулы и интегралы и приближенное к ним продвинутое форматирование. И реализовывать эту перспективную часть когда-нибудь совсем потом, когда отладится основная часть. Не только потому, что эта часть практически не востребована, но и потому, что вообще непонятно, имеет ли смысл использовать формулы (длинные формулы, а не mc квадрат) на малом экране и как это может выглядеть.

Опубликовано пн, 01/12/2008 - 01:28 пользователем computers

Война форматов в хорошем смысле предполагает все же полный комплект инструментов и взаимную конвертируемость, чего в данном случае автор сугубо не обещает ;). Посмотрите на формат docx - сколько проблем у людей, которые им пользуются, точнее, сколько проблем они создают другим! Недаром тотчас появились конверторы в doc. Невольно возникает вопрос - зачем? (с форматом docx знаком, и вопрос - риторический, в смысле социальном, а не программном ;).
По делу - полностью согласен, вполне конструктивное предложение. Создать сначала ядро и предусмотреть расширение, лучше всего, если бы это были плагины, а не встроенные модули, хоть это куда труднее сделать достаточно изящно.
ЗЫ. Источник прогресса - не война, а совместимость и конвертируемость спектра форматов. И еще - альтернативное ПО.

Опубликовано пн, 01/12/2008 - 01:49 пользователем СерыйМыш

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

Опубликовано пн, 01/12/2008 - 19:47 пользователем oldvagrant

computers написал:
ЗЫ. Источник прогресса - не война, а совместимость и конвертируемость спектра форматов. И еще - альтернативное ПО.

Автор формата наверняка не обнимет необъятное :), поэтому часть совершенно необходимой работы сделают и другие, если формат покажет себя. А для этого его нужно таки внедрить в базовом варианте и пощупать юзабельность. Собрать всякие разные пожелания - дело тоже очень нужное и важное, но пытаться их все воплотить, тем более сразу, не стоит. Во-первых, не получится, во-вторых, отложит реализацию формата на неопределенный срок. Кроме того, сейчас нет ни одной читалки для КПК, которая реализовывала бы все средства формата fb2. Тоже самое с большей силой будет с fb3. Так зачем в формате эти средства? Плод чистого разума?

О войне. Мы априори говорим о войне открытых форматов. Это далеко не то, что война закрытых. Конвертируемость у таких форматов будет по определению, а совместимость - на совести авторов читалок.

На мой взгляд на первом этапе внедрения формата nfb сыграла бы комбинация:
1. читалка nfb для КПК (читалка для ПК в разы менее интересна и погоды не сделает никогда)
2. конвертор для fb2, txt, html -> nfb.
И уже можно было бы накапливать сторонников формата, обкатывать технологии, постепенно наращивать всякое ПО.
Мне формат нравится (по разным причинам), но гарантировать ему светлое будущее я бы не стал. Так что создавать полный комплекс ПО, чтобы потом обнаружить, что задумка не сыграла и все ушло в песок - не вполне разумно.

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

computers написал:
А вот это по делу - удалишь?
Я лично в Сети 15 лет,
не поверишь, я примерно так же. еще фидо помню. :)
computers написал:
и считаю, что умножение форматов (будь они хоть золотыми ;) - самое страшное, что можно сделать, чтобы загубить любое дело. Счастливых исключений очень мало, одно из них - fb2.
я не предлагаю множить форматы. я пытаюсь стимулировать людей на креативное мышление и прогресс. потому как единственный на сегодня приемлемый формат, имеющий специальную заточку для каталогизации и хранения книг - это fb2. но он имеет ряд существенных ограничений, о которых люди постоянно гундят, но при этом никто ничего не пытается изменить.

я не агитирую никого прямо сегодня отказаться от fb2, rtf, html, doc, pdf, djvu и прочих ТеХов в пользу нового формата.
я всего лишь надеюсь, что когда будет создан "еще один" формат, в нем будут учтены все плюсы и все минусы, которые народ обнаружил в имеющихся форматах. пусть даже это будет не nfb, а, скажем, fb3. только мне почему-то кажется, что при разработке fb3 учитывается мнение не тех, кто будет пользоваться, а тех, кто на нём будет зарабатывать.

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

Опубликовано пн, 01/12/2008 - 01:15 пользователем computers

Вот это уже конструктивно и по делу тоже. При таком подходе и я не против :). А то развели тут драчку:

Цитата:
вопросы надо/не надо, перспективно/не перспективно, есть смысл/нет смысла обсуждаться не будут, связанные с этими темами посты будут удаляться.
Нельзя же так, батенька! Для честных пиратов это - что красная тряпка для быка ;). Т.е. вам следовало предвидеть, что данное заявление в условиях Либрусека - троллинг чистой воды, и приведет к флейму. Вот и все, что я хотел сказать, спасибо за внимание ;).

Опубликовано пн, 01/12/2008 - 01:56 пользователем СерыйМыш

computers написал:
Нельзя же так, батенька! Для честных пиратов это - что красная тряпка для быка ;). Т.е. вам следовало предвидеть, что данное заявление в условиях Либрусека - троллинг чистой воды, и приведет к флейму. Вот и все, что я хотел сказать, спасибо за внимание ;).
поступим с точностью до наоборот. снимаю предыдущее заявление, перевожу тред в состояние "не модерируется". все результативные мысли и технические подробности буду собитать в пресс-релиз и периодически прикреплять к верхнему посту, чтобы потом не рыскать по всему треду в поисках.

Опубликовано пт, 28/11/2008 - 11:05 пользователем rr3

Помнится, некий пост в теме fb3!!! был злостным оффтопом. Жаль, что в свое время его не удалили...

Опубликовано пт, 28/11/2008 - 11:45 пользователем СерыйМыш

***

rr3 написал:
Помнится, некий пост в теме fb3!!! был злостным оффтопом. Жаль, что в свое время его не удалили...
на то воля хозяина треда. кнопка есть, факт офтопа на лицо, так что ничего не мешает сделать это хоть сейчас.

Опубликовано пт, 28/11/2008 - 11:50 пользователем rr3

СерыйМыш написал:
***
на то воля хозяина треда. кнопка есть, факт офтопа на лицо, так что ничего не мешает сделать это хоть сейчас.

Я - не вы, "хозяин треда" - не барин, обсуждение - не монолог. Удачи.

Опубликовано пт, 28/11/2008 - 00:07 пользователем arteume

ПОчитал написанное и здесь и в указанном посте про фб3. Значительно поднял свою эрудицию и выучил новое слово "парсить". Спасибо!

Теперь к делу:

1) Как быть с использованием различных знаков, например, греческого алфавита, арабского, иврита, а также всяких испанских нь, кириллических ль, нь, французского и португальского ç, умляутных и прочих диакритических знаков существующих в юникоде?

2) Почему нельзя сделать 2 версии читалки - для компа и для кпк. В таком случае прога для компа могла бы сохранять полюбившиеся способности кулридера и др. программ в частности в размере шрифта.

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

Опубликовано пт, 28/11/2008 - 12:28 пользователем СерыйМыш

arteume написал:
1) Как быть с использованием различных знаков, например, греческого алфавита, арабского, иврита, а также всяких испанских нь, кириллических ль, нь, французского и португальского ç, умляутных и прочих диакритических знаков существующих в юникоде?
точно так же, как и во многих других программах - использовать utf-8. для остального - подключаемые плагины.

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

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

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

Опубликовано пт, 28/11/2008 - 01:20 пользователем 1_абрам

Сделать ввод формул как в tex:

Вместо @@math|\integral@@ - $\integral_0^1 e^x dx $,
^^надстрочный индекс^^ - $a_i$, \/подстрочный индекс\/ - $a^j$. Знак $ изображается \$.

Греческие буквы тоже как в тех : $\beta$.

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

Опубликовано пт, 28/11/2008 - 13:46 пользователем СерыйМыш

1_абрам написал:
Сделать ввод формул как в tex:
Вместо @@math|\integral@@ - $\integral_0^1 e^x dx $,
^^надстрочный индекс^^ - $a_i$, \/подстрочный индекс\/ - $a^j$. Знак $ изображается \$.
Греческие буквы тоже как в тех : $\beta$.
На первом этапе вызываемый форматер (плагин) может рисовывать только простейшие формулы, теховская нотация наглядна и понятна в своем исходном виде.
одним техом ограничиться вряд ли выйдет, поэтому имя плагина придется однозначно указывать. про двухбайтовые сигнатуры я уже писал. допустим, что $$ выглядит приличнее, чем @@. тогда либо $$TeX|\integral_0^1 e^x dx$$, либо что-то похожее.
реализовывать поддержку всех команд ТеХа внутри книжного формата - это перебор, а вот в виде плагина - вполне.
при этом использовать безусловно плагин теха для вывода надстрочных/подстрочных индексов - явно лишнее.
две встроенные команды - "^^" и "\/" против плагина полюбому побеждают, но с изменениями.
чтобы избежать лишних повторов, команды будут действовать на часть строки до пробела.
таким образом, пифагор 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.
аналогично и с подстрочным индексом.
а вот степень в степени - это уже задача для плагина. кто бы ещё взялся его написать?

Опубликовано пт, 28/11/2008 - 12:25 пользователем traum

Для блоков цитата/эпиграф/стихи предлагаю добавить необязательные заголовок и подпись - в таком например виде:

[!]
Быть или не быть...
[!]Шекспир, Гамлет

[&]Узник
Сижу за решеткой в темнице сырой
[&]1822

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

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

traum написал:
Для блоков цитата/эпиграф/стихи предлагаю добавить необязательные заголовок и подпись - в таком например виде:
[!]
Быть или не быть...
[!]Шекспир, Гамлет
[&]Узник
Сижу за решеткой в темнице сырой
[&]1822
Подпись позволит не потерять тег text-author из fb2, да и вообще, вполне стоящий выделения структурный элемент. Заголовок большей частью полезен для стихов, в остальные блоки - для единообразия.

очевидное решение, но сам не додумался. включаю в спецификацию.

Опубликовано вс, 30/11/2008 - 19:29 пользователем Helgi

1. Очень хотелось бы увидеть читалку.
2. По моему скромному мнению, до тех пор, пока этот формат не будет читаться хотя бы на winmobile-КПК, популярность его будет не очень большой.
3. Конечно, хотелось бы видеть версии читалки и для более других платформ. Например, для виндовых и симбиановых смартфонов, для настольного линукса, для lbook. Дело в том, что в на настольной виндовой машине и так можно прочитать что угодно — от сколь угодно сложного HTML и до дежавю. Хороший, «лёгкий», переносимый формат хочется иметь именно для карманных устройств.

Опубликовано пн, 01/12/2008 - 07:55 пользователем alextexx

СерыйМыш писал в теме fb3!!! :

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

Хотелось бы увидеть тоже самое в отношении портирования на другие платформы GDIPlus.dll (через которую производится вся отрисовка в разрекламированной маленькой читалке).

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

alextexx написал:

Хотелось бы увидеть тоже самое в отношении портирования на другие платформы GDIPlus.dll (через которую производится вся отрисовка в разрекламированной маленькой читалке).

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

Опубликовано вт, 02/12/2008 - 02:56 пользователем koreec

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

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

Lazarus

Опубликовано вт, 02/12/2008 - 03:01 пользователем whistle

Зря. Всё равно придётся.

Опубликовано пн, 01/12/2008 - 12:02 пользователем jno

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

а мечтать, что все кинутся портировать проприетарное закрытое угробище GDIplus... Ну, мечтайте. Или получите просто ещё одну форточную читалку, коих и так уже дох..я. Вот недавно уже требовали формат айсбукридера "поддержать".

Опубликовано пн, 01/12/2008 - 14:12 пользователем Atirik

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

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

Выложена новая редакция спецификации.
http://lib.rus.ec/sites/default/files/NFB%20Specification_1.0.6.txt

Спецификация практически готова к переводу в стадию "прототип" и внутреннему тестированию. тестовые версии читалки и конвертера будут выложены после их доработки.

Опубликовано вт, 02/12/2008 - 02:21 пользователем alextexx

jno писал:

Цитата:
Если уж припёрло портабельный гуй поюзать, то Qt вам в руки...
СерыйМыш писал:
Цитата:
Читалка...весит 95 килобайт. Именно 95К. ... Ей не нужны никакие дополнительные dll и парсеры XML. ... То есть, ничуть не отстает от Haali Reader, который и был вобщем-то источником вдохновения и разочарования.
При чем тут GUI? Для вывода картинок в представленной читалке используются функции GDIPlus.dll. (Это к вопросу …не нужны никакие дополнительные dll…). Что касается Haali Reader, который был источником разочарования, то в нем для вывода картинок используются переносимые библиотеки libjpeg и libpng. При портировании супер маленькой читалки на другие платформы, придется либо портировать GDIPlus.dll., либо использовать подобные библиотеки работы со стандартными типами картинок. Плюс к этому добавить модуль работы с переносами и в итоге от супер маленькой читалки ничего не остается. Она по размеру будет сопоставима с Haali Reader.

Опубликовано вт, 02/12/2008 - 03:36 пользователем СерыйМыш

alextexx написал:
Для вывода картинок в представленной читалке используются функции GDIPlus.dll. (Это к вопросу …не нужны никакие дополнительные dll…).
для винды эта библиотека является "встроенной", и обязательно присутствующей в любом дистрибутиве, начиная с Win2K. может ещё посчитать некорректным обращение к kernel32.dll, или к user32.dll при создании окна программы?
а вот MSXML - это реально дополнительная длл, потому как например FBEditor отказывается работать при ее отсутствии, а по дефолту она в системной поставке не идёт.

alextexx написал:
Что касается Haali Reader, который был источником разочарования, то в нем для вывода картинок используются переносимые библиотеки libjpeg и libpng.
я в курсе, смотрел исходники. и парсер xml там собственный, без валидатора и шаблонов. вы же не станете упрекать эту прогу в том, что она использует libc? и в том, что для отрисовки виндовых окон она обращается к виндовой же user32.dll? платформа для того и существует, чтобы обеспечить некоторую общую функциональность. для винды одни функции, для линуха другие, для симбиана третьи, но суть у них схожая - нарисовать интерфейс, прочитать файл и т.п.

alextexx написал:
При портировании супер маленькой читалки на другие платформы, придется либо портировать GDIPlus.dll., либо использовать подобные библиотеки работы со стандартными типами картинок.
не первый и не второй вариант. если среда исполнения имеет собственные средства, сделанные максимально близко к нужному варианту, какой смысл их воспроизводить в программе? вот если на кпк нет библиотеки для работы с картинками (в чем я сомневаюсь), тогда есть смысл юзать модули, встроенные в программу.

alextexx написал:
Плюс к этому добавить модуль работы с переносами и в итоге от супер маленькой читалки ничего не остается. Она по размеру будет сопоставима с Haali Reader.
хоть завтра добавлю. 8 килобайт в исходнике, около 2Кб в бинарном коде. только надо ли? если всем нравятся переносы, будут переносы. могу даже подключаемые правила переносов прикрутить, чтобы для разных языков. еще 1.5 килобайт. итого около сотни. а Хаали весит полмегабайта. даже если я добавлю встроенный парсер xml и конвертацию из fb2 "на лету", которые весят в сумме 80-90 килобайт, всё равно не догоню.

Опубликовано вт, 02/12/2008 - 04:30 пользователем alextexx

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

Цитата:
…для винды эта библиотека является "встроенной", и обязательно присутствующей в любом дистрибутиве, начиная с Win2K.
Ты путаешь системную библиотеку (которая висит в памяти с момента загрузки системы) и библиотеку, имеющуюся на диске (которая подгружается при необходимости как GDIPlus.dll). Специально просмотрел список всех процессов в системе и ни один не использует GDIPlus.dll – в памяти ее нет. А после загрузки sample.exe – появилась. Так что, GDIPlus.dll используется по такому же принципу, как и MSXML.dll

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

Цитата:
…если среда исполнения имеет собственные средства, сделанные максимально близко к нужному варианту, какой смысл их воспроизводить в программе?
Теряется переносимость. Интерфейс работы с изображениями в разных средах исполнения – разный. Для этого и пишутся libjpeg и libpng. А по-иному для каждой платформы придется писать свою читалку (не компилировать один исходник под разные платформы, а писать отдельно исходник на каждую платформу). А это уже гораздо сложнее поддерживать и модифицировать.

Относительно нового формата У меня возникло 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 -архива), позволяют при необходимости разбить текстовый файл на несколько частей (в случае если он слишком большой – к примеру, какая-нибудь энциклопедия или книга с большим содержанием картинок) и работать с частью файла.

Опубликовано ср, 03/12/2008 - 00:31 пользователем СерыйМыш

!!! Осторожно, очень много букв! :)

alextexx написал:

Ты путаешь системную библиотеку (которая висит в памяти с момента загрузки системы) и библиотеку, имеющуюся на диске (которая подгружается при необходимости как GDIPlus.dll). Специально просмотрел список всех процессов в системе и ни один не использует GDIPlus.dll – в памяти ее нет. А после загрузки sample.exe – появилась.
Так что, GDIPlus.dll используется по такому же принципу, как и MSXML.dll
не-не-не-не, я не о том. я о том, что у любого, у кого установлена винда, заведомо есть GDI+. а вот msxml может и не оказаться. и тогда требуются дополнительные танцы, на которые "непродвинутый" пользователь не пойдет. не запустилась прога - всё, значит поставим другую. я кстати так тоже иногда делаю. особенно расстраивает приверженность некоторых к платформе .NET, причем максимально послених версий, которая сволочь уже под сотню метров в дистрибутиве, и качать её ну никак не улыбает.

alextexx написал:

Цитата:
…если среда исполнения имеет собственные средства, сделанные максимально близко к нужному варианту, какой смысл их воспроизводить в программе?

Теряется переносимость. Интерфейс работы с изображениями в разных средах исполнения – разный. Для этого и пишутся libjpeg и libpng. А по-иному для каждой платформы придется писать свою читалку (не компилировать один исходник под разные платформы, а писать отдельно исходник на каждую платформу). А это уже гораздо сложнее поддерживать и модифицировать.
согласен, что переносимость - это хорошо но есть некоторые особенности, которые просто невозможно реализовать на конструктивно разных платформах. и создание переносимой версии автоматом отрезает нас от использования "платформозависимых" наворотов, того же сглаживания при выводе шрифтов, или наложения с прозрачностью. опять же, как сделать единый интерфейс для экрана 640*320 точек, и для 1280*1024? либо учитывать ограниченный размер, либо для каждого варианта сделать своё - на большой экран можно налепить разных фенечек, а для смартфона оставить только утилитарную часть. если делать общий интерфейс, урезанный под минимальные возможности, то в итоге прога становится универсальной, но невыразительной.

alextexx написал:
Архивировать или не архивировать?

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

alextexx написал:
Кодировать картинки в base64?

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

alextexx написал:
Использовать base64 опять же расточительно и перед выводом требует раскодировки.

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

alextexx написал:
XML or not XML? (Подражание Шекспиру)
Вот тут сложнее.
Сам формат XML мне тоже не шибко нравится. Но книга по своей структуре хорошо ложится в древовидную структуру, хорошо разбираемую XML. Поэтому думаю, что оглавление книги должно содержаться в отдельном файле в виде разметки XML (или XML-подобной поддерживающей древовидную структуру) с указателями на смещения различных глав и секций в текстовом файле и указателями на смещения картинок в файле книги. А вот конкретно текст книги хранить отдельно.
Идея СерыйМыш отделить форматирование текста от XML мне нравится.
Даже очень нравится!
Мне кажется, что такое сочетание будет удачным. Не нужно проходить по всему текстовому файлу, чтобы получить оглавление книги и указатели на картинки. Произвел разбор оглавления, получил смещение в текстовом файле на нужное место в книге, а дальше вывод по той схеме, что предложил СерыйМыш.

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

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

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

вобщем темы на сегодня такие:
1. довести до ума управление разметкой на основе "непарных" тегов - так, как сейчас описано в спецификации. это позволит однозначно упростить парсинг и форматирование. плюс "ремонтопригодность" - при случайном включении в текст управляющих комбинаций произойдет только лишнее "переключение" форматирования, и ничего более, структура всего файла не пострадает.
2. разобраться с картинками. кстати, упаковка jpg/png в архив с попыткой сжатия абсолютно бессмыслена - не упаковываются они по своей природе. хранение картинки в текстовом файле в base64 позволяет не заморачиваться, и архивировать весь файл целиком. текстовая часть сожмется лучше, картинки сожмутся хуже, но всё равно не менее чем на 20% - такова суть base64. опять же отпадет заморочка с "архивом в архиве".
3. разобраться с необходимостью и способом построения индекса. на этот счёт была мысль такая - читалка/библиотекарь при первом открытии или при импорте файла создаёт для себя _отдельный_ индексный файл (или общую индексную таблицу для всей библиотеки), и пользуется им. там же рядом читалка держит свои закладки, пометки и прочие удобства. при экспорте книги наружу передаётся только информативная часть - собственно текст с картинками. при острой необходимости, можно сделать экспорт закладок/пометок/правок, и таскать его в паре с основным файлом, но это принципиально вредно, потому как отдельные файлы имеют обыкновение распараллеливаться и теряться.
4. разобраться с "портабельностью". мнение на этот счёт однозначное - для платформ со сходными характеристиками можно делать "переносимый" код, и сохранять единство конструкции. для платформ WinMobile/Symbian/Android нужна своя ветка программы, учитывающая ограничения размера экрана и особенности управления - стилусом/пальцами/кнопками. внутреннее устройство программы при этом может совершенно не отличаться, но вот визуальная часть должна быть у каждого своя. для устройств типа e-book - третий вариант интерфейса, а может и не только интерфейса.
5. ?????
6. PROFIT (c) :)

Опубликовано ср, 03/12/2008 - 01:55 пользователем 1_абрам

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

documentstyle[12pt,a4,landscape]{Poerty}.

Ну и соответвенно убрать ключ CONT.

Опубликовано ср, 03/12/2008 - 03:43 пользователем СерыйМыш

1_абрам написал:
После FormatID добавить секцию стиль, указывающий читалке способ отображения документа. Что-то вроде этого:
documentstyle[12pt,a4,landscape]{Poerty}.
Ну и соответвенно убрать ключ CONT.

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

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

Опубликовано ср, 03/12/2008 - 04:20 пользователем 1_абрам

СерыйМыш написал:
1_абрам написал:
После FormatID добавить секцию стиль, указывающий читалке способ отображения документа. Что-то вроде этого:
documentstyle[12pt,a4,landscape]{Poerty}.
Ну и соответвенно убрать ключ CONT.

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

Согласен, но ведь читалка знает на каком устройстве оно установлена и соответвенно может адаптировать, упращать указанный стиль к заданному устройству: 12pt преобразуется во что-то подходящее для смартфона и.т.р. А documentstyle определяет оптимальный стиль, который может быть отображен на большем экране. А устройства для чтения с большими (>=A3) экранами появятся очень скоро и nfb должен использовать их возможности.

Опубликовано ср, 03/12/2008 - 07:20 пользователем alextexx

Предлагаю рассмотреть следующий вариант:
По-моему архивирование библиотеки целиком идея не очень удачная. Если библиотека будет содержать большое количество книг, ее обслуживание (добавление, удаление и т.д.) превратится в настоящий геморрой.
Архивирование книги по одной на архив, на мой взгляд, оптимальный вариант.
Структура архива могла бы быть такой:
-- 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.

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

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

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

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

alextexx написал:
Архивирование книги по одной на архив, на мой взгляд, оптимальный вариант.
Структура архива могла бы быть такой:
-- content.nbf <- сжато (deflated)
-- text.nbf <- сжато (deflated)
--0000.jpg <- без сжатия (stored)
--0001.png <- без сжатия (stored)
--и т.д.
технология называется "здравствуй грибов" :)
в принципе лично к нему у меня претензий нет, но как-то не хотелось бы обезьянничать и делать "те же файлы, только в профиль".
файл индекса должен позволять получить практически мгновенный доступ к произвольному участку текста. в идеале индексироваться должен не текст, а уже сжатый файл. в принципе, при использовании блочной архивации можно значительно увеличить скорость за счёт того, что распаковываться будет не весь файл с текстом, а небольшой фрагмент. тут нужно опять же исходить из того, что важнее - минимальные затраты памяти, или скорость доступа, потому как непосредственное чтение из файла и распаковка секций "на лету" медленнее, чем однократная распаковка в буфер.
мысль по поводу бинарного контейнера с нестандартным внутренним форматом я уже обсуждал, и подробно рассказывал, почему это плохо. хоть это и самый эффективный вариант, сложность в обработке убьет на корню все преимущества. понимать этот формат будут от силы несколько человек, а написать для него поддержку вообще может не найтись желающих.

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

подозреваю, что для программ под Win32 и WinMobile ответы на эти вопросы будут разными.

Содержание файла text.nbf: Cекция "Text"

alextexx написал:
Содержание файла content.nbf :
...
Проверка корректности смещений в тексте производится сравнением максимального смещения и размера распакованного файла text.nbf из заголовка zip-архива. Не факт что перейдешь в нужное место, но читалка не упадет.
при такой конструкции форматныз тегов, как предложена, не упадёт. но радости мало, промазать мимо нужной секции.

alextexx написал:
При чтении распаковываешь text.nbf, переходишь на нужную главу по смещению – и далее потоковый вывод.
в итоге всё равно приходится распаковывать весь text.nfb. ну, и в чём счастье? время распаковки, чтения и разбора индексной таблицы примерно сопоставимо со временем составления индекса по данным в буфере памяти. смысл как-то начинает теряться.

alextexx написал:
Встречается картинка – из оглавления zip файла берем смещение в архиве на соответствующий файл изображения, а он хранится без сжатия (zip для jpg и png практически не дает выигрыша), считываешь в память – и далее вывод стандартными функциями.
Плюс к этому программа-библиотекарь может работать только с файлом content.nbf.
опять же, подгрузка каждой картинки "на лету" - не очень здравый вариант. нужно предусмотреть кеширование и/или подгрузку с упреждением. либо, есликартинок не много, поднимать их все в память. опять вопрос подхода упирается в то, на какой платформе это крутится, чколько памяти, и т.п.

Опубликовано чт, 04/12/2008 - 09:09 пользователем Midas

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

А если посмотреть CoolReader3? Минималистский интерфейс, динамические страницы, стили, таблицы, мультиплатформенный движок ... проект в развитии. Мне он почему-то больше импонирует чем AlReader.

Опубликовано вт, 23/12/2008 - 14:44 пользователем Erlgrey64

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

А если посмотреть CoolReader3? Минималистский интерфейс, динамические страницы, стили, таблицы, мультиплатформенный движок ... проект в развитии. Мне он почему-то больше импонирует чем AlReader.

CoolReader разве на КПК работает? И весит он сколько?

Опубликовано вс, 11/01/2009 - 07:12 пользователем Midas

Цитата:
Программа мультиплатформенная, в настоящее время поддерживает Windows, Linux, Mac.
Имеются работающие версии для Symbian(SmartReader) и LBook/Jinke eBook V2/V3.
Готовятся версии для PDA.
Программа публикуется по лицензии GPL. Исходные тексты доступны на sourceforge.net.

Распакованная win-версия - 2,5 М

Страницы
X