fb3!!!

Опубликовано пн, 08/06/2009 - 02:43 пользователем soshial

на фикшнбуке второй заход обсуждения формата "fb3".
если есть пожелания и профессиональные советы, то думаю, стоит туда обратиться =)
(сам Грибов писал, что он заинтересован.

последние новости (март, 2009):

GribUser написал:
Cobalt написал:
А вообще когда можно ждать окончательную версию стандарта? Хотя бы приблизительные сроки... И от чего это собственно зависит?

Окончательная будет через годик, думаю. Едва ли раньше. Рабочая будет к осени, надеюсь. Драфт уже есть, второй драфт должен быть, по идее, но пока его нету, потому что я ужасно занят текущими проблемами и времени на доработку формата нет.
Зависит скорость разработки пока, в основном, от моей занятости. Так же весьма важно и общественное участие, но сейчас набросали уже кучу замечаний, которые пока сил нет, узкое место - во мне. Хотя, думаю, общество могло бы побольше косяков наловить. Если бы хотя бы пара профи дали себе труд внимательно просмотреть схему, следующий драфт, до которого я таки-доберусь когда-то, стал бы значительно лучше.


.
материалы и ссылки: 1. xslt-код [устарело] 2. краткое описание fb3 [устарело] 3. обсуждение формата [активное обсуждение]

.

Комментарии

Опубликовано вт, 18/11/2008 - 02:36 пользователем whistle

7. PROFIT!!!

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

переведи

Опубликовано ср, 19/11/2008 - 02:53 пользователем whistle

http://lurkmore.ru/PROFIT

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

Цитата:
Следует отметить, что семь (в крайнем случае, пять) вопросительных знаков обязательны. Без них применение мема считается зафейленным.

низачот.

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

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

А нельзя сделать конструкцию без замыкающих тегов? Или без жестких требований к замыкающим тегам - типа, тег форматирования текста кончается там, где начинается другой тег форматирования.
Это должно снизить требования к анализу текста читалками и, кроме того, уменьшить объем тегов (тег типа "emphasys" вместо, скажем, "i" мог выдумать только нездоровый человек (ИМХО)) по отношению к объему текста.

Опубликовано вт, 18/11/2008 - 04:43 пользователем Ulenspiegel

Нееееееет! Только не "конструкцию без замыкающих тегов"! Это не снизит прожорливость читалок, наоборот. Чем менее грамматически жестко задан язык разметки, тем более хитрож... сложным является парсер. Проверочное слово - SGML. А i вместо emphasys - и в рамках XML прекрасно умещается.

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

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

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

oldvagrant написал:
Это должно снизить требования к анализу текста читалками и, кроме того, уменьшить объем тегов (тег типа "emphasys" вместо, скажем, "i" мог выдумать только нездоровый человек (ИМХО)) по отношению к объему текста.

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

а в другом случае нет, что вынуждает редактор (или того, кто додумается городить это руками) добавлять лишние парные конструкции, и в итоге увеличивает количество срабатываний по сигнатурам:
обычный <ita>курсив <str>полужирный курсив</str></ita> <str>просто полужирный <und>подчеркнутый полужирный</und></str>

что называется - оцените разницу в длине выходного текста и его читабельности.

P.S.
я тут обнаружил, что спор в основном ведется с двух точек зрения. первая точка - кодерская, когда люди оценивают именно простоту и возможность программной реализации (причем своими руками). и вторая - абстрактная, когда человек не собирается сам ничего кодить, и его интересует лишь теоретический аспект. так вот, господа теоретики, скажу вам сразу - если уж для такого простого формата, как fb2, никто не сподобился написать удобный редактор, то для формата, подобного мс-офисному .docx (а fb3 именно таковым и является) вообще нет шансов получить хоть какой-то вразумительный редактор и альтернативные читалки. и распаковка-упаковка zip, и парсинг xml по схемам, и корректная обработка файла связей .rels - это на порядок более сложные вещи, чем работа с тем же плоским xml, не говоря уже об обычном тексте. и я, например, не взялся бы _бесплатно_ делать для такого формата читалку/редактор, ибо нагрузка на мозг в этом случае будет явно больше, чем моральное удовлетворение от полученного результата.
попробуйте ради эксперимента написать конвертер из "открытых" форматов .docx или .odt хотя бы в обычный текст, пусть даже используя готовый распаковщик zip и парсер xml, и посмотрите, на каком этапе вас заклинит. а лучше для начала ознакомьтесь со спецификацией "ECMA-376 Part 2", чтобы иметь общее представление о том "как хорошо, когда картинки в отдельных файлах".
в результате вы поймёте смысл всех этих танцев с fb3 - вынудить людей использовать коммерческие читалки, потому как бесплатных скорее всего не будет, а если и будут, то совместимость у них будет на уровне совместимости MSOffice и OpenOffice. кто ровнял и переформатировал разъехавшиеся таблицы и списки, тот в курсе. конвертер fb3-fb2 тоже вещь явно нетривиальная, и не факт, что кто-то сразу кинется его писать.
извиняйте, опять приступ графоманства :)

Опубликовано вс, 26/04/2009 - 14:43 пользователем Aleksey_nederlands

Sorry using english - no Russian keyboard on my laptop.

  • Complexity of fb3. Even simplier than fb2 (book body markup is done more logically than it is in fb2). Yes, multiple files add some fun (it would be bit tricky to use single parser as I'm using now). But so far - no real problems, I hope I'll finish my fb3 reader next week (just a hobby, no more than 1 hour/day :-).
  • My reader/printer uses full schema validation. Working pretty fast, and just ~500 lines of code. This really helps to correct some mistakes in fb2 books (not so often, but happens). By the way, tag "ID" in "AUTOR" is not defined, but most of librus books have it.
  • Convetrer fb3->fb2 - bit advanced xslt (usage of multiple sources is advanced feature :0). Amount of work: ~1 week.
  • Nobody would do it - my reader I wrote just to practice with full-screen API (and also being bored with litportal/ICE reader/etc).

If somebody interested, I can put my reader/printer somewhere (open source :-).

Опубликовано вт, 27/01/2009 - 04:48 пользователем lebird

6. Предметный указатель - либо закладками, либо <p id="string" &rt;
7. Комментарии, в комментариях, например, код, возвращающий картинку - формулу и пр. и т.д.

Опубликовано вт, 18/11/2008 - 02:42 пользователем Ulenspiegel

Это, например, образец вывода на экран какой-либо программы. Или кусок лога. Или кусок текста программы.
Пример.... Ну, выход ifconfig'а, например.

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

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

Питерс, Эллис.
     Выкуп за мертвеца / Эллис Питерс ; [пер. с англ. Е. Фрадкиной]. - Санкт-Петербург : Азбука : Терра, 1996. - 381 с. : ил. ; 17 см. - (Детектив из средневековой жизни).
     Из цикла "Хроники брата Кадфаэля". - 20000 экз. - ISBN 5-7684-0053-2 (в пер.) : б. ц.

     -- 1. Детективные романы и рассказы (х. л.).
N 20873 УДК 820-31Питерс
55 N 4290 N 6919 [96-26126] ББК 84(4Вл)

и не просто расшифровкой, а осмысленным заполнением всех полей. про то, чтобы вручную формировать изгороди вида
001 RU\NLR\bibl\00003
005  20060812140230.0
010 ##$a5-7684-0053-2$bв пер.$dб. ц.$920000 экз.
021 ##$a96-26126
100 ##$a19970630d1996#### | | | y0rusy0179####ca
101 1#$arus$ceng
102 ##$aRU
105 ##$aa### | | | | | | | a |
200 1#$aВыкуп за мертвеца$fЭллис Питерс$g[пер. с англ. Е. Фрадкиной]
210 ##$aСанкт-Петербург$cАзбука$cТерра$d1996
215 ##$a381 с.$cил.$d17 см
225 1#$aДетектив из средневековой жизни
300 ##$aИз цикла "Хроники брата Кадфаэля"
488 #0$12001#$aХроники брата Кадфаэля
606 1#$aДетективные романы и рассказы (х. л.)$2rkp-sh
675 ##$a820-31Питерс
686 ##$a84(4Вл)$vLBC/PL$2rubbk
700 #1$aПитерс$bЭ.$gЭллис
702 #1$aФрадкина$bЕ.$4730
801 #0$aRU$bRKP$c19961029$gpsbo
801 #1$aRU$bNLR$c19970630
801 #2$aRU$bNLR$c20060812$gRCR

речь, думаю, вообще не идёт.

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

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

как вам перспектива получить сортировку книг по предметным рубрикам?
в смысле, перевести класификатор жанров на систематизированные рельсы. так вот (цитирую):
Ежеквартально полные данные о предметных рубриках, примененных для раскрытия содержания книг, полученных на государственную регистрацию в РКП, публикуются в виде ежеквартального указателя к "Книжной летописи", а ежегодные списки - в указателе к ежегоднику "Книги РФ в … году"

только на букву А рубрик около тысячи.
кто не верит - гляньте сами: http://www.bookchamber.ru/NationalBibliographySubjects.htm

вобщем, полный пиндык :(

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

Я бы добавил возможность работы с формулами типа $E=mc^2$, как в tex, с разумными ограничениями.

Примеры, текста и читалки впечатляют.

Думаю, что силами пользователей либрусека вполне реально искоренить грибовщину.

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

1_абрам написал:
Я бы добавил возможность работы с формулами типа $E=mc^2$, как в tex, с разумными ограничениями.

че-то мне подсказывает, что реализация подобных вещей приведет к необходимости устройства "подключаемых форматеров", как в движке Wiki. с одной стороны, конечно, приятно видеть красиво нарисованную формулу E=mc2, но с другой стороны, закончится всё банальным воспроизведением мелкософтовского ActiveX по имени Equation (редактор формул), или редактора TeX на базе книжного формата, ибо за простыми конструкциями захочется рисовать дроби, логарифмы и прочую ботву.
теоретически можно сделать специальную редакцию формата для оформления учебников, только вопрос - насколько это необходимо, и почему бы не использовать более подходящий для этих случаев графический формат djvu/pdf? просто есть шанс, что какая-нибудь маленькая ошибка или особенность реализации в парсерах разных версий приведет к тому, что формула будет отображенане так, как задумывалось автором. кому тогда адресовать претензии? тому кто текст составлял/форматировал, или тому, кто вовремя не обновил версию читалки?

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

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

че-то мне подсказывает, что реализация подобных вещей приведет к необходимости устройства "подключаемых форматеров", как в движке Wiki. с одной стороны, конечно, приятно видеть красиво нарисованную формулу E=mc2, но с другой стороны, закончится всё банальным воспроизведением мелкософтовского ActiveX по имени Equation (редактор формул), или редактора TeX на базе книжного формата, ибо за простыми конструкциями захочется рисовать дроби, логарифмы и прочую ботву.
теоретически можно сделать специальную редакцию формата для оформления учебников, только вопрос - насколько это необходимо, и почему бы не использовать более подходящий для этих случаев графический формат djvu/pdf? просто есть шанс, что какая-нибудь маленькая ошибка или особенность реализации в парсерах разных версий приведет к тому, что формула будет отображенане так, как задумывалось автором. кому тогда адресовать претензии? тому кто текст составлял/форматировал, или тому, кто вовремя не обновил версию читалки?

Нет Equation совершенно не к чему, ведь NFB имеет обычную текстовую структуру, так что конструкции tex'a идеально подходят для отображения формул, они общеизвестны, хорошо документированы и легко набираются. Желательность формул - понятна - без них куча книжек не вписывается в формат (научно-популярные, учебники и.т.д.). Включив, часть конструкций tex в NFB вы приобретете сторонников нового формата из многочисленных людей, использующих tex.

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

djvu/pdf - форматы хорошие, м.б. если бы были подходящие устройства для комфортного чтения этих форматов, то и фб2 и nfb были бы не к чему. Пока ни на lbook, ни на сони-505 их не почитаешь.

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

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

Нет Equation совершенно не к чему, ведь NFB имеет обычную текстовую структуру, так что конструкции tex'a идеально подходят для отображения формул, они общеизвестны, хорошо документированы и легко набираются. Желательность формул - понятна - без них куча книжек не вписывается в формат (научно-популярные, учебники и.т.д.). Включив, часть конструкций tex в NFB вы приобретете сторонников нового формата из многочисленных людей, использующих tex.

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

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

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

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

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

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

Согласен, сам таблицы в виде картинок вставлял. Но часто простые формулы содержатся в тексте типа $E=mc^2$ или $см^-3$ ее в виде картинки вставлять неудобно.

Вначале в формат можно ввести простейшие конструкции типа $a_i^j$, затем постепенно расширять возможности.

Ну и конечно для продвижения нового формата нужно написать читалки для WM, lbook's и конвертор
fb2 -nfb.

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

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

1_абрам написал:
Ну и конечно для продвижения нового формата нужно написать читалки для WM, lbook's и конвертор
fb2 -nfb.

Конвертеры нужны в первую очередь из doc, txt, html, rtf - для перевода в него новых вещей. Это устранит ненужную прокладку-fb2 между отсканированными текстами и NFB. Для продвижения - что-нибудь серверное: для исключения fb2 в качестве формата хранения. Тогда уже будет затребован и конвертер nfb->fb2 - для упорных фанатов Gribuser'а :-))

Насчет читалок - они понимают не только fb2.

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

1_абрам написал:
Согласен, сам таблицы в виде картинок вставлял. Но часто простые формулы содержатся в тексте типа $E=mc^2$ или $см^-3$ ее в виде картинки вставлять неудобно.
Вначале в формат можно ввести простейшие конструкции типа $a_i^j$, затем постепенно расширять возможности.

ну, задать верхний и нижний индекс - это не сложно, и в рамках разметки wiki делается элементарно. а вот вопрос с рисованием формул по правилам TeX-а, это немного другое. тут либо делать сразу полную поддержку формул, либо сделать только реализацию тегов вида < sub > и < sup > и успокоиться. метод "постепенно наращивать" закончится бардаком и несовместимостью версий.

1_абрам написал:
Ну и конечно для продвижения нового формата нужно написать читалки для WM, lbook's и конвертор
fb2 -nfb.

читалок для е-буков пока нет, а вот конвертер окультурил и положил в голову сообщения. форум не разрешает бинарники, поэтому нужно как бы текст сохранить как .exe (около 90 КБайт), и получится конвертер. не пытайтесь кормить его чем попало - защит на все случаи жизни не делал, может тупо свалиться. с обычными fb2 в win1251 и utf-8 вроде бы справляется. результат можно переименовать в sample.nfb и подсунуть демо-читалке, она поднимет. кто не нашел читалку - вот прямой линк: http://lib.rus.ec/sites/default/files/NFBR_sample_zip.txt (70 КБайт) - сохранить как зип и распаковать.

Опубликовано пт, 21/11/2008 - 03:43 пользователем TaKir

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

читалок для е-буков пока нет, а вот конвертер окультурил и положил в голову сообщения....
.... с обычными fb2 в win1251 и utf-8 вроде бы справляется. результат можно переименовать в sample.nfb и подсунуть демо-читалке, она поднимет. кто не нашел читалку - вот прямой линк: http://lib.rus.ec/sites/default/files/NFBR_sample_zip.txt (70 КБайт) - сохранить как зип и распаковать.

Конвертер конвертирует нормально, а читалка отображает кракозябрами (и свой образец и получившийся после конвертера файл, fb2 был в кодировке utf-8)

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

там косяк со сравнением "UTF-8" и "utf-8" переведи запись в третьей строке файла в другой регистр.

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

Извиняюсь за повтор!!!!
Не туда всавил текст!!!

По моему непрофессиональноу мнению новая спецификация
fb3 достаточно удачна.
Разбивка одного файла с книгой на несколько секций позволяет
програмистам оптимизировать читалку,производя разбор не всего файла
с загрузкой его в память, а лишь ту часть которая неоходима для
отображения.
Насколько я понял из описания,содержание книги (её структура)
содержится в небольшом xml файле, который несложно все время держать
в памяти. При необходимости отобразить скажем 3 главу
из файла содержания считывается соответствующая ссылка
и производится парсинг небольшой части текста.
В этом на мой взгляд два выигрыша:
1. Не сильно напрягается память.
2. В текствой секции производится разбор из сильно
ограниченного числа тегов(в основно форматирования).
Плюс к этому хранение картинок в бинарном виде без сжатия.
Форматы JPG и PNG сами достаточно хорошо сжимают
изображение. Библиотеки для работы с этими форматами
есть на любой платформе. Вывод изображения на экран
производится простым считыванием части файла в буфер и
передачей этого буфера библиотечной функции.
При этом, если достаточно грамотно разработать
формат файла содержания (включив в него сведения
о включении картинок в определенную текстовую секцию),
достаточно легко реализуется предвыборка картинки при выводе
определенной секции.
В итоге имеем достаточно шуструю читалку не сильно
требовательную к ресурсам.

K недостаткам формата следует отнести приверженность Griba к
каноническому XML.
Все эти XLink, XPointer, namespace, куча всевозможных атрибутов
при тегах лишь затрудняют парсинг.
Мне кажется,что формат должен лишь устанавливать структуру документа,
а способ отображения различных типов тегов должен настраивать
пользователь читалки.

Отностительно формата NFB

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

Цитата:
Предварительное название формата - NFB,
что можно расшифровать как "Nice Formated Book",
равно как и "NOT a FictionBook".

Простота формата напоминает беззаботную улыбку идиота.

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

Что касается сетований на большой размер читалок, то это
претензии к программеру, который вместо написания
простеньгого XML-парсера для очень ограниченного числа тегов,
прикручивает msxml*.dll или какой нибудь другой парсер, расчитаный на
разбор канонического XML со всеми наворотами(XLink...).

При текстовом разборе строки особой разницы между разбором
...,... и [!]...#0D#0A, [>]...[>] и
прочих тегов размерки нет.

Относительно хранения картинок в base64.
При хранении в бинарном виде отображение просхотит
в следующем порядке:
считывание в память файла -> передача в функцию ->
распаковка в память(по сути дела в bmp) -> вывод на экран.

При хранении в base64 впереди этой цепочки добавляется:
чтение в память -> раскодировка в бинарый вид...

И все эти танцы с бубном для возможности сохранения книги
в одном тектовом файле!
Вывод:
Предлагаю автору изменить название формата на
"POOR Formated Book"

А с моей точки зрения идея формата fb3 достаточно продуктивна.

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

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

alextexx написал:
K недостаткам формата следует отнести приверженность Griba к каноническому XML.
Все эти XLink, XPointer, namespace, куча всевозможных атрибутов при тегах лишь затрудняют парсинг.
Мне кажется,что формат должен лишь устанавливать структуру документа, а способ отображения различных типов тегов должен настраивать пользователь читалки.
нуну. все мы знаем, как устроено электричество в розетке, и что происходит, когда нажимаешь выключатель. и практически каждый из нас способен отремонтировать, ну скажем, блок питания в компе. хренли там делов-то...
и, будьте любезны, поясните, чем вас лично затрудняют XLink, XPointer, и особенно namespace.

alextexx написал:
Простота формата напоминает беззаботную улыбку идиота.
Калашникову скажи, что его автомат херня, потому что в нём всего 10 составных частей.

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

alextexx написал:
Что касается сетований на большой размер читалок, то это претензии к программеру, который вместо написания
простеньгого XML-парсера для очень ограниченного числа тегов, прикручивает msxml*.dll или какой нибудь другой парсер, расчитаный на разбор канонического XML со всеми наворотами(XLink...).
При текстовом разборе строки особой разницы между разбором ...,... и [!]...#0D#0A, [>]...[>] и прочих тегов размерки нет.
давайте спорить о вкусе ананасов с теми, кто их ел (с).
месье похоже очень абстрактно и теоретически знаком с процессом программирования, как такового, и с компиляторами в частности. потому как прикручивание внешней бибилиотеки практически не увеличиват размер исполняемого файла, а вот запихивание аналогичного по размеру кода внутрь программы как раз увеличивает.

я готов продолжить конструктивный диалог сразу после того, как уважаемый alextexx представит нам собственноручно написанный простенький парсер xml, ну, скажем, ограниченный только тегами, встречающимися в fb2. а мы, программисты, поучимся у него, как надо писать программы для разбора текстовой размерки.
а пока можете посмотреть на размер конвертера fb2-nfb. там в нем как раз внутри лежит полноценный xml-парсер ALXmlDoc, написанный Stéphane Vander Clock, за что ему огромное спасибо. так вот, этот парсер в десятки раз быстрее MSXML, хотя умет абсолютно всё то же самое и весит на два порядка меньше.

alextexx написал:
Относительно хранения картинок в base64.
При хранении в бинарном виде отображение просхотит в следующем порядке:
считывание в память файла -> передача в функцию -> распаковка в память(по сути дела в bmp) -> вывод на экран.
При хранении в base64 впереди этой цепочки добавляется:
чтение в память -> раскодировка в бинарый вид...
сам догадался, что там происходит, или подсказал кто?
раз уж познания уважаемого дона настолько глубоки, может он нам заодно расскажет, как происходит выборочная распаковка файла из zip-архива и парсинг таблицы связей .rels в fb3?

alextexx написал:
Предлагаю автору изменить название формата на
"POOR Formated Book"
если уважаемый дон alextexx соблаговолит сравнить внешний вид книги формата fb2, открытой в том же Haali Reader-е, и внешний вид того же демо-примера nfb-читалки, я думаю, он сразу же сможет нам сказать, в чем конкретно ущербность текстового формата nfb в сравнении с текстовым же форматом fb2, а тем более с продуктивным бинарно-xmlно-архивным fb3.

ну и на последок, извиняюсь за прямоту,
alextexx, 265!

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

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

Ok, я в теме разбираюсь - в силу нынешних профессиональных интересов. А Вы? Рассмотрим нижеследующую цитату:
СерыйМыш написал:
ну и на последок, извиняюсь за прямоту,

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

Если честно, я не читал эту Вашу спецификацию. По некоторым косвенным признакам (один из которых я привёл выше) я решил, что оно того не стоит. И не стал тратить время.

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

Вот ещё одна альтернатива:
http://www.caelumobjects.com/opensource/tubaina

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

Таблицу связей .rels просто ни разу не видел (не попадалась мне книга в формате fb3),
а относительно выборочной распаковки файла - это совсем не сложно.
Для картинок распаковывать к счастью ничего не нужно, поскольку файлы картинок
хранятся в zip-архиве, как следует из спецификации fb3, без сжатия(stored).
По оглавлению архива находишь заголовок директории image(что можно сделать при
открытии файла книги). Далее из заголовка соответствующего файла
изображения считываешь его размер и смещение в архиве. Переходишь по смещению и просто считываешь
необходимое количество байтов в буфер. В памяти картинка в бинарном формате.
Передаешь указатель на буфер библиотечной функции. В чем сложность?
Для текстовых секций последовательность действий почти такая же, но поскольку они
хранятся в архиве в сжатом виде, вместо прямого чтения в буфер производится
распаковка в этот буфер штатными средствами zlib библиотеки. Размер буфера для распакованной
секции берется из заголовка архива.
Если оптимизировать разбиение файла на секции (скажем размер каждой секции не более
64 Kb в распакованном виде), то можно организовать циклическую очередь из, к примеру, 3
буферов по 64 Kb,и производить выборку следующей текстовой секции в фоновом режиме.
Плюс один буфер для сносок... ну и так далее. В общем - вопрос реализации.

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

А вот fb2 и предложенный nbf жестко требует производить полный разбор файла.

Теперь о вкусе ананасов:
При динамической линковке библиотеки размер исполняемого файла действительно
не увеличивается. Но при загрузке такого файла на исполнение в память процесса
загружается прилинкованная dll - ка, которая и висит в памяти всем своим могучим размером.
Если линковать статически, то размер исполняемого файла увеличивается на размер прилинкованной
библиотеки.
"Что сову об пенёк, что пеньком по сове... Результат один - сове не летать".
Плюс к этому файл книги полностью считывается в память и полностью парсится.
Результат привычки программирования под мощные компы.
Это все хорошо подходит к компам с большим объемом оперативной памяти (десктопы, ноуты).
Но когда приходится читать, к примеру, на КПК или телефоне, особенно книгу с большим количеством
иллюстраций - читалка виснет.
Fb3 в отличие от предложенного формата позволяет парсить и отображать файл по частям, считывая
в память лишь короткий файл оглавления, который и нужно постоянно держать в памяти.

Теперь о парсинге:
Если СерыйМыш знаком с форматом fb2, то ему должно быть известно,
что в текстовых секциях используется незначительная часть тегов:
p,strong,image,stanza и т.д. Основная куча тегов находится в секции description,
которая собственно к читалке никакого отношения не имеет (всякие там isbn,
src-url,publish-info. Это вопрос к программе-библиотекарю.
А для читалки, с точки зрения программирования, какая разница искать в
строке подстроку "strong" или "**" для переключения шрифта.
Разбор строки все равно придется делать перед отображением, а названия тегов - лишь вопрос вкуса.
Хотя на 32-битной архитектуре действительно желательно для оптимизации поиска
уместить подстроку в двойное слово. Тут я согласен. Теги действительно должны быть покороче.
А фактически набор тегов nbf и fb* для форматирования ничем не отличается.
Я не видел исходников демки, но поскольку написана он на Pascal-е, то рискну
предположить, что разбор текста перед форматированием происходит стандартными
средствами встроенного в Delphi строкового типа (который является аналогом
string из STL).

Чем меня лично затрудняют XLink, XPointer, и особенно namespace?
Одно дело при парсинге найти короткую подстроку и далее просто переключить вывод текста
определенного формата, чем производить разбор всяческих конструкций
типа "xmlns: XLink = "..." XLink:type = ..." XLink:show = "..." и т.д.

Что касается внешнего вида книги в Haali Reader и демке, Haali Reader действительно проигрывает.
Но это проблема не формата, а читалки.
В AlReader fb2 книжка смотрится достаточно неплохо.

ключевое слово здесь - непрофессиональноу Ну, бывают опечатки! Что касается профессионализма, то действительно я не программист-профессионал. Но разобраться со структурой zip файла особого труда не составило.

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

alextexx написал:
Таблицу связей .rels просто ни разу не видел (не попадалась мне книга в формате fb3),
предлагаю скачать пример, любезно подсунутый нам грибоедовым: http://www.gribuser.ru/xml/fictionbook/3.00/example.fb3.zip ,
и на нем отточить своё мастерство. как только будет что-то вразумительное, скомпилированное в .ехе - милости просим.
alextexx написал:
а относительно выборочной распаковки файла - это совсем не сложно.
брателло, это был риторический вопрос. те, кто кодеры, знают это и без развёрнутых пояснений, а остальным глубоко паралельно.
alextexx написал:
Если оптимизировать разбиение файла на секции (скажем размер каждой секции не более
64 Kb в распакованном виде), то можно организовать циклическую очередь из, к примеру, 3
буферов по 64 Kb,и производить выборку следующей текстовой секции в фоновом режиме.
Плюс один буфер для сносок... ну и так далее. В общем - вопрос реализации.
с нетерпением ждём отчета о проделанной работе, не забудь включить в коментарии к коду все идеоматические выражения, которые будут самопроизвольно произноситься в процессе борьбы с "перспективным форматом".
alextexx написал:
А вот fb2 и предложенный nbf жестко требует производить полный разбор файла.
вот с этого места поподробнее. на кой это вам сдалось парсить плоский текст целиком? или построчный проход по тексту с поиском в начале каждой строки тегов заголовков/картинок и составление таблицы смещений - это парсинг?
alextexx написал:
Теперь о вкусе ананасов:
...скип...
Но когда приходится читать, к примеру, на КПК или телефоне, особенно книгу с большим количеством иллюстраций - читалка виснет.
Fb3 в отличие от предложенного формата позволяет парсить и отображать файл по частям, считывая в память лишь короткий файл оглавления, который и нужно постоянно держать в памяти.
омг.
чудовище, здесь полно программистов. и профессиональных и всяких. в теории тут все сильны, покажи готовый код. особенно, я думаю, люди будут рады видеть в исходниках читалку, умеющую парсить файл по частям, и включающую в себя маленькую и быструю реализацию zlib и xml-парсера под тот же симбиан, да и под виннмобайл не помешает.
а потом чисто теоретически сравним, насколько проще и легче была бы читалка, в которой принципиально отсутствует код xml-парсера/валидатора и zip-распаковщика.
alextexx написал:
Если СерыйМыш знаком с форматом fb2, то ему должно быть известно,
победил. сдаюсь! :) я очень слабо знаком с fb2, практически второй раз в жизни его вижу.
alextexx написал:
А фактически набор тегов nbf и fb* для форматирования ничем не отличается.
а с чего бы им отличаться? делают они одно и то же. только разными способами.
alextexx написал:
Я не видел исходников демки, но поскольку написана он на Pascal-е, то рискну предположить, что разбор текста перед форматированием происходит стандартными средствами встроенного в Delphi строкового типа (который является аналогом string из STL).
промазал. разбор текста сделан на PChar, что являтся аналогом массива символов в вашем любимом си. потому как работа со строками типа String в дельфи сделана слегка тормозно.
alextexx написал:
Одно дело при парсинге найти короткую подстроку и далее просто переключить вывод текста определенного формата, чем производить разбор всяческих конструкций типа "xmlns: XLink = "..." XLink:type = ..." XLink:show = "..." и т.д.
парень, ты меня убиваешь. я именно это и имел ввиду, когда прорабатывал формат. именно подход "переключатель атрибутов" вместо подхода "блок текста с определенным форматированием" и вместо изгородей с таблицами стилей как раз отличает предложенный формат nfb от xml-ориентированных fb2/fb3.
alextexx написал:
Что касается внешнего вида книги в Haali Reader и демке, Haali Reader действительно проигрывает.
Но это проблема не формата, а читалки. В AlReader fb2 книжка смотрится достаточно неплохо.
вопрос был не в этом. вопрос был в том, чтобы показать, чем новый формат ущербен, и чего он такого не позволяет делать, что позволяет fb2.
кстати, дружище, то, что ты не нашел, как настроить цвета, выравнивание и форматирование в хаали ридере, насмерть убивает твою теорию о том, что кому-то нужна возможность настроить цвета и шрифты.
все ленивые. всем охота чтобы всё было красиво прямо из коробки.
alextexx написал:
Что касается профессионализма, то действительно я не программист-профессионал.
Но разобраться со структурой zip файла особого труда не составило.
да тут три четверти непрофессионалы и любители. однако никто не берется убеждать других, что "программистам будет удобнее, если файлы будут лежать отдельно". гораздо убедительнее будет звучать: "я написал читалку для fb2 и для fb3, и для fb3 она получилась проще, меньше по размеру, и быстрее в работе".
убеди меня.
2all: извините нас. когда два больных графомана встречаются, обычно так всё и бывает :)

Опубликовано вс, 26/04/2009 - 17:09 пользователем ganzzz

alextexx написал:

При динамической линковке библиотеки размер исполняемого файла действительно
не увеличивается. Но при загрузке такого файла на исполнение в память процесса
загружается прилинкованная dll - ка, которая и висит в памяти всем своим могучим размером.
Если линковать статически, то размер исполняемого файла увеличивается на размер прилинкованной
библиотеки.
"Что сову об пенёк, что пеньком по сове... Результат один - сове не летать".

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

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

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

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

пожалуйста!! не флудите здесь: пишите в своем блоге.

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

А мне вот не нравится в FB3 упаковка в ZIP. Сейчас я перепаковываю (пачкой) скачанные .fb2.zip в формат RAR и размер, как правило, уменьшается раза в полтора. С FB3 так сделать будет нельзя. И не говорите, что это сейчас не важно - 3Гб явно больше, чем 2Гб. Лишний гиг здесь, лишний там.... винчестер не резиновый, да и лучше 2 диска вместо 3-х, хотя и стоят они недорого. Кстати, существуют достаточно быстрые и простые алгоритмы (того же порядка по скорости, что и deflate), но сжимающие получше.
А формат будет тот, который будет поддерживаться больше - будет больше книг в FB3, тогда и FB2 зачахнет, пусть и не до конца, и наоборот. А еще я очень не хочу повторно покупать книги из-за изменения форматов:

Цитата:

http://www.digital-books.ru/obnovlenie-formata-fictionbook-i-elektronnyj-vavilon/
читатели особо не рады ситуации «электронного Вавилона» и, тем более, — помните, как говорил герой «Людей в черном», — необходимости с каждым новым носителем (или форматом) опять покупать «Золотые хиты» Битлз.

Опубликовано чт, 12/02/2009 - 11:08 пользователем VadimV

kusaka написал:
А мне вот не нравится в FB3 упаковка в ZIP. Сейчас я перепаковываю (пачкой) скачанные .fb2.zip в формат RAR и размер, как правило, уменьшается раза в полтора. С FB3 так сделать будет нельзя. И не говорите, что это сейчас не важно - 3Гб явно больше, чем 2Гб. Лишний гиг здесь, лишний там....

Более того, вполне возможно написать препроцессор для fb2/fb3 форматов, который бы преобразовывал файл таким образом, чтобы тот паковался еще лучше процентов на 20-30...

Опубликовано пн, 12/01/2009 - 03:08 пользователем dmitriid

Тут прозвучала следующая мысль:

Цитата:

K недостаткам формата следует отнести приверженность Griba к
каноническому XML.
Все эти XLink, XPointer, namespace, куча всевозможных атрибутов
при тегах лишь затрудняют парсинг.

Проблема не в этом. Проблема в реализации всего этого для мобильных устройств.

И если невалидирующий SAX-парсер может быть очень быстрым и нересурсоемким, то поддержка XLink и прочая в достаточном объеме — это уууу.

Опубликовано вт, 13/01/2009 - 03:47 пользователем Rustam_aka_Rust

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

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

А как на счет того, чтобы делать книжки в EPUB ? нафиг fb3

Опубликовано пт, 23/01/2009 - 16:25 пользователем abulat

Если позволите мнение не совсем неопытного программиста.

I. А нам нужно читать книги или печатать для продажи - это относительно качества представления и т.д. (если конечно издательства не начнут в этом формате давать книги, даром)?
Хорошая читалка мне кажется должна уметь просто показать страницу, листать, искать ... на определенном устройстве - КПК или комп.
Относительно картинок - я ими не разу не пользовался, хотя если говорить об учебниках... Но мне кажется их как раз лучше иметь как pdf. Если это карта - лучше показывать не внутри страницы а в другом окне ... Идея вынести рисунки отдельно хороша особенно для устройств с ограниченной памятью

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

II. О технологиях
1. Относительно парсера - уже упоминался SAX, который работает быстро, занимает мало кода и ! не загружает в память весь текст сразу!
2. Единственная проблема эффективности по объему памяти (для КПК) и по скорости - это использование namespace - при его использовании во вложенных тегах ! эффективность падает. Вывод простой - все пространства имен описываются в root узле, а собственные дополнительные - в пространстве имен по умолчанию. Так что сомнения относительно использования стандартов W3 просто потому, что простой текст кажется проще - это от незнания матчасти (мне так кажется).
3. Вариант использования HTML может оказаться удачным, хотя бы потому, что для него есть реализация, а красоты можно делать стилями (если придумать как быть со сносками)
3. Библиотекарь может хранить в контейнере книги свою собственную информацию - например, устанавливать закладки или относить книгу к той или другой категории - я не ошибаюсь, что файл архива можно редактировать (менять отдельный файл) или возможно только переписывание всего архива? Это дает возможность таскать за собой книгу которую читаешь с компа на КПК и наоборот (сохранив закладки и т.д.)
4. Задача конвертирования из fb3 в fb2 как мне кажеться не стоит выеденного яйца (теоретически, и сам писать все равно не буду ..., наверное ..., только если припечет ...) - это наоборот может не получиться, хотя ... (есть XSLT, в конце концов SAX воспользоваться)
5. Относительно программы на Delphy в которой метаинформация хранится как ключ-значение - это хорошо только если такая информация неструктурирована, а для хорошего библиотекаря это минус, большой и жирный. А когда попробуете ее структурировать получите аналог XML и SAX так что стоит-ли.
6. Относительно редактора fb3 - если я правильно понимаю нужен редактор метаинформации? так это просто несколько форм и если этот стандарт станет по тем или иным причинам популярным, то я уверен, что любой "живой" редактор fb2 будет переделан за несколько дней его разработчиком.

III. ВЫВОДЫ:
Полностью согласен с теми, кто говорит, что новые формат это зло. Лично меня и этот устраивает, тем более, что я читаю fiction books, а не научные статьи (их я читаю в pdf).
Но так считают почти все когда формат обсуждается. Обычно они появляются как реакция на какой-нибудь вариант использования уже существующих и/или появлении новой технологии (не наш случай). Покажите зачем и я тогда соглашусь, может быть..., если пойму ...
А пойму, когда увижу бету программы, прототип, скриншоты в конце концов..., или, например, либрусек стал работать лучше, литрес начал все давать бесплатно и т.п. Тем более, что никто не вводит новый формат без готового приложения, которое его использует.

Сложно ли будет пользоваться fb3 - да точно также как и fb2 (если конечно нет шифрования отдельных файлов, но это не относится к fb3 или я что-то просмотрел?). Если я правильно представляю структура трудозатрат при написании читалки и/или библиотекаря, затраты на вывод, индексацию, поиск, перелистывание и т.д. в таких задачах раз в 20 больше чем чтение из файла. Так, что не стоит по этому поводу переживать. А на первое время появится конвертер в fb2.

Опубликовано вс, 26/04/2009 - 14:51 пользователем Aleksey_nederlands

+1

Опубликовано пн, 16/02/2009 - 06:53 пользователем Рыжий Тигра

Хм. Насчёт перепаковки зипов в рары и прочих извращений: а как насчёт требований распаковщика к объёмам ОЗУ? А то запаковать можно хоть в 7z, он позволяет давить ещё и поплотнее, но кэээк попросит под буфер распаковки сотню мег - а в, к примеру, LBook V3 их всего 32, да и ядру где-то сидеть надо... :(
ZIP чем хорош - ему под распаковку нужны считанные десятки кил...

Опубликовано ср, 25/02/2009 - 15:31 пользователем UPSTM

Господа, зачем париться. Берём фб2, режем по главам и картинкам, запихиваем в зип, обзываем всё это дело OpenFB, классификатор берём из фб3. В итоге - фб3 будет пользоваться только литрес, а у нас будет приличный фикшенбук дизайнер, основанный на том, что есть сейчас и новый, более интересный по сравнению с FB2 формат.

Опубликовано вс, 15/03/2009 - 10:50 пользователем OGR1989

+ Возможность хранения в одном файле несколько произведений
- Необходимость нескольких сторонних программ

По-моему лучше старый добрый
txt.

Опубликовано вс, 22/03/2009 - 05:40 пользователем sergeych

Будущее - за форматами которые не привязаны к бумажному листу (djvu, pdf, ps), потому как читать удобно на том хкране и в том окне которое в данный момент есть - очень удобно. Соответственно формат должен предоставлять информацию как хорошо отобразить в окно произвольно размера. А пытаться уподобить окошко на экране, или сам экран бумажной страничке - атавизм, и отомрет. Для этого есть букинисты :) А читать с экрана надо уметь все - и техдоки, и чтиво. Несчастье, что форматы типа compressed html, не очень распространяются. Хотя они 100 очков вперед любому ps дают.

Надо имхо подработать немного формат fb*, чтобы можно было преформатированный текст включать, кстати. Есть уже реализации ?

По теме. Я давно мучаюсь с написанием под айфон читалки под fb2 - там приложение загружается заново, и, соответственно, открывает книгу заново, практически при любом переключении задач (например, звонок пришел). Так вот, как бы я с fb2 не шаманил, средняя книга открывается 1-6 секунд. При каждом переключении на книгу ждать 6с. гадко, я такой прогой пользуюсь и это ОТСТОЙ.

Соответственно, геморр с кешированием открытых кинг. Чтобы работало хорошо, приходится открывать fb2, вытаскивать из него картинку (которую какой то нестанадртно ориентированный товарисч в конец сжатого файла зафигачил), делить текст на куски, куски снова сжимать и все это писать обратно на диск. Гораздо было бы удобнее если бы все это было уже в архиве, как в fb3. Попробовал не сжимать - но при библиотеке в 10Гб не катит. А оч удобно на айонфе держать именно библиотеку - никогда не знаешь, что и когда понадобится. И естественно хотелось бы хранить книги в исходном формате, а не переделывать их при импорте в нечто типа fb3.

С точки зрения инженера, fb3 организован более продуманно, чем fb2, но тоже не без урода. Технически никаких проблем нет сконвертировать. Зря копья ломаете...

Можно, конечно, встать на точку зрения, что в кармане должна быть плафторма с немереными ресурсами, и экраном формата А4, но имхо это напрасная трата энергии.

Опубликовано вт, 05/05/2009 - 12:21 пользователем Alexeyghe

Есть прога ICE Book Reader Professional Russian называеццо. В принципе ей вообще пофиг формат. Она конвертит всё по своему.

Так вот меня вообще всё там устраивает... нафиг нужен этот фб3.. хз Сама запоминает положение - в процентах. Постраничного маразма нету вообще. Есть скроллинг. Удобно!

К слову книга заносится в базу данных 4-8 секунд а далее из её базы данных открывается на лету!

Кстати она есть уже многие годы... ненаю как вы с использованием постраничного маразма читаете -Р

Все книги легко становятся в базу данных! Формат к слову .ibk называется.

Опубликовано сб, 06/06/2009 - 17:27 пользователем sk_49

Лучшее- враг хорошего.
Чтоб фб-тришная вода
Нам не наделала вреда

Опубликовано пн, 08/06/2009 - 03:55 пользователем Lord KiRon

http://www.the-ebook.org/forum/viewtopic.php?p=244920#244920

GribUser написал:
Roman написал:
Кстати , а что про FB3 слышно - забросили или как ?
Сейчас не до него. В принципе вернемся рано или поздно, никуда не денемся.

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

Опубликовано пн, 08/06/2009 - 06:16 пользователем soshial

может кто-нибудь что-то обзорчика по epub сделает?
а то я знаю о нём только понаслышке...

Опубликовано пн, 08/06/2009 - 06:58 пользователем Tenno Seremel

Кстати, +1

Опубликовано пн, 08/06/2009 - 13:52 пользователем Tenno Seremel

Получилось не так что бы очень, но тем не менее.

http://serenareem.net/html/articles/epub.xml

P.S. В IE лучше не смотреть :)
P.S.2. Если будет тормозить попробуйте подождать или зайти завтра. Что-то Ру-Центр там мутит… %)

Опубликовано пн, 08/06/2009 - 17:34 пользователем soshial

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

Опубликовано ср, 24/06/2009 - 11:22 пользователем Arkanmirr

чем на симбе 9ке открыть мона??? СмартРидер или КьюРидер наверное уже не откроют.......

Страницы
X