With already over 350 carefully styled and handmade e-books for the Sony Reader, and brought to life less than 2-1/2 months ago, the Book Upload section (http://www.mobileread.com/forums/forumdisplay.php?f=126) has been a phenomenal success. My personal thanks to everyone who has been so fervently contributing up to today! :2thumbsup

It's now about time to expand the uploads with formats for other e-book readers. Please take a second to participate in the poll which we will use as an indication how you'd like us to expand the forums. Thanks!

Hint: This is a multiple choice poll.

Books for the iLiad only make no sense. It would be Mobipocket format which is available for many devices.
What we definitely need is the HTML source for the handmade books already available. Ideally with projects to convert them to multiple formats.

I like the idea of multiple formats. Providing HTML source code is nice, but it alienates those who would love to have the books, but cannot/will not do the conversions themselves. Why not make multiple formats available?

As the Delphi-Guy said, iLiad uses mobi so if we added another forum for that format it would serve multiple devices. The same reasoning supports the addition of an area for PDB (which in itself can also be used by those that use mobi.)

It seems to me that HTML runs counter to the logic of offering books that people can just load and go. I can easily convert all that I have already uploaded to the Sony area to another format and make them available.

I was assuming the iLiad formatted books would be PDF, I guess. :shrug:

MOBI format is all I need, it can be read using MoibiPocket's Reader software on many devices and FBReader on Linux (and Windows XP). Another possibility would be LIT, since many folks will have a procedure for getting .lit files onto their reading device already.

I was assuming the iLiad formatted books would be PDF, I guess. :shrug:
Assume nothing. (OK, it was a catch phrase from the film Desk Set.)

There is no reason that we cannot do custom PDFs for the iLiad. Feedbooks.com already does that and has many of the titles that are available in LRF format here at MobileRead for the Sony.

Perhaps it'd be better to upload the books to FeedBooks for processing into Custom PDFs? Hadrien's put a lot of effort into that rascal, and I know we aren't out to steal any thunder.

Maybe we could then add a link to Feedbooks to point folks there for PDF formatted books, or some such?

Yes, that probably would make more sense.

I was wondering why that wasn't the case for the Reader, as well, but I guess it's the custom LRF format.

Perhaps it'd be better to upload the books to FeedBooks for processing into Custom PDFs? Hadrien's put a lot of effort into that rascal, and I know we aren't out to steal any thunder.

Maybe we could then add a link to Feedbooks to point folks there for PDF formatted books, or some such?

I think Feedbooks works very well as a complimentary source for e-books. Feedbooks has an automated backend that Hadrien is constantly improving, whereas for example the e-books that have already been uploaded for the Sony Reader here are very unique and custom-crafted. The advantage is that we can discuss and comment these uploads and constantly improve them.

So I would definitely favor to built upon what we've already created through the upload section for the Sony Reader.

Well... I guess that in some case, handmade books are quite different from what we provide with Feedbooks. But we're not doing a simple conversion like manybooks either. The goal of Feedbooks is to provide the best machine made formatting, and we'll be working on the same goal with XML-based formats too (we won't be able to do advanced typesetting but we'll focus on good looking chapter headings, TOCs, real footnotes etc...).

Feedbooks is basically a "black box" and we'll provide more outputs, and a more flexible input for it in the future.
Things we're working on:
- recommendation system: we're planning on doing personnal recommendations, based on what you have in your favorites
- synchronize: we're building a small app to synchronize our content for your e-ink device ( http://blog.feedbooks.com/?p=3 ). We would like to do an app directly on the iLiad too that would let you browse and download content using your iLiad (I can do C and GTK, but I'm still missing a development device, iRex people aren't answering at all)
- formats: better RSS support, the last few improvements that we need for PDF support, Open E-book support. Output isn't limited to e-book formats, we'll support e-mail and maybe mobile phone related features too. We already implemented Text To Speech with mp3 output, but weren't satisfied by the result of the open source software we were using (if we find the right TTS engine, we'll open this feature to the public).
- input: working on an XML format for input. This way you'll be able to use your blog and publish your own book on it (you post the chapter on your blogs, and with a plugin, it'll generate the right format for us to format everything and publish your book in all the different formats supported).
- news widgets: we'll add more and more widgets for the news part of the website. We'd like to create something else than just a PDF files with a bunch of RSS feeds in it, something closer to Netvibes and all these Ajax homepages, but for e-ink readers.
- social stuff: we're working on a Facebook application that'll show your favorite books on your profile. We'll do "dedicated e-books", you'll be able to add a small message in an e-book and send it to a friend.

Some of the users on this forum added books on Feedbooks, and yes, once someone added a book on Feedbooks, it's available for both the Sony PRS-500 and the iLiad (+ customized PDF too). We can't exactly cut and paste, or use a bot like most websites in order to build our database. We need to divide books into parts/chapters/sections and this can't be done without a bit of human work so help is appreciated.

I voted for adding both, a section for the iLiad in particular and a section for uploads in general formats. Why? Because for the reason mentioned by Steve Jordan. It's makes a huge difference whether you must download a text and first convert it, or whether you can download immediately and install it on your device with the perfect settings.

The Sony Reader uploads section rocks, and I cannot see why it shouldn't be the same for the other upload sections.

But... I have one suggestion:
On the frontpage, remove uploads from the "Latest Forum Activity" section. Instead add a new section specifically for latest e-book uploads. This way we can track both more easily, user threads and user uploads.

Since we're living in the shadow of EBabel, it would only be fair to allow multiple choices. Let's not forget expansion for the other formats that will be imposed on us too. And that format that will unite us all has not been born yet.

Although I chose to provide books in different formats, I would love to contribute PD books for the Sony reader as well as other formats. Is there a consolidated tutorial for cleaning up the text? Sometimes I get unwanted or excess spaces, no space between words, or deleted special characters (like an accented "e" missing). All the books uploaded so far are so well done and I don't want to embarass myself.

Ellen

almost everyone else that i know reads on a fancy palm

Since the iLiad had Mobipocket for it, just make the conversions for it in PDB format and then the palm types can read it as well. LIT format is good to have for use on the computer or laptop. And yes there are good tools to convert from LIT to something else such as LRF. Book Designer would be the best tool of choice in this multi-conversion as it will allow format once, write multiple.

Jon

I meant the HTML download as an additional option. The HTML is the base for most ebook formats so it is needed for those who want to create the various formats. I doubt that all the creators here know all the tricks for all the formats equally well. So collaboration is needed. Probably the download area needs to be moved over to the wiki.

I meant the HTML download as an additional option. The HTML is the base for most ebook formats so it is needed for those who want to create the various formats. I doubt that all the creators here know all the tricks for all the formats equally well. So collaboration is needed. Probably the download area needs to be moved over to the wiki.
The solution to that would be easy. When you attach the book for the forum, make it a ZIP file with the book already compiled and the source file be it HTML, HTML0, or whatever was used. Include a text file to say what program was used and the options and there you go.

Perhaps it'd be better to upload the books to FeedBooks for processing into Custom PDFs?

FeedBooks seems to only offer eBooks in PDF form (according to the quick check I did), making the service worthless.

I can understand offering eBooks in ready-to-go formats for those who don't want to be bothered to do their own conversion, but the original source should [B]always[B] be offered as well.

FeedBooks seems to only offer eBooks in PDF form (according to the quick check I did), making the service worthless.

I can understand offering eBooks in ready-to-go formats for those who don't want to be bothered to do their own conversion, but the original source should [B]always[B] be offered as well.

I don't think that all of our registered users consider Feedbooks worthless, hopefully. PDF is what we selected for the beta, since it's the only good way to keep nice typesetting in an e-book for the moment.
What you call original source is actually quite different on Feedbooks: the source is not a file but in multiple tables in a database, divided into elements that are not presentation tags but parts/chapters/sections.
And some of the presentation tags are book specific too like footnotes for example.
Oh and unlike many websites, the source is always included both on the website and in the book, so you can easily find who scanned, did the proof reading etc...

Based on your opinion, I guess that you also consider the LRF uploads worthless, since on the forum, people usually upload the LRF only ?

What you call original source is actually quite different on Feedbooks: the source is not a file but in multiple tables in a database, divided into elements that are not presentation tags but parts/chapters/sections.

Then you should be able to provide eBooks in a non-restricted format just as easily as you can in PDF.

Based on your opinion, I guess that you also consider the LRF uploads worthless, since on the forum, people usually upload the LRF only?

All closed, proprietary formats are worthless.

We should have the base books cleaned prepared and stored in HTML. When you click on a book choice a dialog box asks you what format you need and a universal translator coughs it up for your download. That would be a neat service similar to a vending machine and necessitating less server space. MR's service would stand out with the offer of tasteful displays like those RWood and HarryT do. Every format available could be provided, particularly orphaned device formats, those that are no longer supported by their departed makers.

Can this kind of software be done and offered on a large scale?

Then you should be able to provide eBooks in a non-restricted format just as easily as you can in PDF.


We can and we will be supporting Open Ebook in the future. But for us, HTML/XML is not the source.

Why ?
Because if we only used HTML/XML as the source, we wouldn't have any markups dividing the book correctly. A book is not strictly presentation, there's also semantic information in it. HTML is not the nexus for e-book: it lacks some very valuable information.
We must not represent a chapter as something slightly bolder and on the center of the page, in what would be the source of all those e-books formats. You don't need to store a TOC in the source, you can easily create a TOC if you have the right markup for parts/chapters/sections.
The same thing could be said for footnotes too.

Restrictions are not purely based on DRM or reflowable capabilities.

Perhaps it'd be better to upload the books to FeedBooks for processing into Custom PDFs?FeedBooks seems to only offer eBooks in PDF form (according to the quick check I did), making the service worthless.

I can understand offering eBooks in ready-to-go formats for those who don't want to be bothered to do their own conversion, but the original source should [B]always[B] be offered as well.(Sigh) I was talking specifically about how we might handle uploads of PDF books, rlauzon, so the fact that FeedBooks only offers the thing I was specifically talking about is kinda the point. :wink:

I know you don't like PDF, Mobi, LRF, and all the other 'closed, proprietary' formats, and I'm not disputing the point, but a lot of folks do get a lot of mileage out of them.

I think that when we're talking about ways to offer free books in as many formats as possible, for the convenience of as many folks as possible, with as little trouble as possible, the fact that some of those formats are terminal ones (as in you can't get the stuff back out) is not really the most important point in that context. :shrug:

Because if we only used HTML/XML as the source, we wouldn't have any markups dividing the book correctly.

This is untrue.

You are correct that HTML may not provide all the information you need, but you are incorrect when you say that XML cannot. XML is often used as the "flattened" form of a database.

A book is not strictly presentation, there's also semantic information in it.

Which XML can provide.

(Sigh) I was talking specifically about how we might handle uploads of PDF books, rlauzon, so the fact that FeedBooks only offers the thing I was specifically talking about is kinda the point. :wink:

And when the next eBook reader comes out that doesn't support any of the PDF eBook sizes, all the work you did becomes useless.

I know you don't like PDF, Mobi, LRF, and all the other 'closed, proprietary' formats, and I'm not disputing the point, but a lot of folks do get a lot of mileage out of them.

I do understand. But I also understand that as PDF (or any other locked down format) gains users, it makes it that much harder for a standard eBook format to be created.

And when the next eBook reader comes out that doesn't support any of the PDF eBook sizes, all the work you did becomes useless.Which is why I suggested handling them through FeedBooks which creates them on the fly and can re-create them for other sizes, eliminating the human effort from the equation altogether.

But I also understand that as PDF (or any other locked down format) gains users, it makes it that much harder for a standard eBook format to be created.I'm not disputing that either, but we weren't discussing what formats should be used in a universal sense, but rather how to best serve our members, some of whom use terminal formats such as PDF, and I see FeedBooks as an excellent way to not put a lot of human effort into creating the individual books. Hadrien has already put a lot of his own effort (which I assume is human :)) into creating an engine that does the work for us.

Yes, he's working on handling other outputs, but it's not a finished product yet.
Yes, there are other ways to do it than the way he chose, but he did have to choose one.
Yes, we all want a single, standard format, but we don't have one yet, and people have to choose from the ones available, or give up e-reading altogether, which doesn't help further e-books either.

That's all I'm trying to get across here.

This is untrue.

You are correct that HTML may not provide all the information you need, but you are incorrect when you say that XML cannot. XML is often used as the "flattened" form of a database.



Which XML can provide.

Yes and we're going to use XML for this. But most XML-based formats are purely based on presentation and nothing else (that's what I was pointing to, using XML in my previous post). In the future we'll use as an input xml that will be divided into 2 different types of tags:
- metadata and structure
- presentation

Metadata will be for the name of the book, the title, the isbn, the tags, short description etc...
Structure will divide the the book into parts/chapters/sections and might be extended for other type of texts (plays ?).
Presentation will keep some basic XHTML tags (b, i, br, center, hr...) but we'll also add a few book specific tags (<fb:footnotes>, <fb:verse> for example).

With such an XML file we'll have exactly the same stuff than in our database.

Out of this structure, we'll create files on the fly like we already do (PDF right now, XML based formats in the future, we already tested TTS too).

In our admin, we already have a feature to export our book in XML form, but very basic support right now, we'll work on extending this during the summer.

@ rlauzon

What's your idea of the best format we should have? Is there one now you'd see over others?

That sounds like a good topic for it's own thread, yvanleterrible. :nice:

Yeah! I know but I'm interested in what Lauzon has to say, he's got good ideas on DRM.

Oh, I think he'll happily share them in either place. :wink2:

Which is why I suggested handling them through FeedBooks which creates them on the fly and can re-create them for other sizes, eliminating the human effort from the equation altogether.

But requires that FeedBooks be changed to support the device.

Yes, he's working on handling other outputs, but it's not a finished product yet.

Then I'll reserve my final judgement for later. But, right now, FeedBooks brings me no value.

Yes and we're going to use XML for this. But most XML-based formats are purely based on presentation and nothing else (that's what I was pointing to, using XML in my previous post).

You seem to be confused about what XML is.

Basically, XML is a language that describes data. Pretty much any data.

I suggest "Learning XML" by Erik T. Ray (O'Reilly). Many people at work have used this book to get a good feel of what XML is and what it can do.

What's your idea of the best format we should have? Is there one now you'd see over others?

XML would be the most universal. The problem will be to create a schema that can support everything we need.

Right now, I keep my eBooks in Open Document Format. I use OpenOffice to quickly and easily convert them to whatever format I want them in (PDF for my iLiad, HTML for when I want to play with MobiPocket, PalmDOC for my Palm, etc.).

Since Open Doc is becoming the word processing standard, perhaps that should be the eBook format of choice as well.

There you go !
Then we should store all the books being crafted here to XML and have links to the translators we need for such and such device.

You seem to be confused about what XML is.

Basically, XML is a language that describes data. Pretty much any data.

I suggest "Learning XML" by Erik T. Ray (O'Reilly). Many people at work have used this book to get a good feel of what XML is and what it can do.

I parse and create XML everyday so no, I'm not confused at all. And you're really confused about how Feedbooks work: you can create custom PDF files, which means that there's no need for us to change anything on the website if we need to support more devices that are PDF enabled. We can add templates, which means that they're the files once generated are stored in cache and there's no need for the user to customize anything. But as long as the device is PDF enabled, we can generate the right book for it.

Actually Feedbooks work exactly like what yvanleterrible describded:
We should have the base books cleaned prepared and stored in HTML. When you click on a book choice a dialog box asks you what format you need and a universal translator coughs it up for your download.
We're still in beta test, that's why there's only PDF supported, and we're not using HTML because HTML is pure presentation. We're using a database which would be 100% similar to using XML.

In my previous post I was just pointing to the fact that LRF, Mobipocket etc... use XML purely for presentation, not semantic information.

Then we should store all the books being crafted here to XML and have links to the translators we need for such and such device.

You are still thinking along the lines of "every device should have their own close, proprietary format that they support" and that we need to translate from a common format to that closed, proprietary format.

That's what we basically have today - with everyone disagreeing on what the common format is.

What you need to be thinking is "This is the common format for all eBooks. If your device doesn't support it - and support it well - then I won't buy your device." You should also be thinking along the lines of "eBooks that aren't in the common format aren't worth buying."

Then you should be able to provide eBooks in a non-restricted format just as easily as you can in PDF.



All closed, proprietary formats are worthless.
Then why are you here? Other then text, HTML, or RTF, it's all closed and proprietary which you seem to have a sever dislike for. What binary ebook format do you like if any?

And when the next eBook reader comes out that doesn't support any of the PDF eBook sizes, all the work you did becomes useless.



I do understand. But I also understand that as PDF (or any other locked down format) gains users, it makes it that much harder for a standard eBook format to be created.
Do you honestly think that the Sony Reader size PDF won't be viewable on the next generation eink reader? Because the Sony Reader size is small enough while it might not be optimal due to being small, it will be very clearly readable and usable on any next gen eink device that supports PDF.

rlauzon, as one that has created many of the books in the Sony upload/download section I do keep the originals in other forms. Sometimes one title will be in several forms. We create these titles in LRF because it gives the most flexibility to the end user. Feedbooks does an excellent job of creating PDF versions and in the future I will be adding a lot of the books I have created here to the library there.

I do find it amusing that for all of your condemnation of the PDF format that you admit to using it yourself.

Right now, I keep my eBooks in Open Document Format. I use OpenOffice to quickly and easily convert them to whatever format I want them in (PDF for my iLiad, HTML for when I want to play with MobiPocket, PalmDOC for my Palm, etc.).

This sounds like the same reason that I chose RTF to release my books in, so people could convert them as they wish.

Since Open Doc is becoming the word processing standard, perhaps that should be the eBook format of choice as well.

I have as yet not tried Open Doc format (but I'm still using W2k and Word 2k for a lot of my conversion work). I can't address whether it is in fact becoming the standard WP format, but if it is, I'm all for using it as I use RTF, to give people freedom of choice.

I do find it amusing that for all of your condemnation of the PDF format that you admit to using it yourself.

Yes, I find it ironic myself. But that's the only format that is useful on the iLiad right now.

But that just reinforces my point: If vendors think that PDF is "the eBook standard" they will make devices that support it - to the exclusion of other, better eBook formats. And the more momentum formats like PDF have, the harder it will be to move to a standard eBook format when one becomes available.

Do you honestly think that the Sony Reader size PDF won't be viewable on the next generation eink reader?

A Sony Reader formatted PDF is not displayable on my Palm, my cell phone, my portable video player. On my iLiad, it will look like a large print old-man's book (i.e. not a fun read).

A Sony Reader formatted PDF is not displayable on my Palm, my cell phone, my portable video player. On my iLiad, it will look like a large print old-man's book (i.e. not a fun read).

But they look lovely on a Sony Reader. And I think this is the whole point of having a dedicated upload section. Simply click on the attachment, sync it with the Connect software, and voila, you got a wonderfully styled, perfectly dimensioned new e-book on your device.

So... let's have dedicated sections for popular e-readers, such as the Reader and iLiad, and let's have one section for multi-formats.

Don't expect a "one format to rule them all" any time soon.
There's 2 reasons for this:
- reflowable formats and fixed version are both needed for the moment. As long as reflowable formats won't provide hyphenation and more advanced typesetting, PDF and similar formats will be the alternative.
- DRM: both publishers and hardware manufacturers will use DRM. Right now, Mobipocket and LRF are already in competition for this market.

The first problem could be fixed if all e-ink readers adopted much more advanced software for rendering reflowable formats. But for hyphenation, you need a dictionnary, so the problem isn't necessarily that simple: for each book, you need to know it's language. I'm not sure that the metadata of every reflowable format contain this information.

Don't expect a "one format to rule them all" any time soon.
There's 2 reasons for this:
- reflowable formats and fixed version are both needed for the moment. As long as reflowable formats won't provide hyphenation and more advanced typesetting, PDF and similar formats will be the alternative.
- DRM: both publishers and hardware manufacturers will use DRM. Right now, Mobipocket and LRF are already in competition for this market.

The first problem could be fixed if all e-ink readers adopted much more advanced software for rendering reflowable formats. But for hyphenation, you need a dictionnary, so the problem isn't necessarily that simple: for each book, you need to know it's language. I'm not sure that the metadata of every reflowable format contain this information.
I have used Wordperfect. What Wordperfect did was put in non-displayable hyphens that were used to hyphenate words. So if these ebook formats supported that then the hyphens could be put in at the time f the book creation and the software creating the books can handle that and not the reader. Also, it would allow us to put in hyphens as needed as well.

Given all the various reflowable ebook formats today, which one(s) do you feel are the best ones (ignoring the DRM issue)?

But I also understand that as PDF (or any other locked down format) gains users, it makes it that much harder for a standard eBook format to be created.

That's PDF would be very bad as a general format for e-books.

As a format for a specific reader it makes perfect sense -- except for a publisher who expects to make money out of handcrafting books.

If you guys agree with me, this is how we'll do it:


In the iRex iLiad forum (http://www.mobileread.com/forums/forumdisplay.php?f=99), we create an upload category for the iLiad - analogous to the upload section (http://www.mobileread.com/forums/forumdisplay.php?f=99) for the Reader.
In the E-Books forum (http://www.mobileread.com/forums/forumdisplay.php?f=23), we create an upload category for multi-formatted e-books, i.e. e-books in formats that can be easily converted for a wide range of readers.


Remarks:

It's obviously OK to upload a book multiple times if you have it ready in various formats.
Each upload section requires moderation (see HarryT's excellent guidelines (http://www.mobileread.com/forums/showthread.php?t=10339)). If you like to join our team as a moderator to keep an eye on things, help to improve MobileRead, and hang out with a bunch of really cool guys, please PM me.
The E-Books view (http://www.mobileread.com/forums/ebooks.php?order=desc&sort=dateline) tool has been rewritten last night to support multiple upload categories. :D

The question of HTML/dynamic vs. PDF/static page is a question of what an ebook should be. Static means the ebook should be just like a paper book with only minor enhancements wheras dynamic content tries to introduce new features to the reading process. Which one will win is impossible to predict.

Soft hyphens do work in modern browsers so the HTML source could be augmented by shy entities.

But... I have one suggestion:
On the frontpage, remove uploads from the "Latest Forum Activity" section. Instead add a new section specifically for latest e-book uploads. This way we can track both more easily, user threads and user uploads.

This is a good suggestion and I am planning on doing this. Thanks!

The question of HTML/dynamic vs. PDF/static page is a question of what an ebook should be. Static means the ebook should be just like a paper book with only minor enhancements wheras dynamic content tries to introduce new features to the reading process. Which one will win is impossible to predict.

Soft hyphens do work in modern browsers so the HTML source could be augmented by shy entities.

You're wrong, you can have links in what you call static pages too. HTML is not much more dynamic than some fixed size format, it's just easier to reflow. If you want advance design and typesetting, fixed size formats are much more powerful than HTML.

If you guys agree with me, this is how we'll do it:


In the iRex iLiad forum (http://www.mobileread.com/forums/forumdisplay.php?f=99), we create an upload category for the iLiad - analogous to the upload section (http://www.mobileread.com/forums/forumdisplay.php?f=99) for the Reader.
In the E-Books forum (http://www.mobileread.com/forums/forumdisplay.php?f=23), we create an upload category for multi-formatted e-books, i.e. e-books in formats that can be easily converted for a wide range of readers.

What I think would be good is a just one database of books/links. But it would need another field to show what format it was in. And I also feel that if anyone wants to upload the original source, then that would be done separately in a different forum with the database would show that in the format field. In the topic, after the date, put in the format i.e. LIT, LRF1 (Librie) LRF2 (Reader), PDB, etc.. LRF for the Reader might not work on the Librie which is why LRF1 and LRF2.

You are still thinking along the lines of "every device should have their own close, proprietary format that they support" and that we need to translate from a common format to that closed, proprietary format.

That's what we basically have today - with everyone disagreeing on what the common format is.



No, no! That's not what I'm thinking about. The reason is mostly esthetic. The people working on books here are working for a visual output, and I was concerned that the nice things they do might look like crap when ported to an other device. What I'm thinking of is a translator that would take this into account. Because this is what we could say is the MR signature, not the code, the visual aspect.

I could easily enable Feedbooks to communicate with other websites too, using XML or even a full REST service. This way, people could find both handmade books and books available on Feedbooks using the same interface.

The question of HTML/dynamic vs. PDF/static page is a question of what an ebook should be. Static means the ebook should be just like a paper book with only minor enhancements wheras dynamic content tries to introduce new features to the reading process. Which one will win is impossible to predict.

Unless all eBook readers are the same size, and all human eyes are the same, I feel that dynamic will win hands down.

We've already covered the reader physical size issue.

But there is great benefit to allowing the reader to choose how the book is formatted. A person who has trouble reading italics, for example, can tell the eBook reader to replace italics with a different font - making it much easier to read. Also, someone who has good eyesight can opt for smaller text, while people with not-so-good eyesight can opt for larger text.

No, no! That's not what I'm thinking about. The reason is mostly esthetic. The people working on books here are working for a visual output, and I was concerned that the nice things they do might look like crap when ported to an other device. What I'm thinking of is a translator that would take this into account. Because this is what we could say is the MR signature, not the code, the visual aspect.

I think I know what you are talking about. Too often I see a PDF-translated-LIT file. A file that can't be reflowed because the information simply isn't there in the original.

That's the problem with translation - some data is usually filtered out.

For example, a OpenDoc that's translated to a PDF. The PDF does not contain paragraph breaks anymore. PDF didn't need that information, so there was no provision made for it. So when translating a PDF back to an OpenDoc, someone has to provide that paragraph break information.

What I want is to eliminate the need for any translation process.

I think I know what you are talking about. Too often I see a PDF-translated-LIT file. A file that can't be reflowed because the information simply isn't there in the original.

That's the problem with translation - some data is usually filtered out.

For example, a OpenDoc that's translated to a PDF. The PDF does not contain paragraph breaks anymore. PDF didn't need that information, so there was no provision made for it. So when translating a PDF back to an OpenDoc, someone has to provide that paragraph break information.

What I want is to eliminate the need for any translation process.
Why someone would want to go from LIT to PDF is just beyond me. The problem is a lot of people are totally 100% clueless and it shows. How many times have you seen an ebook in text look like total crap? Take the ebook in LIT, convert it to HTML, do away with the ToC (because it's a seperate file and they are too lazy to deal with it), convert to PDF which will look ok, then use a PDF to text converter that loses all the formatting such as italics, emdashes, proper paragraph ends, and you can easily get one hell of a shitty mess all from a well formatted LIT file.

Why someone would want to go from LIT to PDF is just beyond me.

They were going from PDF, running pdftohtml and using the resulting html file to create a LIT file.

The problem was the original source for the LIT was a PDF document. So no paragraph markers were there.

The problem is a lot of people are totally 100% clueless and it shows. How many times have you seen an ebook in text look like total crap?

Too many to count.

What I think would be good is a just one database of books/links. But it would need another field to show what format it was in. And I also feel that if anyone wants to upload the original source, then that would be done separately in a different forum with the database would show that in the format field. In the topic, after the date, put in the format i.e. LIT, LRF1 (Librie) LRF2 (Reader), PDB, etc.. LRF for the Reader might not work on the Librie which is why LRF1 and LRF2.

Good suggestion and I think it will be similar to what we'll have set up (by tomorrow or so). If you go to the E-Books Uploads (http://www.mobileread.com/forums/ebooks.php?order=desc&sort=dateline), you'll see a new column that shows the format (or the device the book was specifically made for). Also there is a drop-down menu where you can sort for a specific format of uploaded books. I think this is easier than having us add the format info in the title every time.

... In the E-Books forum (http://www.mobileread.com/forums/forumdisplay.php?f=23), we create an upload category for multi-formatted e-books, i.e. e-books in formats that can be easily converted for a wide range of readers....

It almost sounds as if this is either a vague description of PDB formatted books or a dumping ground for HTML, HTML0 (BookDesigner), TXT, and RTF source files.

Good suggestion and I think it will be similar to what we'll have set up (by tomorrow or so). If you go to the E-Books Uploads (http://www.mobileread.com/forums/ebooks.php?order=desc&sort=dateline), you'll see a new column that shows the format (or the device the book was specifically made for). Also there is a drop-down menu where you can sort for a specific format of uploaded books. I think this is easier than having us add the format info in the title every time.
I was suggesting something like...

Becke, Louis: The Mutineer: A Romance of Pitacairn Island. v1. 13 June 07 LRF2

So then the database generator will pick up the LRF2 and know what format it is and fill in the format field properly.

And for PDF, I suggest PDFA4, PDF1, and PDF2. PDF1 for the iLiad and PDF2 for the Sony Reader. We can do similar things for when a file type has multiple versions. LRF1 & LRF2 .. LRF2 might work on the Librie, but not guaranteed. And the same thing for source files too. A designation to know what type of files the source files are if anyone wants to post them. But this means then that the source files will have to be posted separately unless with have a header like LRF2/HTML0 so that would mean it's for the Sony Reader and a Book Designer source file.

And there should be a place to describe all this stuff as well. The wiki would be the place (IMHO).

You're wrong, you can have links in what you call static pages too. HTML is not much more dynamic than some fixed size format, it's just easier to reflow. If you want advance design and typesetting, fixed size formats are much more powerful than HTML.
No, i am arguing on a different level.
There are two forms of ebooks. One concentrating on keeping the experience of paper books while adding some features (mainly navigational not presentational). this is where typography and static pages are the focus. The other form goes for new experiences with text. This means allowing reflow of the text and the many dynamic features HTML allows. This makes the presentation dynamic so some typographic content has to be dropped (usually because it cannot be rendered).
For most of the texts typographical detail is irrelevant because they have none. The separation of content and presentation allows to make the text independent from the presentation device. This is why the majority of ebooks is in HTML not PDF. There is room and need for both forms of ebooks, but not for equal shares on the market.

No, i am arguing on a different level.
There are two forms of ebooks. One concentrating on keeping the experience of paper books while adding some features (mainly navigational not presentational). this is where typography and static pages are the focus. The other form goes for new experiences with text. This means allowing reflow of the text and the many dynamic features HTML allows. This makes the presentation dynamic so some typographic content has to be dropped (usually because it cannot be rendered).
For most of the texts typographical detail is irrelevant because they have none. The separation of content and presentation allows to make the text independent from the presentation device. This is why the majority of ebooks is in HTML not PDF. There is room and need for both forms of ebooks, but not for equal shares on the market.

I also believe that there's a need for both format, but I don't consider that HTML separates content from presentation. An XML format with special tags for books and semantic information would be much more suited for this task.

HTML wasn't designed for books, but some of its basic tags can still be useful. Extending this set of tags with special tags for books formatting, the structure of the text (for all sorts of text, the structure of a novel is quite different from a play) and metadata would be the right solution.

If the readers themselves, can't render the structure of the book using such tags, we can still use stylesheets or some software to transform for example a <chapter> tag into a TOC at the beginning of the text, and a real chapter heading.

Yes, some XML which is an expanded XHTML is probably the way to go (in fact Mobipocket is going that way albeit a bit crudely).
I use "HTML" and "PDF" only as names because they are the dominating formats for the two forms of ebooks. RTF would be an alternative term for HTML and TeX for PDF.
The main difference is that HTML recognizes that presentation of content can be done in different ways. PDF is unable to separate content and presentation.

TeX can, though.

TeX can, though.

That's what we generate our books with on Feedbooks ;-)

We can do stuff like <chapter> <--> \chapter
Easily support footnotes, create a TOC, support hyphenation etc...

I would much rather download books in BookDesigner format than in lrf. Making small changes to a book's display is one of the main advantages of this medium, and to my mind outweighs the reasons for providing a fixed format!

Those of us who are creating books for this site are pretty much all in agreement that uploading books in BD format is not a good idea.

The reason for this is that there are a lot of people out there re-selling PD books, and we don't want to give them a ready-made source of nicely formatted books. It is, as you may be aware, a great deal of work to create a nice-looking book from the PG original - some of my anthologies represent literally days of work. This is work I'm happy to do for the benefit of people on this site, but I'm not prepared to give the fruits of my labour, free of charge, to people wanting to make a "fast buck" from such material.

If you wish to upload BD stuff yourself, however, go right ahead - there will be an "other formats" upload area opening shortly.

Those of us who are creating books for this site are pretty much all in agreement that uploading books in BD format is not a good idea.

The reason for this is that there are a lot of people out there re-selling PD books, and we don't want to give them a ready-made source of nicely formatted books. It is, as you may be aware, a great deal of work to create a nice-looking book from the PG original - some of my anthologies represent literally days of work. This is work I'm happy to do for the benefit of people on this site, but I'm not prepared to give the fruits of my labour, free of charge, to people wanting to make a "fast buck" from such material.

If you wish to upload BD stuff yourself, however, go right ahead - there will be an "other formats" upload area opening shortly.

Harry, I understand that. As for me, if uploading a book in BD format helps profit-makers as well as enthusiasts, that would be discouraging indeed, but as long as there are enthusiasts out there benefitting from it, I'd want to continue orienting myself to what's best for them.