Quote:
|
Originally Posted by mogui
I can appreciate that your comments come from a depth of understanding I do not have. You are probably right in what you advocate, but my comfort level about reader compatibility would be greatly increased if they would include an HTML rendering engine. I would hope they would standardize on the same one. Then I could use a lot of my current files. I could mark-up my txt files to give me the text appearance I want, and I could at least have a horizontal rule between chapters. It is not a difficult thing to do, and it would solve so many problems. I would like the rendering engine to be in the reader of course. One could even use it to display plain text.
I like the comments to the effect that we need to draw our text from a database and include markup for the things that make the text more readable. We need an easy way to massage and store the great mass of material we already have. HTML does all that and most people understand it.
So can we do both?
|
I'm 100% for the support of HTML on reader devices. With this e-babel on our hands, we need devices that can support many different formats.
I'm just pointing the fact that storing something using HTML is not the right choice, we need to store books with just basic formatting informations and informations about the structure of the books (database or XML). This way you can generate any file out of it, using LaTeX for example, or any formatting option in the future. You can generate HTML or RTF with such a system too, and there's many interesting points about it, mostly the fact that you can manipulate this kind of data easily, this could for example improve searching (looking for a book with a chapter name "ABC", well then we'll just search for this chapter in the database (or using <chapter>) instead of scanning the whole text and somehow trying to guess where "ABC" is a chapter.
Take the example of a RSS feed: same data, but it'll look different on your mobile device, ajax home page etc... Sometimes you don't even know there's RSS behind it. Content and formatting are two things that should be different, yet if we separate them, we'd better use something really powerfull to format the content the best way. E-books lack the feeling of a real book, we don't have a real cover, you lack the physical attachment to the product, that's why they should provide a great experience when it comes to formatting. PDF may not provide reflowable text and something really easy to customize the text, but that's mostly because that's not the goal for such a format. As long as you have the structure of the book with basic formatting, you can create really advanced stuff using PDF that another format wouldn't provide for the moment.
The future will be the ability to read directly these basic datas about the book on your reader, and render them using stylesheets (like CSS): for example if you like Arial for chapters and Times for the text, you'll have a separate file with something like:
chapter{
font-family:Arial;
font-weight:bold;
}
text{
font-family:Times;
font-weight:normal;
}
The idea behind this is pretty close from XHTML+CSS, I'm just pointing to the fact that we need a markup-language that's much more content-oriented than format-oriented. With content-oriented representation of a book, we can do so much more out of the content, make everything much more portable, ready for the Web and customizable. The rise of RSS is just the beginning of the divorce between content and its representation, we'll see more and more support for XML based solution (REST for example is great for mobile devices, web services using Ajax on a mobile device is pretty hard, using REST and for example some Java app would enable a much smoother experience).