PDF is dead. Or is it not?

[rlauzon]

Originally Posted by Hadrien

Hyphenation is linked to the screen size, so it has nothing to do with the program that created the RTF file.

Huh? Hyphenation has little to do with the screen size - just in determining if the word should be hyphenated when flowing the text. Where the hyphen goes is determined by the eBook file. I've seen this time and time again (especially in RTF files).

Originally Posted by Hadrien

RTF doesn't support embedded fonts, do you believe that each and every book in your library use the same font ? They don't.

I believe that the content of the eBook and the font shouldn't be linked.

Again, you are thinking in terms of paper today. Not what eBooks should be.

Wouldn't it be nice to have an eBook where you (the reader) could select the font to use? Older people could choose a larger font to make it easier to read. Younger people could choose a smaller font to get more information on the screen. But it can be left up to the reader to determine what the correct font/size it.

Originally Posted by Hadrien

Maybe YOU just need simple features and a poor formatting system, but I don't believe that's the case for everyone.

First we need to satisfy 80% of the market. That will make eBooks the norm and get more innovation out there. Then we can deal with the other 20% that need more.

Originally Posted by Hadrien

If you really believe that RTF is perfect and that PDF is the devil, well then good for you...

I have neither said nor implied that RTF is perfect, or that PDF is the devil.

I have stated that:
1. PDF completely fails as an eBook format because of its page-oriented mentality.
2. RTF is a better solution than PDF because it isn't page-oriented, but allows for more formatting than plain text.

Originally Posted by Hadrien

I'm looking forward for something both portable and powerful, but I know that it'll be hard to make such a format.

HTML and OpenDocument already exist.

Originally Posted by Hadrien

In the meantime, I believe the best solution is to store books in a database or using XML, and create files out of it (some editors use LaTeX already). Keeping all these books in a single text file (TXT or RTF) is the wrong choice, you need to know where the chapters start and end for example if you want something ready for any advanced format. With such a system you can create what you call "absolute positioning" in a relative way: each device and each person can have his/her own formatting. You can also create pure text files out of it, but that would be like downsampling an audio file. When and if a powerful XML format become available, the same system will still work, creating just another kind of files as an output.

So what you are proposing is what I said before:
Keeping the eBook in Format-X then producing something like PDF when the user wants to read it, formatted for the device the user wants to read it on.

I am questioning why that's a good idea. Why make an eBook reader that uses closed, proprietary formats? Why not just have the eBook reader process Format-X in the first place?

[rlauzon]

Originally Posted by Hadrien

Users shouldn't be the one customizing anything. There's a whole lot of people that are used to tech around here, but that's not the case of a more mainstream public. A service should customize automatically e-books for the users, or even better there shouldn't be any customization at all (but we don't have the format and software for this yet).

Ahhh... Now I understand where you are coming from.

Since I will never agree with the Content Cartel's position that all content should be locked up and consumers should never have the ability to modify content for their use, I can stop wasting my time on you.

I'll end this by saying that your stand that "Users shouldn't be the one customizing anything" is completely wrong and goes against what content consumers want today. Making content that cannot be customized by the consumer eliminates all value from the content.

[Hadrien]

"Content Cartel" haha... I'm talking about ease of use, not keeping something closed. That's why I said that eventhough BBeB is pretty good, it should be more open source to be more widely used.
User should be able to customize the content, but if it's necessary to modify the content on the user side to make it usable, then it's really wrong.

RTF and HTML are not better than PDF for e-books, they all have their own issues.
An e-book format should be based around the elements that a book is made of: if you don't know where a chapter start and end, and you just got something like a bolder font for the chapter name, well you won't be able to make anything out of it (or maybe create regexp and some kind of robot to scan each and every book ? That's stupid...). But if you have something like <chapter> </chapter> wrapped around it, you can easily create a TOC, make it really easy to create another file in a different format out of it, enable the user to easily customize the book etc... Plain text files, and storing your book using absolute formatting is both wrong: you need to store important informations about the book and then format it with advanced features. I see PDF files as an output for one of these XML based formatting using "book tags", instead of "formatting tags". You could easily do such an output for HTML too but it would be limited compared to the PDF output. Basic formatting and book elements should be based on an XML format, and advance formatting, how the book looks and feels should be somehow similar to CSS stylesheets, you could use different "themes" for every content.

PS: Added a quick example of something that I could output on Feedbooks.
The PDF example is here: http://www.feedbooks.com/discover/view_book/35

[NatCh]

Originally Posted by rlauzon

I'll end this by saying that your stand that "Users shouldn't be the one customizing anything" is completely wrong and goes against what content consumers want today. Making content that cannot be customized by the consumer eliminates all value from the content.

I think he means that users shouldn't have to be the ones customizing stuff, rlauzon.

[mogui]

Free Software Magazine has three articles on this topic in their latest issue. See:

Making PDFs with free software
http://www.freesoftwaremagazine.com/blogs/making_pdfs

Paper is dead - has PDF followed suit?
http://www.freesoftwaremagazine.com/...s/editorial_16

So, why has the PDF gone?
http://www.freesoftwaremagazine.com/...s_the_pdf_gone

[Steven Lyle Jordan]

Originally Posted by Hadrien

Users shouldn't be the one customizing anything. There's a whole lot of people that are used to tech around here, but that's not the case of a more mainstream public. A service should customize automatically e-books for the users, or even better there shouldn't be any customization at all (but we don't have the format and software for this yet).

Actually, there IS something that will allow the customer to view their doc any way they want: HTML. Make a reader that uses browser software, whatever your screen size or type is, it will be read, your problem's done. Others have already realized this, and are working on HTML- or XML- based standardized formats even now.

Sure, there should always be an "easy way" for consumers who don't want to be bothered how to work a few buttons. On the other hand, these users already use browsers, cell phones, MP3 players, and they can and do customize them with skins and tones... they're not completely daft, and don't need to be treated as such. They can handle a little customization. You can always help 'em out by automating the customization process through a GUI, and making it as simple as selecting a few options and clicking on "Go."

[Hadrien]

Originally Posted by Steve Jordan

Actually, there IS something that will allow the customer to view their doc any way they want: HTML. Make a reader that uses browser software, whatever your screen size or type is, it will be read, your problem's done. Others have already realized this, and are working on HTML- or XML- based standardized formats even now.

Sure, there should always be an "easy way" for consumers who don't want to be bothered how to work a few buttons. On the other hand, these users already use browsers, cell phones, MP3 players, and they can and do customize them with skins and tones... they're not completely daft, and don't need to be treated as such. They can handle a little customization. You can always help 'em out by automating the customization process through a GUI, and making it as simple as selecting a few options and clicking on "Go."

No one's working on including HTML support, it's mostly about new XML based format these days, something much more specialized for e-books in this case. There's a lot of issues with HTML standardization these days, just take a look how web browsers support and render HTML in different ways. The real goal here is not only to create a standard for viewing e-books, but also something really easy to process. If the core of your format is based only on formatting like HTML, you won't be able to extract information or customize your book as easily. It's much easier to pull and filter out information from RSS for example.

[mogui]

Originally Posted by Hadrien

No one's working on including HTML support, it's mostly about new XML based format these days, something much more specialized for e-books in this case. There's a lot of issues with HTML standardization these days, just take a look how web browsers support and render HTML in different ways. The real goal here is not only to create a standard for viewing e-books, but also something really easy to process. If the core of your format is based only on formatting like HTML, you won't be able to extract information or customize your book as easily. It's much easier to pull and filter out information from RSS for example.

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?

[jæd]

Originally Posted by mogui

HTML does all that and most people understand it.

People understand it now, but what about the future... I agree with Hadrien... If you have content its best to keep it in as marked-up xml. That way you can pick and choose your format later...!

[Hadrien]

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).