Драфт FB3

Хорошо бы создать действительно гибкий контейнер. К примеру, элементарно, в header, первый байт файла указываем константу - формат архива (алгоритм компрессии). Применяем ZLib, посредственная коспрессия - для мобильных устройств. Но лучше BZip2 - сжатие на порядок выше. PPMd Шкарина - идеальное сжатие, ориентированное на текстовые данные (то, что нам собственно и нужно - набор символов у нас предсказуем - сжатие в следствие высокое), но только для настольных систем - довольно высокие тревобания к RAM и тч. ЦП. Как вариант для настольных систем - LZMA и ABC BWT (лучший баланс скорости сжатия/упаковки и отличная компрессия).

Я к тому, что реализовать это элементарно, а для пользователя и издателя - удобно. Удобно и для библиотек все таки, ZLib не реализует нормальной компрессии текста, тем более - есть достойная замена в виде BZip2.

Конечно, LZMA/PPMd/ABC для мобильных устройств реализовать сложно по причине требований к RAM и производительности, но, как уже и сказал, можно допустить их использования в настольной версии программ ив производительных мобильных устройствах. Гибкий формат - всегда плюс, а возможность применения отличной компрессии обрадует как библиотеки, так и пользователей.

Почитал описание FB 3.0
Как я понял, теперь текст книги может состоять из нескольких xml файлов (+ файлы-картинки).
А не лучше ли в xml хранить только обложкукниги, т.е. название, автор, переводчик, жанр и т.п.
А саму книгу хранить в нескольких потоках. К примеру
1 поток - это сам текст в формате UNICODE
2 поток - атрибуты текста: жирный, курсив, подчеркнутый и т.п.
3 поток - цвета символов
4 поток - уровни содержания. 0 обычный текст, 1- первый уровень, 2 второй и т.д.

При этом каждый поток хранится в отдельном файле. ИМХО такой подход позволит более удобно писать читалки для формата, так как не надо будет парсить текст из XML

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

Только вряд ли такое здесь примут, тут на xml все задвинуты.. Хотя, можно наверно сделалать конвертор-компилятор в такой формат. Собственно при открытии читалкой это и так делается.

Mike Sinkovsky вот только редактирование такого файла будет еще более дебильно, чем в описанном здесь фб3:)

Shasoft поток 2 3 4 - это одно и то же:), т.е. вполне хватит всего двух...