View Full Version : ePub or No ePub, That is the Poll


RWood
12-27-2008, 08:21 PM
There has been some recent discussion (http://www.mobileread.com/forums/showthread.php?t=34798) about the merits of adding an ePub download section to the existing Sony BBeB/LRF, Mobipocket/PRC, and eBookwise/IMP download sections.

By my count, there are 18 ePub books posted in the "Other Formats" download section.

Bible, King James Version, V1.0, 11.09.2008 [epub] (Misc)
Collodi, Carlo: Le avventure di Pinocchio (Italian) (ePUB) v1 26 Dec 2008 (Misc)
Cutcliffe Hyne, C J: Atoms of Empire v 1 Nov 7 2008 epub (Misc)
Dumas, Alexandre, père: The Three Musketeers. v1.0. EPUB. 08 Aug 2008. (Misc)
EPUB - CIA World Factbook (Misc)
Kingston, W.H.G.: The Pirate of the Mediterranean ePUB v1 26 dec 2008 (Misc)
Le Queux, William: The Stretton Street Affair v 1.0 Nov 5 2008 epub (Misc)
Maniates, Belle Kanaris: Penny of Top Hill Trail v.1 Nov 6 2008 epub (Misc)
May, Karl: Durch das Land der Skipetaren (german) v 1.0 Nov 3 2008 epub (Misc)
May, Karl: Von Bagdad nach Stambul (german) v1.1 Nov 5 2008 epub (Misc)
May, Karl: Durchs wilde Kurdistan (german) v 1.0 Nov 1 2008 epub (Misc)
Nobody's Boy (Sans Famille), by Hector Malot (1830-1907) - EPUB (Misc)
Orwell, George: Animal Farm: A Fairy Story. (ePUB) v4 21 Dec 2008 (Misc)
The American Claimant. (Illustrated) (ePUB) v1 21 Dec 2008 (Misc)
Twain, Mark: The Prince and the Pauper. (Illustrated) (ePUB) v2 21 Dec 2008 (Misc)
Webster, Noah: Webster's Dictionary 1913 (updated .EPUB), v2, 04 Nov 2008 (Misc)
Wilde, Oscar: The Picture of Dorian Gray. (ePUB) v2 22 Dec 2008 (Misc)
Wodehouse, P.G.: The Swoop!, or How Clarence Saved England. (ePUB) v6 21 Dec 2008 (Misc)

Nate did a search of the entire forum for 'ePub" and found 46 file attachments. Therefore the number is somewhere between 18 and 48. As far as I know only the Sony 505 and Sony 700 currently support ePub. It is a chicken and egg sort of thing. Since the only current readers supporting ePub also support LRF and LRF is the format ebooks are the most posted ebooks at MobileRead, the owners of the 505 and 700 already have access to the MobileRead ebooks. When we added the PRC ebooks and later the IMP ebooks we added groups of readers that were not already served by existing formats.

This poll is directed toward people that produce ebooks.

Edit: The poll is open for 20 days and does allow for multiple responses.

nrapallo
12-27-2008, 09:57 PM
I eventually see .epub becoming the ultimate ebook source format.

I already produce most of my ebooks from .html with images/hyperlinks/styles and that is basically what gets encapsulated in a .epub.

I have been reluctant to add .epub support for my software tools (as most probably are) until the format achieves wider penetration/support.

But that support WILL come as more dedicated readers can use the .epub format. I see it becoming a major ebook format and I think it's time will come as a separate MR upload forum.

My hardware reader cannot handle .epub (though it does display a limited HTML v3.2 variant) and I don't think it will. However, the tools used to make .imp books (like eBook Publisher) will migrate to allow the loading of .epub for ultimate conversion to my reader's native (.imp) format as well as the generation of .epub for archival purposes.

So I would welcome a .epub upload forum. The only problem I can see at the moment is that the only hardware readers offering native .epub support (Sony PRS-505/700) require the .html to be in size-limited chunks as opposed to one (large) .html. I don't know if that memory-constrained limit will ever go away and you will have to deal with multiple .epub variants (based on different device's tolerances). Hopefully software tools will soon exist to seamlessly switch between these .epub variants.

=X=
12-28-2008, 01:18 AM
For me the tools to create quality ePUBs exist. With BookCreator and calibre it's just as easy to enough to produce books just as good as LRF and in some cases even better. (Mobi and IMP require more work) But the ePUB support on SONY is just terrible. LRF performance on the SONY is just far better than ePUB.

Just a comment there are other mobile devices today that support ePUB such as the iPhone so I don't think one of your options is incorrect.

=X=

Falbe Publishing
12-28-2008, 01:33 AM
I have yet to produce any of my ebooks in epub format. It is something on the back burner for me because no one has every asked me for that format. Most people just want something that works on whatever device they use and if I have something that works, then they select it.

I've been slowly looking into making epub. I have Adobe InDesign, but I need a $600 upgrade to get the new version that is supposed to make epub, so that's not very exciting. I've been meaning to check out calibre, and see how it does.

For me, I'm just monitoring the epub situation to see how it develops. If readers start wanting it, I'll get motivated about delivering it.

FizzyWater
12-28-2008, 01:33 AM
The few epubs I made with Calibre consistently crashed my Reader. Kovid says it's a bug in the ADE program. Or maybe it's the "too large html" file issue, I can't remember.

I don't want to take the time to code in HTML/XML (and am too unpracticed in it for it to be something fast, as it might be for some of our members).

And Book Designer - ick. I really didn't like using that program and finally uninstalled it.

So for now, it's LRF. If I'm really lazy, it might even be a RTF.

Jellby
12-28-2008, 04:13 AM
Like nrapallo, at the moment I see ePUB as a source format, although my sources are in HTML for mobipocket... What I mean is that, even though I don't have any reader supporting ePUB, and even though none of the readers I know of properly support all the features I'd like, I still produce the ePUB files because that's a nice way to store the source files. Since the books I upload have a certain amount of work in formatting and proofreading, I find it desirable to make it possible for others to convert them to other formats, and ePUB is good as a source for that.

I would maybe like to have better tools for creating ePUB files, but I have the feeling I would be dissatisfied anyway and I'd go back to handcoding the XHTML... so the lack of tools is not a real problem for me now. The lack of readers is more problematic, but since I can check most of the format with a web browser, I can work around that.

Steven Lyle Jordan
12-28-2008, 02:58 PM
I favor making ePub formats available, as I hope to see more reading devices support ePub as a format for translating into their native format. I also presently make RTF files available, for exactly that purpose. Presently I produce in 6 formats (plus PDF, which I use internally but do not sell), and the next time I cut back on formats, I may remove RTF and leave ePub for translation purposes.

Eventually, I'd like to be producing in the fewest formats possible, and as a universal format, I consider ePub among the best for standard literature needs.

mtravellerh
12-28-2008, 04:17 PM
I think epub will become the predominant format in the future. I have made a few tries with assembling some epubs, but the creating software leaves much to be desired. My big problem is the fact that I cannot use my HTML source files the way I use them to make Mobi and LRF files without having to do a complete rebuild of the files. I do XHTML files, for god's sake, stripped to the bare minimum to simplify that process. The only real working epub files available right now, for me, are Feedbook's.

I keep up the hope that someday there will be a software available that makes it possible, with a little editing of the CSS file, to create feature rich epubs working on every available platform and not crash on every other reader or software like Stanza's do for example. This includes software and hardware readers that do not claim specific properties from the book for it to be readable.

Elsi
12-28-2008, 04:35 PM
I'd be glad to create ePub books as well as the other three formats when I convert a book for uploading here. For now, I'm assuming that Calibre will be the software most available to me -- or maybe the online tool at Feedbooks. I do own a Sony 505 reader, but have not yet applied the update that will enable it to support ePub files. (Long story -- but planned to be done by the end of March 2009.) I don't really want to install Adobe Digital Editions on my computer to read the ePub book, so will need to investigate the various options for display.

Some interesting web places having to do with ePub that I found:

* free, online ePub validator -- http://www.threepress.org/document/epub-validate/
* tutorial on creating ePub books -- https://www6.software.ibm.com/developerworks/education/x-epubtut/index.html

mtravellerh
12-28-2008, 04:43 PM
I'd be glad to create ePub books as well as the other three formats when I convert a book for uploading here. For now, I'm assuming that Calibre will be the software most available to me -- or maybe the online tool at Feedbooks. I do own a Sony 505 reader, but have not yet applied the update that will enable it to support ePub files. (Long story -- but planned to be done by the end of March 2009.) I don't really want to install Adobe Digital Editions on my computer to read the ePub book, so will need to investigate the various options for display.

Some interesting web places having to do with ePub that I found:

* free, online ePub validator -- http://www.threepress.org/document/epub-validate/
* tutorial on creating ePub books -- https://www6.software.ibm.com/developerworks/education/x-epubtut/index.html

The online tool at Feedbook has some disadvantages but is the best to date. One thing I do not like is the fact that there are no illustrations allowed in the text. But, hey, pagebreak works and it does not crash any reader I tried so far.

DaleDe
12-28-2008, 07:20 PM
I am not sure there are very many production tools that will generate a correct ePUB file that will pass the check standard. I do not believe Calibre supports an ePUB TOC for example but then perhaps it has been added recently. I would say we need to ensure the tools can do the full job before we have the format go public. I think people would hate having to redo stuff.

Dale


Dale

Hadrien
12-28-2008, 07:57 PM
Files on Feedbooks always pass epubcheck correctly, we even pre-process each XHTML feed individually with Tidy.

llasram
12-28-2008, 10:07 PM
I do not believe Calibre supports an ePUB TOC for example but then perhaps it has been added recently.

No... Calibre EPUB generation has always included NCX TOC support.

What sorts of tools do the people who say they want better tools want?

Abisha
12-28-2008, 11:14 PM
I'm not sure if some of the features I would prefer will ever find itself into the epub format; such as full justification for starters. I'm rather persnickety :rolleyes: about the layout of my books. Epub and the whole ragged right makes reading that much less enjoyable for me. Also, font embedding is pretty crucial for me as well. I'm not sure if that is just a limitation on the software I'm using or if the Epub standard already supports it? Perhaps I will reexamine using Epub when those issues are addressed.

llasram
12-28-2008, 11:46 PM
I'm not sure if some of the features I would prefer will ever find itself into the epub format; such as full justification for starters.

That's an AdobeDE limitation, not an EPUB limitation. Most other EPUB readers do full justification just fine.

Also, font embedding is pretty crucial for me as well.

Also already a part of EPUB. In fact, it's the only format for which font embedding really works well -- if font embedding is important to you then EPUB is the format for you.

Jellby
12-29-2008, 04:38 AM
What sorts of tools do the people who say they want better tools want?

I could use a user-friendly (but not too "smart") .opf and .ncx editor. Having to manually add and name every file in the manifest, and make sure everything is in the spine can be a pain... the same with the "playOrder" in the .ncx.

Abisha
12-29-2008, 02:49 PM
That's an AdobeDE limitation, not an EPUB limitation. Most other EPUB readers do full justification just fine.

Hmmm, so than is it my phsical reader hardware that is failing to display the epub in full justification? As a test, I downloaded "Animal Farm" in Epub format from our very own mobileread online library. I transferred it over to my PRS-505 and to my dismay there was no full justification.



Also already a part of EPUB. In fact, it's the only format for which font embedding really works well -- if font embedding is important to you then EPUB is the format for you.

Unfortunately the tools that I've had exposure to have not presented to me the availability to embed fonts in epub. Perhaps they are commandline and I just need to research more on the topic. For the time being I've had fairly consistent results with embedding fonts in PDF, RTF, DOC, and LRF which are a necessity for me as a linguistic student. Any tips? I would love to make the switch to Epub knowing this will truly be the standard.

wallcraft
12-29-2008, 03:03 PM
Hmmm, so than is it my phsical reader hardware that is failing to display the epub in full justification? Its the software (Adobe Digital Editions) which fails to support full justification, even in its Desktop version which certainly isn't hardware limited.

llasram
12-29-2008, 05:49 PM
Hmmm, so than is it my phsical reader hardware that is failing to display the epub in full justification?

You may not have realized it, but the Reader's EPUB support is via a version of AdobeDE on the device. So like wallcraft said, same limitations.

Unfortunately the tools that I've had exposure to have not presented to me the availability to embed fonts in epub.

Calibre doesn't yet do direct font embedding (le sigh), but you can use some Reader-specific CSS tricks (http://www.mobileread.com/forums/showthread.php?t=30512) to get EPUB books you generate to use fonts you've copied onto the Reader.

Perhaps they are commandline and I just need to research more on the topic. For the time being I've had fairly consistent results with embedding fonts in PDF, RTF, DOC, and LRF which are a necessity for me as a linguistic student.

Oh, fair enough. I wasn't counting PDF as an e-book format, and didn't realize RTF had font embedding / supported it on the Reader. LRF definitely does it, but I was under the impression it could still be a bit chancy given our knowledge of the format, but I haven't looked at it in a while. By comparison EPUB font embedding is drop-dead simple -- include the font files in the ZIP archive and reference them via @font-face rules in the included CSS.

kovidgoyal
12-29-2008, 06:25 PM
Calibre doesn't yet do direct font embedding (le sigh), but you can use some Reader-specific CSS tricks (http://www.mobileread.com/forums/showthread.php?t=30512) to get EPUB books you generate to use fonts you've copied onto the Reader.



This isn't quite as simple to do as you might think at first glance. What about source documents that specify font families of their own or embed their own fonts?

vivaldirules
12-29-2008, 07:16 PM
Hugo Lefty: "Aren't you gonna say if you like the aliens or not?"
Lefty Hugo: "Do you mind if I wait until some at least land?"

llasram
12-30-2008, 12:29 AM
This isn't quite as simple to do as you might think at first glance. What about source documents that specify font families of their own or embed their own fonts?

Oh, I know -- that's part of why I haven't just jumped in and implemented it myself :). I do think that supporting adding fonts and @font-face rules for 'serif', 'sans-serif', and 'monospace' would cover at least 80% of uses though.

kovidgoyal
12-30-2008, 12:44 AM
There's actually a reasonably powerful class in the matplotlib source code that takes a CSS font family name and maps it to the "closest" font on your system. That could be used to take care of documents that specify their own font families.

Jellby
12-30-2008, 04:34 AM
Hmmm, so than is it my phsical reader hardware that is failing to display the epub in full justification? As a test, I downloaded "Animal Farm" in Epub format from our very own mobileread online library. I transferred it over to my PRS-505 and to my dismay there was no full justification.

The book does not specify any justification or text alignment, so the justification (or lack of it) you see is the reader's default. Whether this default can be changed or not is another thing.

If you use the provided index.zip (as explained in the post) to read the book in a web browser, you should see full justification. This is so because there is index.css on top of the book's css, and there you have "body { text-align: justify }". This "trick" is what I'd expect ePUB readers could use (i.e., have a user-configurable css), but apparently they don't (yet). Besides, it seems Adobe DE (and Sony) don't support full justification at all, even if it were called for by the book itself. But as others have said, this is not a problem of ePUB, but of the readers (well, ePUB's is to blame in that full justification is not a required feature, I think)

HarryT
12-30-2008, 04:57 AM
But as others have said, this is not a problem of ePUB, but of the readers (well, ePUB's is to blame in that full justification is not a required feature, I think)

It strikes me as a quite astonishing omission.

mtravellerh
12-30-2008, 05:37 AM
It strikes me as a quite astonishing omission.

Absolutely. But didn't we have THAT discussion before, Harry? Well, we were on the same side, but the techie boys (including Hadrien and Kovid) were on the other! :cool:

Hadrien
12-30-2008, 07:56 PM
Absolutely. But didn't we have THAT discussion before, Harry? Well, we were on the same side, but the techie boys (including Hadrien and Kovid) were on the other! :cool:

On which side ? I hate ragged right, I can only read fully justified text with good hyphenation. I can't understand at all why DE supports something as complicated as XSL-FO, yet doesn't allow the user to select this sort of things.

tompe
12-30-2008, 08:18 PM
On which side ? I hate ragged right, I can only read fully justified text with good hyphenation. I can't understand at all why DE supports something as complicated as XSL-FO, yet doesn't allow the user to select this sort of things.

Wasn't the question if it should be a required feature or not and to me it seems that requiring it will make it harder to implement viewers on some platforms.

mtravellerh
12-30-2008, 09:09 PM
On which side ? I hate ragged right, I can only read fully justified text with good hyphenation. I can't understand at all why DE supports something as complicated as XSL-FO, yet doesn't allow the user to select this sort of things.

Oops, sorry Hadrien. Coffee's on me.

Hadrien
12-30-2008, 09:42 PM
Wasn't the question if it should be a required feature or not and to me it seems that requiring it will make it harder to implement viewers on some platforms.

Justification is a very simple thing to support. Sure it might not look very good on small screens but even in a low ressource environment it's pretty easy to support.

kovidgoyal
12-30-2008, 10:03 PM
Personally, I don't care whether text I read is justified or not, not at the small screen sizes I use. Hadrien is right, justification is trivial to implement (at least for a single language) at a programming level (I know, I implemented it for calibre's LRF viewer).

On the other hand, I'm sick of closing tickets about the lack of justification in epub, so I'm *really* beginning to wish Adobe had implemented it.

mtravellerh
12-31-2008, 03:08 PM
Well, I for one thing, will implement ePUB now in my book assembling and uploading process from now on.

Pagebreaks on chapters work fine now and TOC is ok, too. There are only a few rules I have to take attention to and ePUB generation via Calibre is relatively trivial via now (big cigar for Kovid!).

There are a few other reasons to make the jump now:

1. My daughter gifted me an Ipod Touch for Xmas :D (tell you a secret: I make a lot of them books for my reading pleasure)

2. I think Sony and his reader will be relatively big in Germany this year, what with Kindle not present on the german market yet. So epub will be boosted (Libri.de, the biggest german bookstore chain, will sell the Sony 505 and epub ebooks in bookstores and online)

3. Bookeen will provide ePUB support in it's next firmware update (hopefully)

tompe
01-01-2009, 09:40 PM
Justification is a very simple thing to support. Sure it might not look very good on small screens but even in a low ressource environment it's pretty easy to support.

OK. But isn't the idea that a web browser should be able to be used as an ePUB viewer and most web browsers do not implement it (or do they?).

llasram
01-01-2009, 11:01 PM
OK. But isn't the idea that a web browser should be able to be used as an ePUB viewer and most web browsers do not implement it (or do they?).

(a) I'm not really sure that's the "idea"... It's certainly a big benefit that there's plenty of HTML rendering code already lying around which can be re-purposed into EPUB rendering code, but I think that's more a side-effect of HTML & CSS being mature, widely implemented technologies. (b) Most Web browsers certainly do render "text-align: justify", just not with automatic hyphenation.

mtravellerh
01-04-2009, 10:54 AM
Is auto-hyphenation really necessary or even a good thing? I doubt it a bit.
It still is a hit and miss thing, largely, takes up a lot of calculating power and is not THAT effective. If the screen is not too small, text justifies pretty well without the words being hyphenated, generally. There are exceptions to that rule (overlong words jumping to mind here) but all in all things are pretty viable.

astra
01-04-2009, 11:06 AM
I don't need auto-hyphenation. I prefer the way sony reader justifies the text on a whole screen.

tompe
01-04-2009, 11:53 AM
You must use hyphenation to get a good result. How bad the text will be without hyphenation depends a bit on the language. For example in Swedish you create new words by concatenating two words and no space between them and you get a lot more of longer words then in English.

nrapallo
01-09-2009, 01:23 AM
With about a week left, how would you interpret the results of this poll thus far.

I analzyed it on the basis of support for ePub, no (against) ePub or wait and see (maybe).

Attached are my findings for your consideration. Votes For ePub vs No (against) is currently running at almost 2 to 1!

To date, we have 65 .epub uploads to this forum, an increase of at least 3 fold in two weeks (from 18)... :chinscratch:

mtravellerh
01-09-2009, 02:36 AM
With about a week left, how would you interpret the results of this poll thus far.

I analzyed it on the basis of support for ePub, no (against) ePub or wait and see (maybe).

Attached are my findings for your consideration. Votes For ePub vs No (against) is currently running at almost 2 to 1!

To date, we have 65 .epub uploads to this forum, an increase of at least 3 fold in two weeks (from 18)... :chinscratch:

The increase is mostly due to Jellby and myself, I'm afraid. I do not understand why not more of my fellow book assemblers post their books in epub format with Calibre making such a good work of it. :chinscratch:

vivaldirules
01-09-2009, 07:46 AM
Lefty: "Well, Hugo?"
Hugo: "Well what?"

mtravellerh
01-09-2009, 08:08 AM
Oops, sorry. And vr here present, of course.

vivaldirules
01-09-2009, 08:20 AM
The increase is mostly due to Jellby and myself, I'm afraid. I do not understand why not more of my fellow book assemblers post their books in epub format with Calibre making such a good work of it. :chinscratch:

Well, I don't do it because I don't see the point of the effort. If the Sony Readers are the only ones that currently can read epub and they do that rather poorly (worse than LRF), then there is no immediate need for epub files, as I see it. Once some other devices can read them, I'd be willing to bet that there will be some particular nuance it will have that will mean that the epubs that have been generated already won't be rendered quite as nicely as if you set some particular option or parameter to this or that value. That will mean that they may have to be redone.

For example, many of us were making PRC format ebooks using BookDesigner. But Harry determined a better way to make them so that the illustrations would be displayed better. So now many people are making these with Mobipocket Creator and I need to go back and redo some of the ones I've already made. That's no problem. I'm hoping some people were able to read the ebooks I made anyway.

And then there's the IMP files many of us were making from BookDesigner. Along comes Nick's MOBI2IMP and I'm redoing the files I once made to make them better, too.

I'm not complaining, mind you. But if there is no need to be filled now, why spend the effort to create things that will probably have to be remade later anyway? I don't get that.

mtravellerh
01-09-2009, 08:32 AM
Well, I don't do it because I don't see the point of the effort. If the Sony Readers are the only ones that currently can read epub and they do that rather poorly (worse than LRF), then there is no immediate need for epub files, as I see it. Once some other devices can read them, I'd be willing to bet that there will be some particular nuance it will have that will mean that the epubs that have been generated already won't be rendered quite as nicely as if you set some particular option or parameter to this or that value. That will mean that they may have to be redone.

For example, many of us were making PRC format ebooks using BookDesigner. But Harry determined a better way to make them so that the illustrations would be displayed better. So now many people are making these with Mobipocket Creator and I need to go back and redo some of the ones I've already made. That's no problem. I'm hoping some people were able to read the ebooks I made anyway.

And then there's the IMP files many of us were making from BookDesigner. Along comes Nick's MOBI2IMP and I'm redoing the files I once made to make them better, too.

I'm not complaining, mind you. But if there is no need to be filled now, why spend the effort to create things that will probably have to be remade later anyway? I don't get that.

Well, I read a lot on my netbook and Calibre renders those epubs really fine. That good enough for you?

What about Ipods and Iphones? I guess there may be more users reading books on Iphones than on hardware readers (but that is just a guess).

Sony launches the 505 in Germany this year and Sony's promotion is anchored on the epub format and the german ebook sellers will sell epubs.

Epub, technically speaking, has the most future potential of all formats.

Mobi and LRF once were in the same situation than epub is now, but did you hesitate to create ebooks?

llasram
01-09-2009, 08:39 AM
Well, I don't do it because I don't see the point of the effort. If the Sony Readers are the only ones that currently can read epub and they do that rather poorly (worse than LRF), then there is no immediate need for epub files, as I see it.

Three reasons:

(1) OMG is it better than LRF. Having real italics instead of a programmatically slanted font is worth the price of admission alone. Image floats, direct HTML rendering (vs. necessarily incomplete conversion), SVG, etc are just icing on the cake.

(2) Plenty of other readers. Stanza, Calibre, FBReader (er... kind of), and definitely more to come.

(3) Clean clean clean source. If you produce a clean XHTML+CSS source of your book to produce other formats from, you can release that source as the EPUB version. If any else ever wants to convert to any other format, they can just grab the EPUB version and have the cleanest possible source to work from.

tompe
01-09-2009, 08:57 AM
(3) Clean clean clean source. If you produce a clean XHTML+CSS source of your book to produce other formats from, you can release that source as the EPUB version. If any else ever wants to convert to any other format, they can just grab the EPUB version and have the cleanest possible source to work from.

This is a very important point. I would never spend time formatting something for a dead-end terminal format. I would first invent an exchange format and write converter programs. But since ePub exists I do not have to do this.

vivaldirules
01-09-2009, 09:21 AM
Well, I read a lot on my netbook and Calibre renders those epubs really fine. That good enough for you?

Wouldn't Mobipocket Reader be a better option for these devices given the number of books available in that format?

What about Ipods and Iphones? I guess there may be more users reading books on Iphones than on hardware readers (but that is just a guess).

I was not aware that was significant. If it is and epub is the only format available, then I can see it as an important driver. I think I need to visit some of the other forums here. :o

Sony launches the 505 in Germany this year and Sony's promotion is anchored on the epub format and the german ebook sellers will sell epubs.

If you mean they'll be selling epub format books instead of LR*, then that is unfortunate, in my opinion - that is, for the readers who will have to put up with the inadequacies of the Sony firmware for rendering epubs.

Epub, technically speaking, has the most future potential of all formats.

Yes, but it wasn't clear that it has any present need whatsoever, or at least until you've mentioned the Apple devices.

Mobi and LRF once were in the same situation than epub is now, but did you hesitate to create ebooks?

Well, when I joined 18 months ago, Mobi, LRF, and IMP were the only formats being used and so that's what people have been making.


I appreciate your comments and info, mtravellerh. Thanks.

Jellby
01-09-2009, 10:47 AM
(3) Clean clean clean source. If you produce a clean XHTML+CSS source of your book to produce other formats from, you can release that source as the EPUB version. If any else ever wants to convert to any other format, they can just grab the EPUB version and have the cleanest possible source to work from.

That's the reason why I publish ePUB files. Well, it's not really my source format, because I've had to convert the books into ePUB, but once they're in ePUB format, it should be easier for anyone else to use them, and for me to eventually edit or convert them.

mtravellerh
01-09-2009, 01:31 PM
That's the reason why I publish ePUB files. Well, it's not really my source format, because I've had to convert the books into ePUB, but once they're in ePUB format, it should be easier for anyone else to use them, and for me to eventually edit or convert them.

One pretty important point for me, too. I am not a techie, my interests lie in ebook making and I want to be able to make good work and make it as simple as possible so that I can edit fast and transfer those changes as fast and as easy as possible to the various ebook formats.

Hadrien
01-10-2009, 02:02 PM
One pretty important point for me, too. I am not a techie, my interests lie in ebook making and I want to be able to make good work and make it as simple as possible so that I can edit fast and transfer those changes as fast and as easy as possible to the various ebook formats.

That's one thing that a workflow like Feedbooks is very good at, since the end formats are generated on the fly and we work with abstract elements.

=X=
01-11-2009, 04:42 PM
The increase is mostly due to Jellby and myself, I'm afraid. I do not understand why not more of my fellow book assemblers post their books in epub format with Calibre making such a good work of it. :chinscratch:

I tried ePUB many times on my PRS0-505 and I still prefer LRF and PDF over ePUB. The ePUB performance is just terrible on the SONY PRS-505. I cant see myself uploading ePUB when I myself would not use it.

=X=

Patricia
01-11-2009, 11:16 PM
Sony launches the 505 in Germany this year and Sony's promotion is anchored on the epub format and the german ebook sellers will sell epubs.

Epub, technically speaking, has the most future potential of all formats.


That's an interesting point of view, mtravellerh, and what you say makes a great deal of sense. I suppose that the question then arises, why do you still bother to create LRFs, if the EPubs are so good?

I'm currently not making EPubs because I use Book Designer and Mobipocket Creator, and can't be doing with yet another converter to use with each book. This may change, as I get round to exploring new tools.

=X=
01-11-2009, 11:56 PM
I'm currently not making EPubs because I use Book Designer and Mobipocket Creator, and can't be doing with yet another converter to use with each book. This may change, as I get round to exploring new tools.

You can create ePUB from calibre. Either buy running any2epub from the command line or you can create ePUB from BookCreator

The nice thing about calibre's ePUB is it takes sony 300KB files size limit
=X=

nrapallo
01-12-2009, 01:02 AM
You can create ePUB from calibre. Either buy running any2epub from the command line or you can create ePUB from BookCreator

The nice thing about calibre's ePUB is it takes sony 300KB files size limit
=X=

The above statement in bold holds mostly true for only Sony-PRS-505/700 users and I would have wished this limitation did not exist.

I view .epub as an ultimate ebook source format and cringe when I see the resulting .html (xhtml) included therein as output by Calibre (no offense intended) in accordance to the ADE limitation.



I know the switch --profile="None" exists (and am grateful Kovid has allowed this), but IMHO it is a shame to have this source format be "butchered" i.e. somewhat arbitrarily split, so as to meet this minuscule limitation. I mean what happened, so as to not use MB or GB capacity or storage, since 300KB... KB, I mean, is so 1990's!!!!!!!



I'm not shooting the messanger, but just the imposer of the limitation!

mtravellerh
01-12-2009, 01:08 AM
That's an interesting point of view, mtravellerh, and what you say makes a great deal of sense. I suppose that the question then arises, why do you still bother to create LRFs, if the EPubs are so good?

I'm currently not making EPubs because I use Book Designer and Mobipocket Creator, and can't be doing with yet another converter to use with each book. This may change, as I get round to exploring new tools.

Good question, Patricia. Currently I still "bother" to create LRFs simply because the PRS505 has deficiencies in rendering epubs and because there are a lot of people, like our friend X here present, that prefer to have LRFs .

I WAS already thinking about giving up LRF and even Mobi creation because it is really simple to make mobis and LRFs from the epub files but I think that it would be quite rude to oblige people to convert their books to their preferred format themselves.

So as long as there are no bandwidth limits, I will provide those formats. See, we could tell our friends that want IMPs that they could make them easily themselves by downloading mobis and converting them with Nicks wonderful Mobi2imp, but we don't, do we?

I think of it simply as a service, I guess.

mtravellerh
01-12-2009, 01:19 AM
The above statement in bold holds mostly true for only Sony-PRS-505/700 users and I would have wished this limitation did not exist.

I view .epub as an ultimate ebook source format and cringe when I see the resulting .html (xhtml) included therein as output by Calibre (no offense intended) in accordance to the ADE limitation.



I know the switch --profile="None" exists (and am grateful Kovid has allowed this), but IMHO it is a shame to have this source format be "butchered" i.e. somewhat arbitrarily split, so as to meet this minuscule limitation. I mean what happened, so as to not use MB or GB capacity or storage, since 300KB... KB, I mean, is so 1990's!!!!!!!



I'm not shooting the messanger, but just the imposer of the limitation!

Nick, my friend, I know that you feel strongly about this limitation, but let's be honest: This 300KB rule is not Kovid's and he has only implemented it because there ARE a lot of Sony readers around. The Bebooks seem to have still more problems with epubs (as far as I have heard) and so epubs would be limited to PCs and Iphones and we surely don't want that.

nrapallo
01-12-2009, 01:52 AM
Nick, my friend, I know that you feel strongly about this limitation, but let's be honest: This 300KB rule is not Kovid's and he has only implemented it because there ARE a lot of Sony readers around.

Oh, and just so as to be clear (clearer?), I don't view Kovid or Calibre as the culprit in imposing this limitation. :)

The Bebooks seem to have still more problems with epubs (as far as I have heard) and so epubs would be limited to PCs and Iphones and we surely don't want that.

Yes, I know this will be the case during the transition from a non .epub world to one with abundantly flowing .epub ebooks. I understand, more than most, that yesterday's (or year's) hardware just can't cut it sometimes. Even with my .imp reader, I envision .epubs will be used not directly but with the same conversion process that WILL BE required for my reader to view said .epub ebooks.

It doesn't mean that, in the future, when and if (:fingersx:) my reader gets a firmware upgrade to allow native reading of .epubs, my tune will change. Then I would expect my reader's conversion software to take a perfectly healthy .epub (i.e. no ADE limitation) and then convert it to my reader's required (and maybe somewhat compromised/crippled) support for .epubs.

Again my view is skewed in that I view .epub as a source and not for utlimate reading on my reader yet. If I did have a Sony reader capable of viewing .epub ebooks natively, the question I would have to wrestle with is would I want (1) the convenience of a Sony-specific .epub variant over (2) a non-compliant Sony .epub that I would need some software (like Calibre) to re-generate the .epub so that my Sony reader could read it.

My answer, would be a resounding endorsement of convenience over a "higher good", but the fact remains that in the foreseeable future the "higher good" can take a back seat, but not for the long haul. The hardware will catch up and the present day .epubs will be viewed in a different light.

So do I want the current situation to change? No, but I would want the imposer of the limitation (ADE) to eventually remove that limitation (or raise it sufficiently higher so as to not be a "hinderance" to the way ebooks are scripted in .html).

For ebooks with numerous chapters of limited size, this limitation is a moot point. For huge hyperlinked ebooks, like the kind I usually prepare, I just can't appreciate that my source .epub will be in a 100 or so pieces. I don't know, maybe it's just me, but I like to work on the whole rather than the parts.

Perhaps, in my perfect world vision, I would like non-compliant Sony (non-split) .epubs to be the norm and then let every ebook reader (BeBook/Sony/iPhone) that can't handle it to re-generate their variant of that .epub ebook (even if it is .lrf for the Sony-PRS500 or .imp for my reader or .prc for the Cybook Gen3/Hanlin/iLiad...).

I told you it was a RANT! ;)

=X=
01-12-2009, 09:12 AM
I view .epub as an ultimate ebook source format and cringe when I see the resulting .html (xhtml) included therein as output by Calibre (no offense intended) in accordance to the ADE limitation.

Hi Nick, now it's my turn to rant :)

For me this is only proof of how poor the ePUB spec is. Here is a committee that knows that the majority of their eBooks market are viewed on embedded devices, yet they make no provision for them. Either include them or exclude them but make it clear in the specification. I'm not saying "X" plaftorm can/can't run ePUB. But address the issue by stating what kind of memory is required. And have provisions in the spec for devices that have limited hardware constrains.

Another huge gaping hole in the ePUB standard is no one solution for DRM. Maybe that is wishful thinking on ePUB side that DRM will go way but it's here and real. This means more vendors aside from Adobe can spring up with their own DRM solution. Which means buying a book from one vendor will most likely not work with another. How open is that?

So now as ePUB consumers we now have to worry about what hardware we buy in addition worry about what DRM the book is using. Arh what a headache.

I've said it before and I'll say it again. I cannot get exited over ePUB it is a GREAT idea that was poorly executed. Right now where ePUB stands today is not a valid open solution but yet another tower. So with that said

... I'll stick to MOBI and LIT where I know the eBooks I buy will work on any platform they support.


=X=

llasram
01-12-2009, 09:19 AM
Oh, and just so as to be clear (clearer?), I don't view Kovid or Calibre as the culprit in imposing this limitation. :)

For my two cents -- as much as I like EPUB, I think the real culprit is the Open Container Format (OCF). The OCF basically boils down to "put all the book content in a ZIP file," which is delightfully simple, may be just a bit too simple.

Every other e-book format that I know the details of contains features which explicitly simplify seeking and incremental rendering. LIT compresses book content in 64k chunks, allowing random-access to compressed data; it contains an index of all explicit page-breaks within the book content; and it uses a simplified CSS rendering model without context selectors, allowing accurate rendering of an element given only its parents. Mobipocket compresses all ebook content in 4k chunks; and it uses a single-level rendering model, allowing rendering with almost no context.

In contrast, EPUB: (a) only allows compression on entire file streams; (b) contains no indices aiding incremental rendering; and (c) mandates a rendering model which requires full file context.

For example, EPUB allows a file which looks like:


<html>
<head>
<title>Example</title>
<style>.first ~ .last { display: none; }</style>
</head>
<body>
<p class="first">Displayed!</p>
[50 MB of content]
<p class="last"> Not displayed</p>
</body>
</html>


And requires that fully conformant systems render the content correctly, not displaying the final pagraph. Which in the context of the OCF means keeping 50MB of parsed markup around and in memory. Which is even worse on a device like the Sony Reader. On a system with a hard drive, the reader system could at least extract the compressed data to temporary files and build its indices from there. The Reader's flash filesystem is only good for so many writes, so instead it has to keep all the extracted file content in RAM, right along with all the RAM it need to actually parse the data and render it.

So unfortunately EPUB / the OCF needs some sort of arbitrary limit on the size of markup streams. It's the simplest solution to the problem without ditching the entire OCF and creating a completely different container format from scratch. I'm hoping that such an explicit -- if yes, somewhat higher -- arbitrary limit will eventually become part of the specification itself.

mtravellerh
01-12-2009, 09:27 AM
So unfortunately EPUB / the OCF needs some sort of arbitrary limit on the size of markup streams. It's the simplest solution to the problem without ditching the entire OCF and creating a completely different container format from scratch. I'm hoping that such an explicit -- if yes, somewhat higher -- arbitrary limit will eventually become part of the specification itself.

:chinscratch: Hey llasram, this is the first time I really understood everything you were saying! Do I progress or do you oversimplify? :rofl:

=X=
01-12-2009, 09:30 AM
@llasram exactly the point (the first point) I was making, but you said much more eloquently.

kovidgoyal
01-12-2009, 10:31 AM
I agree with llasram, once the size limit is raised a little higher, this becomes effectively a non-issue. Look at it this way, there has to be *some* size limit, since support for CSS means that the full HTML file ahs to be parsed. The size limit will grow inevitably with time until it becomes a non-issue. In the meantime, store your epub books with .zip extensions in calibre ;)

Jellby
01-12-2009, 10:52 AM
So unfortunately EPUB / the OCF needs some sort of arbitrary limit on the size of markup streams. It's the simplest solution to the problem without ditching the entire OCF and creating a completely different container format from scratch. I'm hoping that such an explicit -- if yes, somewhat higher -- arbitrary limit will eventually become part of the specification itself.

This is like line-length limits in the Fortran programming language. In the specification there are limits to the number of characters in each line and the number of "continuation lines" that can be used. There is, as far as I know, no real reason for these limitations other than it is not sensible to demand complying compilers to support unlimited number of characters per line. Each (or at least some) compiler must have a limit somewhere, and rather than having each compiler setting a limit by itself, it was preferable to put a limit in the specification, something that every compiler must support. Then it is up to each compiler to make it possible to use longer lines, but users should not expect this to work on every compiler.

Enough of off-topic. It's true that there should be a limit on what must be supported, there should be a minimum file size, number of styles, nesting level, etc. that must be supported by ePUB readers.

vivaldirules
01-12-2009, 10:57 AM
So 10 people here are producing epubs but not LRFs and another 9 are producing both. I find that amazing given that we have almost none in our library. And I still don't think I understand why, yet. There seems to be very few people here who read on an Apple device. Pardon me for my persistent ignorance.

zelda_pinwheel
01-12-2009, 11:05 AM
So 10 people here are producing epubs but not LRFs and another 9 are producing both. I find that amazing given that we have almost none in our library. And I still don't think I understand why, yet. There seems to be very few people here who read on an Apple device. Pardon me for my persistent ignorance.
people have only recently started producing epub files, so of course there are fewer of them than other formats. however there are currently 75 epub files uploaded. they are not very visible, as they are still in the "miscellaneous" forum with other formats, but soon there will be a dedicated epub forum. i prefer epub format to any other, myself.

Jellby
01-12-2009, 11:06 AM
So 10 people here are producing epubs but not LRFs and another 9 are producing both. I find that amazing given that we have almost none in our library.

Well... producing epubs does not necessarily mean uploading them here ;)

zelda_pinwheel
01-12-2009, 11:08 AM
Well... producing epubs does not necessarily mean uploading them here ;)

right, and there's also that. :rolleyes:

DaleDe
01-12-2009, 11:15 AM
The above statement in bold holds mostly true for only Sony-PRS-505/700 users and I would have wished this limitation did not exist.



The 300K limitation is not mostly true of Sony at all. It is always true of any ADE (Adobe Digital Editions) implementation, of which Sony happens to be one. Let's place the blame where it belongs.

Dale