Информационный портал POCKET  WIKI  FAQ  Поиск  Пользователи  Группы  Регистрация  Профиль  Войти и проверить личные сообщения  Вход Драфт FB3 На страницу Пред.  1, 2, 3, 4, 5 ... 12, 13, 14  След.   Найти сообщения без ответов        Список форумов www.fictionbook.org -> Перспективы формата FB Предыдущая тема :: Следующая тема   Автор Сообщение Alan Автор ридера Alreader и клона Haali Зарегистрирован: 25.01.2005 Сообщения: 421 Добавлено: Пт Июл 04, 2008 19:01    Заголовок сообщения: GribUser да, ты прав, глупость сделал, что влез сюда типа что-то пообсуждать. даже пятница меня не простит. Вернуться к началу Cherckes Новенький участник форума Зарегистрирован: 05.05.2007 Сообщения: 89 Откуда: Гомель Добавлено: Пт Июл 04, 2008 23:15    Заголовок сообщения: Мне кажется что если говорить о тексте то одно произведение -- один текстовый файл, сборник, например рассказов, -- несколько, для сборника такой подход более чем оправдан, да и с отображением прогресса проблем быть не должно -- читают ведь рассказ, и интересно сколько осталось читать/прочитано для рассказа, а не сборника в целом. Цитата: # Картинки больше не хранятся в XML, лежат в архиве, отдельно. Как они там лежат?, ИМХО если есть директория для текстов должна быть такая и для картинок. Цитата: # Сноски будут типизированные. Выделяются концевые и подстраничные. Читалке желательно отображать сноски соответственно. Речь идет ведь о электронной книге?, так почему сноски обязательно текст? Например читаю я в книге что из радио доносились звуки лунной сонаты, что мне даст описание того что это такое и кто ее написал по сравнению с возможностью прослушать кусок? Хотелось бы иметь возможность вставлять в текст фрагменты содержания не относящиеся к схеме fb, например MusicXML для книг по теории музыки, или шахматную нотацию(обсуждалось на форуме), оставив отображение содержимого на читалку,стили тут ни как не проходят, не факт что опция сразу найдет поддержку, но наличие как опции было бы заманчиво. Вернуться к началу GribUser Автор формата FB2 - Автор библиотеки FB Зарегистрирован: 30.09.2004 Сообщения: 2475 Откуда: Москва Добавлено: Сб Июл 05, 2008 20:49    Заголовок сообщения: Cherckes писал(а): Хотелось бы иметь возможность вставлять в текст фрагменты содержания не относящиеся к схеме fb, например MusicXML Хотелось бы, конечно, всё, и сразу, но в ближайший год мы поддержку сторонних нэймспейсов ни в библиотеках, ни в софте, не осилим. Нечего и стандартизировать от, что работать заведомо не будет. Все по порядку бум, давайте сперва с текстом как таковым разберемся окончательно. Вернуться к началу Cherckes Новенький участник форума Зарегистрирован: 05.05.2007 Сообщения: 89 Откуда: Гомель Добавлено: Вс Июл 06, 2008 0:25    Заголовок сообщения: Не поддержку, опцию, тег типа <нихрена не фб stile читать этим(ссылка на плагин)> усе. Тогда если кому потребуется можно будет реализовать поддержку в софте, если тег поддерживается, смотрится соответствующий плагин, если плагин есть содержимое выводится программой, нет просто не отображается. Ограничится форматами построенными на xml, принципы вывода содержимого идентичны, тот же SVG или другой формат векторной графики давно востребован для технической литературы (по сообщениям на форумах), ну вот будет теоретическая возможность, кто нибудь добавит поддержку в читалке, начнут пользоваться, будут пользоваться появится поддержка в других программах, со временем станет нормой как прозрачный фон в картинках. Книга это содержащая помечается только фб, речь как мне казалось идет о перспективе развития формата, или я не прав? Иначе зачем тогда это обсуждение. Достаточно представить перспективу: *Для музыкальной литературы ноты идут как вложение, но не картинка, а текст, со всеми возможностями масштабирования. *Шахматная(шашечная, ..) движком читалки показывает доску с фигурами, со всеми изменениями позиции по ходу чтения. *Техническая литература, масштабируемые чертежи... опять же вместо картинок. Для чего там еще открытые xml форматы есть? ЗЫ А главное не потребуется придумывать как реализовать отображение всего этого в фб силами самого формата, берется готовое и скидывается на сторонний модуль. Вернуться к началу Mike Sinkovsky Зрелый участник форума Зарегистрирован: 27.10.2005 Сообщения: 296 Откуда: Пермь Добавлено: Вс Июл 06, 2008 5:29    Заголовок сообщения: Cherckes писал(а): не потребуется придумывать как реализовать отображение всего этого в фб силами самого формата, берется готовое и скидывается на сторонний модуль. Не потребуется если такие расширения сделать расширением картинки, например типа такого: Код: <image l:href="preview.png"><нихрена не фб stile  читать этим(ссылка на плагин)></image> или такого: Код: <image l:href="preview.png" object="image.svg"/> Тогда тот софт который ничего об этом расширении не знает, или не имеет достаточных ресурсов - покажет картинку, а кто знает - покажет векторный. Вернуться к началу Cherckes Новенький участник форума Зарегистрирован: 05.05.2007 Сообщения: 89 Откуда: Гомель Добавлено: Вс Июл 06, 2008 12:20    Заголовок сообщения: Осталось закрепить тег <нихрена не фб> в формате . _________________ http://esperantofb2lib.at.tut.by/ - Книги в fb2 на эсперанто. Вернуться к началу Mike Sinkovsky Зрелый участник форума Зарегистрирован: 27.10.2005 Сообщения: 296 Откуда: Пермь Добавлено: Вс Июл 06, 2008 13:52    Заголовок сообщения: Cherckes писал(а): Осталось закрепить тег <нихрена не фб> в формате . Угу. И таблицы тоже вынести туда, аналогично другим расширениям. Все равно в том виде что сейчас они не прижились, и сомнительно что приживутся. Вернуться к началу lb-user Новенький участник форума Зарегистрирован: 26.05.2008 Сообщения: 5 Добавлено: Вт Июл 08, 2008 13:22    Заголовок сообщения: А нельзя ли продумать добавление шрифтов туда же, в zip? Довольно редко требуются специальные шрифты (например, типа windings), но когда они используются приходится каждый раз уговаривать читателя скачивать и устанавливать дополнительные шрифты. Ужасно неудобно. Добавлено спустя 6 минут 56 секунд: И ещё. Электронные книги, как ни странно, приходится всё время редактировать, исправлять опечатки, форматирование (абзацы). Будет ли явная поддержка версий? Чтобы по номеру версии можно было понять изменился ли файл, а не скачивать его снова и сравнивать тексты. Вернуться к началу GribUser Автор формата FB2 - Автор библиотеки FB Зарегистрирован: 30.09.2004 Сообщения: 2475 Откуда: Москва Добавлено: Вт Июл 08, 2008 17:49    Заголовок сообщения: Mike Sinkovsky писал(а): в том виде что сейчас они не прижились Да нет, почему. Где надо - используются. Другое дело, что они слабо востребованы, ну от этого никуда не денешся. Вернуться к началу LX Главный экзекутор Зарегистрирован: 05.12.2004 Сообщения: 967 Откуда: Минск Добавлено: Вт Июл 08, 2008 19:13    Заголовок сообщения: Alan писал(а): Кстати еще неплохо было, что бы текст всего был только в пределах <p></p>... Т.е. чтобы конструкции вида <code>текст</code>, <title>текст</title> и т.д. правильно записывались в виде <code><p>текст</p></code> и <title><p>текст</p></title>, соответственно... давно пора а теперь по самому драфту: Цитата: Все файлы внутри архива имеют латинские имена в нижнем регистре. это, имхо, излишнее ограничение. все операционки давно уже понимают регистр нормально (чего, правда, нельзя сказать о юникоде или вообще отличных от латиницы алфавитов) Цитата: В корне архива может присутствовать один из файлов cover.png/cover.jpg, содержащий обложку документа для быстрого отображения. Размер этой картинки не больше, чем 240*240. Полноразмерная обложка может размещаться в другом файле (описывается в fb3_meta.xml, см. ниже). несколько нелогично. скорее можно попробовать сделать для ЛЮБЫХ картинок (как для кавера, так и для инлайна) поддержку и превьюшки и полной версии (при наличии таковой) и кавер обрабатывать на общих условиях. есть превью -- читалка выводит его. есть и то и то -- добавляем к превью ссылку на полную. есть только полная версия -- читалка рендерит ее как превью, а читатель парится и ждет Цитата: В корне архива может присутствовать файл fb3_marks.xml, содержащий заметки/закладки. блин, все бы хорошо, полезная идея. но вот хранить таким образом закладки, оставленные читалкой (не редактором, а именно читалкой) -- означает переписывать заново архив Цитата: Все прочие файлы в архиве должны быть прямо или косвенно указаны в одном из перечисленных выше *.xml-файлов (например, каждая картинка должна быть использована в документе, если она попала в архив). Наличие в zip-архиве файлов (помимо указанных выше), не описанных в документе, является некритической ошибкой. При обработке файла о данной ошибке редактор должен обязательно выдавать предупреждение. Читалка должна игнорировать лишние файлы. ты сам себе не противоречишь? с одной стороны у тебя должны, а с другой является некритической ошибкой Цитата: Ссылки на отсутствующие файлы, используемые в документах, являются некритической ошибкой. И читалки, и редакторы должны выдавать сообщение об ошибке или иным образом ясно информировать пользователя о недостающих файлах. имхо, для редактора это должна быть критическая ошибка, для читалки -- некритическая Цитата: Тег translator упраздняется Тег author в title-info получит новый атрибут role, который будет принимать значения author|translator|compiler|illustrator|editor. Тег translator упраздняется, соответственно. о, это полезно Цитата: Новый порядок тегов title-info: это же xml, ты вон xpath вовсю юзаешь. зачем порядок в данном случае? имхо, в любом порядке можно писать кстати, о порядке в фб2 насколько я помню (когда-то попробовал, не получилось, и потом не пытался) в цитате автор может быть только последним элементом, после него ничего добавить нельзя. а хотелось бы, например, так: <cite> <p>уважаемая катерина матвевна, и т.д.</p> <text-author>сухов</text-author> <p>p.s. вспомнил я, что...</p> <p>p.p.s. вспомнил я, что...</p> <p>p.p.p.s. вспомнил я, что...</p> </cite> так что может не задавать порядок следования элементов для цитат? Цитата: Блоки, выпадающие из общего потока, с атрибутами float, align, width. Возможно, с разрешенной вложенностью. Возможно, с бордерами. К примеру <block float="left" width="40em" align="right"><p>тутатекст</p></block> имхо, не надо связываться с инлайн-стилями, мы же стараемся абстрагироваться от рендеринга. атрибут типа class='class-name', имхо, лучше сюда подойдет, а уж дело читалки поймать цсс-ник, в нем прочитать имя класса, и отрендерить только то, что она отрендерить сумеет Цитата: Картинки больше не хранятся в XML, лежат в архиве, отдельно. аллах акбар! Цитата: Сноски будут типизированные. Выделяются концевые и подстраничные. Читалке желательно отображать сноски соответственно. имхо, это лишнее. по большому счету здесь нет четкой разницы. или же придется вводить жесточайшие правила для редакторов: каким типом сносок когда пользоваться. писатели же читалок (не будем показывать пальцем) по своей лени, скорее всего, оба типа сносок будут все равно показывать одинаково Цитата: Сноски выделяются в отдельный section (или в несколько), и отделяются друг от друга не секциями, а новым тегом <note> а сделать что-нить вроде <section type="note">? Цитата: fb3_marks.xml содержит закладки – указывается адрес закладки (с точностью до символа, отмечается начало выделения и конец), тип закладки (закладка, заметка, правка). Адресация с использованием xpointer, в закладке может содержаться текст, аналогичный содержимому секций. прекрасно, но см. выше по поводу закладок. редактор может и переписать архив заново при добавлении закладки. для читалки это все-таки непозволительная роскошь, тем более для наладонников --- как-то так, сильно ногами не бей, я сегодня спал часа три и не очень вменяем _________________ disinformation must be free! Вернуться к началу sorotokin Новенький участник форума Зарегистрирован: 26.05.2008 Сообщения: 7 Откуда: San Jose, CA Добавлено: Вт Июл 08, 2008 19:34    Заголовок сообщения: 1. Возможность разбивки на секции и вынос картинок в отдельные файлы в zipе - по-моему очень правильно. 2. Вместо атрибутов float, width, etc. - лучше не смешивать семантику и презентацию, а стандартизировать, как работают стили (CSS). Вовсе не обязательно поддерживать все возможные селекторы: например можно ограничится атрибутом class="name" и селектором .name. Может, добавить tag и tag.name. Такой stylesheet легко обработать. Точно так же, не обязательно поддерживать все возможные properties в CSS. 3. Подумайте, не вставить ли элемент для альтернативных форматов. Скажем Код: <object required-namespace="http://www.w3.org/1998/Math/MathML" xlink:href="f1.xml"> <img xlink:href="f1.png"> </object> Единственное, что должны делать все читалки - правильно отображать содержимое всех тэгов object, которые они не понимают. Формулы, графики, чертежи и ноты отображать только картинками - плохо. С другой стороны, требовать от всех читалок понимания специальных форматов - нереально. Может, это правильно и для таблиц. Добавлено спустя 19 минут 16 секунд: Формат закладок c точностью до буквы - это правильно. Должна быть возможность обработки внешних закладок. Для этого нужно всегда указывать в файле закладок данных самой книги, чтобы можно было понять какой файл относится к какой книге. Xpointer может быть черезчур многообразен, по-моему. Формат указателя на текст должен быть очень жестко определен. Желательно также, чтобы была возможность сохранять только небольшое количество информации в конвертированом из FB3 файле для привязки произвольных FB3 закладок, даже, если исходник FB3 недоступен. В закладке нужно иметь возможность указать метаданные самой закладки (дата создания/модификации, автор) и её идентификатор (чтобы можно было слить вместе два файла закладок, полученные из одного независимым редактированием). Вернуться к началу GribUser Автор формата FB2 - Автор библиотеки FB Зарегистрирован: 30.09.2004 Сообщения: 2475 Откуда: Москва Добавлено: Вт Июл 08, 2008 21:33    Заголовок сообщения: LX писал(а): все операционки давно уже понимают регистр нормально Но не все понимают "нормально" одинаково. LX писал(а): означает переписывать заново архив Ну пусть рядом хранит, в архив их можно на любом этапе запихнуть. Никто ж отдельно этим закладкам жить не запрещает, но книга может успешно тащить их за собой. LX писал(а): с одной стороны у тебя должны, а с другой является некритической ошибкой Это из серии того, что сейчас редактор позволяет сохранять невалидный файл. В библиотеку такое не примет, а в качестве промежуточного варианта - почему нет? Редактор все-таки не валидатор, у него другие функции. Но такой файл является совершенно невалидным при этом. Вот такая логика где-то. LX писал(а): имхо, для редактора это должна быть критическая ошибка, для читалки -- некритическая Не, валидация - одна из функций редактора, далеко не единственная. LX писал(а): зачем порядок в данном случае? имхо, в любом порядке можно писать Чтоб можно было в читалке в порядке появления тегов отображать, в xslt тож можно будет некоторые вещи попроще оформить. LX писал(а): мы же стараемся абстрагироваться от рендеринга. Ну не то, чтобы мы СОВСЕМ старались абстрагироваться. Мы стараемся выделить абстрактные типы рендеринга, а такой тип, как "иллюстрация с обтеканием" вполне себе имеет место быть, это уж почти логическая конструкция - отображает взаимное отношение фрагментов книги. LX писал(а): по большому счету здесь нет четкой разницы. Как минимум часто встречается случай, когда идет два параллельных потока сносок, которые надо как-то разводить. При таком подходе проблема достаточно прозрачно решается. Можно типизацию сделать необязательной, чтобы разводить только то, что в разводке нуждается, а прочее оставить на совести настроек программы. LX писал(а): а сделать что-нить вроде <section type="note"> Практика показала, что этот section с обычным секшном общего ничего не имеет в итоге. Нефига их и объединять, я так мыслю. Это что касается очевидного и мною уже всесторонне обмысленного. Остальные вопросы я плотно обдумаю. sorotokin писал(а): Вместо атрибутов float, width, etc. - лучше не смешивать семантику и презентацию В данном случае это семантика. Если в учебнике есть иллюстрация, под ней подпись и рядом - поясняющий текст, это семантика в дистилированном виде. Вот ее и надо как-то поддерживать. Возможно сформулировать не float, а более наукообразно, но есть книги, где взаимное расположение фрагментов является неотъемлемой частью, для таких книг это и вводится. sorotokin писал(а): Подумайте, не вставить ли элемент для альтернативных форматов Есть шальная идея картинки оформлять аналогично, разводя тип контента по mime-type, в 3.0 стандартизировать поддержку базового набора (скажем, png, gif, jpg, svg), а в 3,01 допустить использование произвольных типов... Но произвольные типы, мне кажется, это ерунда. Вот поддержку флоатов или там svg я и ЛитРес, допустим, планируем обеспечить. Но вот мы стандартизируем MathML, и чего? Кто его будет воплощать? Стандартизировать можно и XHTML для секций, не вопрос, тока кто будет потом поддержку-то всего этого осуществлять? sorotokin писал(а): Xpointer может быть черезчур многообразен, по-моему. Формат указателя на текст должен быть очень жестко определен. Да не особо и многообразен... В любом случае можно подмножеством для 3.0 ограничиться, разрешить только адресацию по индексу, без сложных там селекторов, осей навигации и прочего. sorotokin писал(а): В закладке нужно иметь возможность указать метаданные самой закладки Кстати да, это прально. Вернуться к началу sorotokin Новенький участник форума Зарегистрирован: 26.05.2008 Сообщения: 7 Откуда: San Jose, CA Добавлено: Вт Июл 08, 2008 22:32    Заголовок сообщения: Цитата: Если в учебнике есть иллюстрация, под ней подпись и рядом - поясняющий текст, это семантика в дистилированном виде. Вот ее и надо как-то поддерживать. Ну так так и надо поддерживать тэги для иллюстрации, подписи и поясняющего текста. Sidebar box в учебниках - вполне себе семантика. Но width и border - нет. Даже обтекание - это не более семантика, чем, скажем, жирный шрифт. Для карманного издания, например, вряд ли обтекание будет использоваться для выделения фрагмента текста. Цитата: В любом случае можно подмножеством для 3.0 ограничиться я это и имел в виду. Вернуться к началу GribUser Автор формата FB2 - Автор библиотеки FB Зарегистрирован: 30.09.2004 Сообщения: 2475 Откуда: Москва Добавлено: Ср Июл 09, 2008 13:27    Заголовок сообщения: sorotokin писал(а): Sidebar box Ну я в общем-то где-то это в виду и имел, но сформулировал неудачно, согласен. Хотя просто обозначить "Sidebar box" это не очень функционально, как без ширины на практике обойтись я пока не представляю. Хотя в целом правы скорее вы, чем я, как это "правильное" на практике делать я плохо представляю. Вернуться к началу LX Главный экзекутор Зарегистрирован: 05.12.2004 Сообщения: 967 Откуда: Минск Добавлено: Ср Июл 09, 2008 16:38    Заголовок сообщения: GribUser писал(а): Не, валидация - одна из функций редактора, далеко не единственная. ну я примерно это и имел в виду -- т.е. редактору таки позволять сохранять файл, конечно же, но орать во все горло, что он неправильный, и либа его не всосет а фактически давно пора при валидации просто ввести два вида сообщений -- warning и error, потому как кое-какие вольности в документе вроде как формально позволены, но делать их все равно не стоит. правда, это вопрос уже не к формату GribUser писал(а): в xslt тож можно будет некоторые вещи попроще оформить. так в результирующий файл они будут выводится в том порядке, в которм они прописаны в xslt, а не в исходном документе, т.е. я пишу шаблон вида <xsl:template match="title-info"> <div> <xsl:apply-templates select="./coverpage"/> <xsl:apply-templates select="./book-title"/> <xsl:apply-templates select="./book-sub-title"/> и т.д. </div> </xsl:template> <xsl:template match="book-title"> <h1>блаблабла</h1> </xsl:template> <xsl:template match="coverpage"> <img src="блаблабла" /> </xsl:template> <xsl:template match="book-sub-title"> <h2>блаблабла</h2> </xsl:template> и т.д. и именно в таком порядке, как в apply-templates (1 - coverpage, 2 - book-title, 3 - book-sub-title) все и выводится на выходе. а в исходнике вполне может идти book-sub-title, потом book-title, потом coverpage, селекту-то глубоко похрен порядок да, если там ОЧЕНЬ критична скорость, и все крутится в длинном цикле, то селекты надо делать вида "./[1]", "./[2]" и т.д. -- оно будет быстрее, несомненно, но я думаю, что тут такая оптимизация не нужна GribUser писал(а): Чтоб можно было в читалке в порядке появления тегов отображать а ведь читалка приблизительно такой же механизм, как xslt, и должна юзать (по уму она должна юзать именно xslt ) так что подумай-таки про отказ от жесткого порядка но это так, лирика, некритично GribUser писал(а): Есть шальная идея картинки оформлять аналогично, разводя тип контента по mime-type о, это здравая мысль GribUser писал(а): как без ширины на практике обойтись я пока не представляю в данном случае позволить читалке решать. если там картинка во врезке -- минимальная ширина все равно определяется картинкой. если же только текст, то читалка проставляет какое-нить свое дефолтное однообразное значение, скажем, 30% от ширины экрана _________________ disinformation must be free! Вернуться к началу Показать сообщения: все сообщенияза последний деньза последние 7 днейза последние 2 неделиза последний месяцза последние 3 месяцаза последние 6 месяцевза последний год Начиная со старыхНачиная с новых         Список форумов www.fictionbook.org -> Перспективы формата FB Часовой пояс: GMT + 3 На страницу Пред.  1, 2, 3, 4, 5 ... 12, 13, 14  След. Страница 4 из 14   Перейти: Выберите форум Информация и новости----------------Вопросы и предложения по порталу поддержки формата (FictionBook.ORG)Библиотека FictionBook.Lib (Fictionbook.RU)КнигиНа чем читаемFictionBook и капуста Формат FictionBook----------------Основы формата FBПерспективы формата FBСделано для FBFB - разработка и программированиеИспр@влено For English Speakers----------------FictionBook Format  Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах Powered by phpBB © 2001, 2005 phpBB Group