Вопрос про картинки

А можно "текст" картинки (тот, что base64'ный код) - прямо в картинку втыкать? Сейчас вроде бы низя, а в будущем такое сделать? Было бы удобно. А то сейчас читаю заголовки (инфу о книгах), чтобы создать индекс для показа списка. И получается, что нужно парсить файлы целиком. Накладно получается. Особенно если этих картинок в файле - ну, зззавались.

А так открыл - прочитал начало - бросил, пошел дальше читать.

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

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

Ну почему, вроде принципиально ничто не мешает разрешить перемешивать тэги <body> и <binary> в произвольном порядке, и размещать картинку содержащую coverpage между <description> и первым <body>.
Или я неправильно понял?

GribUser
Ну, если делать ссылки на картинки и сами картинки, то запросто. Картинка объявляется (прописывается) при первом к ней обращении, а потом просто идут ссылки.

Но это мне и самому не очень нравится. А вот если <binary> прописывать прямо внутри <image> - это было бы очень интересно.

Как такая мысль?

Admin
DOM - не панацея. Я уже про это говорил. Почему к дому-то привязка такая бешеная? Не хочу я использовать DOM. По достаточному большому количеству причин... А то получается, если нет DOM'а, то и FB2 - не читается? Странный подход.

А про буквицы - я уже сказал. Дать возможность просто binary прописывать внутри тэга image. И всё. И ссылаться на этот binary так же. Просто он будет находиться в другом месте, а не железно внутри FictionBook.

GribUser
Я только как "на подумать". Я уже сделал кэш в своём формате (повторяюсь).

Есть ведь два типа картинок. Одни повторяются лишь однажды. Вторые - многократно. Например те же буквицы. Буквицы - можно указывать где угодно, это абсолютно всё-равно. Любое расположение будет одинаково. А вот те, что встречаются один раз - я бы втыкал прямо по месту жительства. Потому что в других местах они не нужны вообще.

Admin
Дом тоже всё шерстит Smile

Мой способ настолько же просто поменять, как и обработку дома. Там примерно одинаково. А, например, если правильно закодировать SAX, то его вообще не нужно будет менять.

Дом не плох. Просто это не единственное решение. И не всегда возможное. Это просто стереотип такой Smile

Что с домом - проще работать в XML. А как только появляются файлы, которые в DOM'е, увеличившись в 5-10 раз, начинают занимать по 200-400 метров - начинаешь задумываться.

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

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

Так что дом - это хорошо. Повторюсь, для редактирования дом - это идеальное решение в 98% случаев (кроме очень огромных файлов, но их наверное и не будет пока). Но для читалок - это достаточно некорректное решение. Неудобное минимум.

Добавлено спустя 46 секунд:

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

Кстати, насчёт картинки - это две команды (ну, не считая обработки на ошибки):
List := Doc.getElementsByTagName('description/title-info/coverpage/*');
Здесь находим ссылку, а дальше
List := Doc.getElementsByTagName('binary');
И вытягиваем бинарник. И совершенно все равно, где он находится.

Admin
Это если дом уже построен. А для того, чтобы построить дом - нужно прочитать весь файл. Чего, собственно, я хочу избежать. Smile

Admin
Мне уже прислали книгу на 6 метров. Там много картинок Smile

А между 6 и 40 - уже не сильно большая разница. Так что будут... Интересно, как их будут редактировать Smile

Я использую так называемый StAX. Streaming API for XML. Если в саксе мне в приложение выдают "события", которые я обрабатываю, то в StAX'е - я сам говорю "дай следующий элемент". То есть читаю, как из потока. Это лично мне - удобнее. Хотя само решение достаточно сильно схоже с SAX.

Ну, и генерю в памяти "образ" документа. Но, в отличие от иерархического ДОМа - линейный. Двусвязный список. После чего бегаю по нему.

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