| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
rsperberg
Новенький участник форума
Зарегистрирован: 20.01.2006
Сообщения: 15
|
 Добавлено: Ср Янв 25, 2006 1:17 Заголовок сообщения: FictionBook 3.0 |
 |
|
In a different thread, I wrote (apologies for not knowing how to link to it): | Цитата: | I have several suggestions and requests for the next version of FictionBook as a format. What's the best way to raise issues about the format?
For instance, it would nice if an FB2 file could include a short name that the e-reader could use in its header or title bar. Here's a picture that -- by virtue of a too-long name -- illustrates what I mean:
|
I thought I would put down my thoughts about the FictionBook format here, with suggestions for how it might be improved in its next version.The above is a simple, specific request, for a single element. The other things listed here propose larger changes.
I am new to the FB2 format, and it may be that I have missed aspects of the format in my short education, especially regarding the design principles for files. Point me to the information I need to know where something already exists, please!
And I do understand that adding elements to the FictionBook format requires e-readers to add new rendering capacities as well as to be able to differentiate between FB2 and FB3 if there are changes to the existing elements. That, of course, is true with any application and its files, but I recognize that the file creators and the application creators (of the e-readers) are two separate sets of people and these suggestions put most of the burden on those application creators.
If I didn't think the benefits would outweigh the efforts required, I wouldn't make these suggestions. But I do, so here they are:
- The first thing I feel is missing is a structure for lists.
I know from experience publishing books directly out of XML to PDF that building a bullet-proof list framework is a major task. Still, something on the level of list support in XHTML would be useful I think. Moreover, it allows the markup to better reflect the structure of the text. Just as a poem is not really a lot of p elements, neither is a list (and of course, some list items would be more than one paragraph long).
- The second thing I think would benefit readers (the human kind) would be to extend linking.
I think FictionBook should permit hyperlinks to other books in the current library or to URLs on the web. It is an electronic book, after all, being read on a computer or handheld device with a CPU in it. Shouldn't texts in the FB format include links to resources on the web? Lots of programs can can launch the default browser, open a window and supply the URL for loading. If FictionBook permits it, an e-reader can implement the feature or choose the fallback of ignoring external links.
With a link to another book in the installed library, there will need to be a way to unambigously refer to the other book. Very possibly the current identifier can be used; perhaps instead a URI-like identifier ought to be required (I haven't looked to see what Xlink allows). Note that this doesn't require an e-reader to open two books simultaneously (can any FB2-capable e-readers do that now anyway?), but just to close the current book, open the linked-to book, and jump to the referenced anchor. And, again, e-readers have the fallback of ignoring the link if this feature isn't implemented.
- FB3 should permit Flash and/or SVG files to be called and played if the e-reader has a plugin. Audio files in MP3 and/or other specified popular formats.should also be able to be called.
Well, the same argument applies here as above -- if books are electronic, why shouldn't they take full advantage of being electronic? I don't expect e-readers to be browsers or to exceed browsers' capabilities, but can't we expect e-readers to approach browsers' capabilities? It's been TEN years since Flash came out after all.
Macromedia has long made it easy to create a Flash plugin for any kind of program. But if an e-reader can't play a Flash file then the FB specification will have to require the file creator to supply a fallback -- maybe this will be one or more images with text that is only displayed when there's no Flash capability.
With an audio file, perhaps the plugin approach would work best, in which the audio capability is internal to the e-reader. Or perhaps the e-reader would launch an external audio application, similar to the way it would launch the browser when a web link is encountered.
In the current format, images are included as base64-encoded text. I don't know if this is practical with Flash or music files. This might require the format to accommodate external files, accessing them if they are in the same directory as the FBfile, or in the same zip archive.
- Lastly, I suggest that FB3 allow outside namespaces.
I'm thinking of four specific instances -- Docbook, TEI, MathML and XHTML tables.
If, for instance, an e-reader had a plug-in that allowed it to render text marked up in the Docbook format, I would like to be able to include hunks of that Docbook title in my FictionBook file without having to change the markup.
What FB3 would have to allow is a way to identify any Docbook element and what FictionBook element it should map to for those e-readers that lacked such a plugin. So maybe the description section should have an additional, optional part called mappings, where this information could be placed. Any element not in the map would fall back to the p element for rendering or be ignored.
Similarly with TEI or any other namespaced markup vocabulary.
With MathML, the fallback might more likely be an image of an equation, and consequently, I think it would have to be mentioned explicitly in the specification.
We might be getting pretty far from FictionBook with MathML, but I do think this makes the format more flexible in a worthwhile way. Of course, it doesn't really work unless e-readers can parse and render MathML. (Since I'm not going to build an e-reader, I'm pushing this from something of a theoretical standpoint, whereas every other suggestion comes from a wish to include such features in the texts I prepare.)
I note the simple table markup in FB2. Rather than duplicate the elements of the two standard table systems (CALS and XHTML), I suggest incorporating all or part of XHTML into FB3 using namespaces, similar to the way Xlink was brought in for linking. The spec might specify only a subset of elements and attributes, or it might deprecate certain usages or complexities -- for instance, tables within tables might not be permitted,. But any way you look at it tables are really, really necessary to present certain kinds of information concisely.
Lots of web pages use tables for precisely locating objects or text on the page; to avoid this kind of formatting within the content file, perhaps a table would only be allowed as a child of a certain element (the "tableholder"), and could not contain a section element.
---
These are my initial suggestions, and they definitely pull at the FictionBook format to become something much larger than it must have been conceived.
I will cross-post this list of suggestions to the MobileRead.com FBReader forum, where further suggestions may be made. My apologies for putting such major suggestions in the English-language forum of this site. I will depend on others to move the discussion to the appropriate Russian-language forum -- and to bring back the best responses and further suggestions here, so I can see them.
Thanks,
Roger Sperberg |
|
| Вернуться к началу |
|
 |
GribUser
Автор формата FB2 - Автор библиотеки FB
Зарегистрирован: 30.09.2004
Сообщения: 2475
Откуда: Москва
|
| Добавлено: Ср Янв 25, 2006 4:47 Заголовок сообщения: |
|
|
woof... too match for me for today.
Just make sure you understand the purpose of the format. it is not meant to replace rtf, xhtml or docbook. It's supposed to display FICTION books on ANY device out there. Adding lists, svg, mathml and the whole thouse things is just a way to get xhtml clone. We have one already, no need to make another one, the first is quite cool already.
bts current fb2 architecture allows mathml as well as svg to be used - just use binary to attach a file and img to display. Thou no reader|converter will show the contents. So why worry about them? |
|
| Вернуться к началу |
|
|
rsperberg
Новенький участник форума
Зарегистрирован: 20.01.2006
Сообщения: 15
|
| Добавлено: Чт Янв 26, 2006 3:25 Заголовок сообщения: |
|
|
| GribUser писал(а): | | woof... too match for me for today. |
Sorry -- I got carried away. 
| Цитата: | | Just make sure you understand the purpose of the format. It is not meant to replace rtf, xhtml or docbook. It's supposed to display FICTION books on ANY device out there. Adding lists, svg, mathml and all those things is just a way to get xhtml clone. We have one already, no need to make another one, the first is quite cool already. |
Ah, well., I personally don't think Docbook is so good for an e-book reader, nor do I think XHTML is really a good match for how books are structured, nor for handling all the metadata necessary.
What I think is that FictionBook could provide a mechanism to extend itself without duplicating those other vocabularies and yet utilizing them when it's useful.
| Цитата: | | btw current fb2 architecture allows mathml as well as svg to be used -- just use binary to attach a file and img to display. Tho no reader|converter will show the contents. So why worry about them? |
MathML and SVG are XML vocabularies -- they're not binary files at all. I presume you're just saying "transform them into an image and insert them that way into the FB file." They wouldn't be editable, but then neither are current images. |
|
| Вернуться к началу |
|
|
Admin
Администратор информационного портала FB
Зарегистрирован: 11.06.2004
Сообщения: 1610
Откуда: Воронеж
|
| Добавлено: Чт Янв 26, 2006 8:54 Заголовок сообщения: |
|
|
| rsperberg писал(а): | | What I think is that FictionBook could provide a mechanism to extend itself without duplicating those other vocabularies and yet utilizing them when it's useful. |
I think, that in the future expansion of format FictionBook will be carried out due to additional schemes. Thus the basic scheme, as well as will cover now fiction. |
|
| Вернуться к началу |
|
|
GribUser
Автор формата FB2 - Автор библиотеки FB
Зарегистрирован: 30.09.2004
Сообщения: 2475
Откуда: Москва
|
| Добавлено: Чт Янв 26, 2006 15:56 Заголовок сообщения: |
|
|
| rsperberg писал(а): | | MathML and SVG are XML vocabularies -- they're not binary files at all. |
Does not matter, they are just 10010010111001 sequences after all for any way and could be put in separate files, base64-encoded and inserted in fb2. Just like png. If there is anybody willing to support svg today he could start right now. As soon as the feuture will become usable at all (and if) we will think about including it in the standart itself. If you do not like base64, use separate namespace. Library will rejuct such a file (it has no idea about how to handle svg for any way), but you still can create a converter and standard will follow THEN.
The feauture requests from users familiar with the words like "svg, mathml" were submited many times here. But there are no developers willing to add this feuture in a REAL product. So we are waiting to the one who will not only know svg word, but will make a reader with svg support for at least two platforms. And a converter for at least html. And then we will proceed. |
|
| Вернуться к началу |
|
|
rsperberg
Новенький участник форума
Зарегистрирован: 20.01.2006
Сообщения: 15
|
| Добавлено: Чт Фев 02, 2006 21:12 Заголовок сообщения: |
|
|
| GribUser писал(а): | | The feauture requests from users familiar with the words like "svg, mathml" were submited many times here. But there are no developers willing to add this feuture in a REAL product. So we are waiting to the one who will not only know svg word, but will make a reader with svg support for at least two platforms. And a converter for at least html. And then we will proceed. |
Yes, lots of requests are just people repeating buzzwords.
Or just repeating features that they have in browsers like Firefox and Opera.
But if people don't voice what they want, how will developers know what features to add and please users? |
|
| Вернуться к началу |
|
|
rsperberg
Новенький участник форума
Зарегистрирован: 20.01.2006
Сообщения: 15
|
| Добавлено: Вс Мар 12, 2006 23:10 Заголовок сообщения: |
|
|
| Admin писал(а): | | I think, that in the future expansion of format FictionBook will be carried out due to additional schemes. Thus the basic scheme, as well as will cover now fiction. |
I've been thinking about this for a while. I have to admit that this approach makes a lot of sense.
It raises a few questions for me. Who is responsible for deciding what an additional schema would include?
How do you see these additional schema working with FictionBook? For purposes of discussion, if you were to create a "TechnicalBook" schema that included a code element, would the basic idea be to include that schema as a namespace and text in a FictionBook file would be marked with something like tech:code? Or would there be complete separation? That is, TechnicalBook files would be standalone, with no reference to FictionBook elements.
I also wonder how elements from non-FictionBook-created schemas might be formally recognized as suitable for FictionBook-compliant e-readers to render. I'm thinking of XHTML and the various tags that make up lists and tables.
If I recall correctly, it was pointed out somewhere else that there's nothing preventing an e-reader to support such expansion currently. But as a reader (or user of an e-reader), I don't have any say in the matter; the program either will or will not support it. With the expansion via schemas you describe, the base for markup could be expanded to let FB files include XHTML sections as a matter of course -- or at least those parts of XHTML that represent markup structures not available in FictionBook. |
|
| Вернуться к началу |
|
|
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
|
Powered by phpBB © 2001, 2005 phpBB Group
|
POCKET 
WIKI 
FAQ 
Поиск 
Пользователи 
Группы 
Регистрация 
Профиль 
Войти и проверить личные сообщения 
Вход
