feelings on .epub ?

[jbenny]

Originally Posted by kovidgoyal

I don't mean just rendering performance, I also mean pagination performance. I know for example that SONY's LRF layout routine is extremely fragile. I can easily create LRF files that are correct, but cause the reader to reset because it runs out of memory. And LRF is really, really simple compared to HTML.

And pagination takes a hell of along time for larger books. You wont notice this if you use connect, but if you transfer directly to a reader, then the hit is significant. I've often had to wait for upto 15mins for the reader to finish pagination.

If you can borrow a Nokia N800, take a look at the performance of FBReader when paging and displaying any of the ebook formats is supports. I haven't noticed it being slow at all, regardless of book length. I know FBReader doesn't currently support CSS or tables, but still, I've read some very long ebooks with it.

Another example is the trusty old Ebookwise 1150. You can select from two different font sizes on the device and the resulting repagination takes almost no time at all. The older RocketBook supported even more font choices.

I'm not sure what Sony is doing with pagination for the various font sizes, but that would seem to be specific to that format and that hardware. I don't see anything in the OPS spec that mentions anything like this. Now, if a particular hardware vendor decides to do something similar for some reason (I can't see why), that is outside the spec. Perhaps you can elaborate on exactly what is going on when an ebook is repaginated on a Sony and why it is done this way.

[kovidgoyal]

Originally Posted by DaleDe

I think an editor is important. It is also important to have tools to troubleshoot and fix problems with the document. For example css can be a bitch to work with when it doesn't do what you thought. There needs to be a way to find out the exact css entry that is causing particular text to appear as it does. Tools should also spot and fix grouping errors and in many cases special character problems should be dealt with with in automatic or prompted ways.

I doubt an editor that requires you to edit CSS is ever going to catch on. If you need to edit CSS you may as well use a text editor anyway.

[jbenny]

Originally Posted by Hadrien

Sure but keep in mind that Feedbooks doesn't exactly work like some kind of conversion service, we create the epub files completely on the fly the same way we display HTML for the website...

I wasn't suggesting that anyone use Feedbooks for converting their own content. I was just suggesting that with your experience, you could offer some helpful advice on ways to ease the process for the rest of us.

[jbenny]

Originally Posted by kovidgoyal

I doubt an editor that requires you to edit CSS is ever going to catch on. If you need to edit CSS you may as well use a text editor anyway.

Although the type of CSS required for an ebook isn't very complicated and can easily be done in a text editor, there are some nice CSS-specific editors out there. I don't have a URL handy, but somewhere I even saw a visual CSS editor and I think it was free.

[kovidgoyal]

In order to paginate a reflowable format like HTML or LRF, what's needed is that the reader software has to essentially render the whole book in one pass and save layout information (basically how many lines fit on a page at the current base font size).

The more complex the markup the longer it takes to do this. Without CSS HTML is actually simpler than LRF, so I'm not surprised that FBReader manages to paginate quickly.

Does the eb1150 software pre-paginate when transferring to the device? SONY's connect software does that and so you wont notice any slowdown if you use it, but if you transfer books directly, using a SD card for example, you see the slowdown.

[Hadrien]

Originally Posted by jbenny

I wasn't suggesting that anyone use Feedbooks for converting their own content. I was just suggesting that with your experience, you could offer some helpful advice on ways to ease the process for the rest of us.

OK. We had to deal with all the .ncx, container files, mimetype etc... But for CSS we're not doing fancy stuff yet: we keep the same stylesheets for every book, and every book is divided the same way into parts/chapters/sections/text.

I'd like to add hyphenation and real footnotes (in the footer, not a link) in our books, but I haven't found any real solution for this yet.

Right now, I'm working on producing epub files using RSS feeds...

[DaleDe]

Originally Posted by kovidgoyal

I doubt an editor that requires you to edit CSS is ever going to catch on. If you need to edit CSS you may as well use a text editor anyway.

I wasn't talking about editing css as a starting point but as a troubleshooting technique. If you look at the Indesign product is specially has issues that require CSS intervention to fix from time to time. I do think that, in the final analysis there should be the capability to get to the level of a text editor. Trying to guess at the magic high level control that makes something appear the way you want can be frustrating at times when you know that you can fix it at a low level by editing one line of text.

Dale

[kovidgoyal]

Originally Posted by jbenny

Although the type of CSS required for an ebook isn't very complicated and can easily be done in a text editor, there are some nice CSS-specific editors out there. I don't have a URL handy, but somewhere I even saw a visual CSS editor and I think it was free.

Because I come from a LaTeX background, to me a good editor should be one that forces you to use semantic structure. i.e. you specify what a particular document element is (a header, a list element, a dropcaps, an image, etc.) and let the software take care of layout details.

[DaleDe]

Originally Posted by kovidgoyal

In order to paginate a reflowable format like HTML or LRF, what's needed is that the reader software has to essentially render the whole book in one pass and save layout information (basically how many lines fit on a page at the current base font size).

The more complex the markup the longer it takes to do this. Without CSS HTML is actually simpler than LRF, so I'm not surprised that FBReader manages to paginate quickly.

Does the eb1150 software pre-paginate when transferring to the device? SONY's connect software does that and so you wont notice any slowdown if you use it, but if you transfer books directly, using a SD card for example, you see the slowdown.

The eb1150 pre-paginates both choices when the document is created. Sony does this as well when you use connect to get your book but the other tools do not do this for Sony thus the hit the first time you change font sizes. A similar problem exists in Digital Editions but even worse since the pagination isn't saved to you take the hit every time you change font sizes. This can be a significant problem as you point out and I think that the epub standard ignores it.

Dale

[kovidgoyal]

Originally Posted by DaleDe

I wasn't talking about editing css as a starting point but as a troubleshooting technique. If you look at the Indesign product is specially has issues that require CSS intervention to fix from time to time. I do think that, in the final analysis there should be the capability to get to the level of a text editor. Trying to guess at the magic high level control that makes something appear the way you want can be frustrating at times when you know that you can fix it at a low level by editing one line of text.

Dale

In that case what's needed as a first step is a command line tool that unpacks and repacks .epub files.

[Hadrien]

Originally Posted by kovidgoyal

Because I come from a LaTeX background, to me a good editor should be one that forces you to use semantic structure. i.e. you specify what a particular document element is (a header, a list element, a dropcaps, an image, etc.) and let the software take care of layout details.

That's exactly what we're doing with Feedbooks ^_^

(Well we're using LaTeX for our PDF output for this reason too)

[jbenny]

Originally Posted by Hadrien

OK. We had to deal with all the .ncx, container files, mimetype etc... But for CSS we're not doing fancy stuff yet: we keep the same stylesheets for every book, and every book is divided the same way into parts/chapters/sections/text.

I'd like to add hyphenation and real footnotes (in the footer, not a link) in our books, but I haven't found any real solution for this yet.

Right now, I'm working on producing epub files using RSS feeds...

Yes, footnotes need further investigation. I haven't tried doing footnotes yet, but was trying something similar, which didn't work. I wanted to use CSS to provide a popup window that gave you a definition when you either hovered or clicked on a particular word. It worked great on a web browser, but not in Digital Editions. After reading the OPS spec more carefully, I discovered that "position" and "z-index" are allowed, but not required in the OPS spec. It is a shame that they left these out, as doing word lookup and even popup footnotes could easily be done this way.

[kovidgoyal]

Originally Posted by DaleDe

The eb1150 pre-paginates both choices when the document is created. Sony does this as well when you use connect to get your book but the other tools do not do this for Sony thus the hit the first time you change font sizes. A similar problem exists in Digital Editions but even worse since the pagination isn't saved to you take the hit every time you change font sizes. This can be a significant problem as you point out and I think that the epub standard ignores it.

Dale

The problem with an in file pagination solution like eb1150 is that you are then tied to a particular reader implementation (screen size, font size and layout algorithm). I am very concerned that it may not be possible to layout HTML+CSS on existing devices quickly enough, in which case .epub is useless as anything other than an archival format, and as for archiving a zipped up set of HTML files with a opf for metadata and structure information is good enough.

[jbenny]

Originally Posted by kovidgoyal

Because I come from a LaTeX background, to me a good editor should be one that forces you to use semantic structure. i.e. you specify what a particular document element is (a header, a list element, a dropcaps, an image, etc.) and let the software take care of layout details.

Yes, an editor geared towards epub generation would be a very nice thing. InDesign is not specifically geared toward epub and even after generating an epub with it, you have to use a text editor to fix some things.

[jbenny]

Originally Posted by kovidgoyal

In that case what's needed as a first step is a command line tool that unpacks and repacks .epub files.

An .epub is just a .zip with a different extension. No special tools required. That was one smart thing they did with the spec.