View Full Version : feelings on .epub ?


aapezzuto
10-24-2007, 06:46 AM
I'm just trying to feel out the waters right now on .epub

jbenny
10-24-2007, 06:55 AM
Your poll needs at least one additional choice: "epub shows promise and I'm using it now (or trying to)"

nekokami
10-24-2007, 08:37 AM
Being able to select more than one of the choices would have been nice.

tribble
10-24-2007, 08:46 AM
It would be great to have an ebook standard, which allows for content to be read in many viewers with lamost anything that can be done using html. Though i hear many publishers be very reluctant to use this new format.

Hadrien
10-24-2007, 11:21 AM
Your poll needs at least one additional choice: "epub shows promise and I'm using it now (or trying to)"

I need this additional choice too.

NatCh
10-24-2007, 11:41 AM
My vote would be for "I'm hopeful that .epub might finally give us a de facto 'standard' that all concerned will buy into" -- or something like that. :nice:

kovidgoyal
10-24-2007, 11:47 AM
I am concerned about the performance impact of rendering HTML on an embedded device, so I'm going to remain skeptical until I see an embedded reader.

Robert Marquard
10-24-2007, 11:51 AM
It should be the same as for Plucker. Zip compession and HTML.

jbenny
10-24-2007, 12:00 PM
I am concerned about the performance impact of rendering HTML on an embedded device, so I'm going to remain skeptical until I see an embedded reader.

Numerous PDAs have been rendering HTML with adequate performance for some years now. I use my Nokia N800 to view complicated web sites and the performance is adequate. The current crop of dedicated readers use similar hardware to a modern PDA.

Given the subset of XHTML that the OPS spec requires and the fact that you would not expect an ebook to support everything that a full web browser does, I don't think performance is going to be an issue, if the rendering software does a good job (I'm thinking about Digital Editions and how poorly it performs on a desktop PC).

jbenny
10-24-2007, 12:02 PM
It should be the same as for Plucker. Zip compession and HTML.

Good example. Another is MobiPocket, which is also HTML-based. To check this, take any of the MobiPocket ebooks posted here and use either PDBShred or MakeDoc to extract the HTML.

aapezzuto
10-24-2007, 12:10 PM
I don't care if it ever gets read natively on devices... If it is a good standard, and we can start converting all of our books to a single format... then regenerate them from there... Thats fine!

So, anyone willing to put their 2 cents in on what it will take for this format to become popular with people who archive their own books?

Im guessing they will need to build a good editor that can be used to easily alter/generate .epub files... without having to figure out all the compression levels for files, and mime types... etc...

Maybe a version of the spec that was meant to be read by a user rather than a software rendering engineer.

kovidgoyal
10-24-2007, 12:26 PM
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.

jbenny
10-24-2007, 12:37 PM
I don't care if it ever gets read natively on devices... If it is a good standard, and we can start converting all of our books to a single format... then regenerate them from there... Thats fine!

So, anyone willing to put their 2 cents in on what it will take for this format to become popular with people who archive their own books?

Im guessing they will need to build a good editor that can be used to easily alter/generate .epub files... without having to figure out all the compression levels for files, and mime types... etc...

Maybe a version of the spec that was meant to be read by a user rather than a software rendering engineer.

Here are three pages that discuss creating an epub by hand. The first one is the most detailed.

http://www.hxa7241.org/articles/content/epub-guide_hxa7241_2007.html
http://www.ebooktechnologies.com/OCFUsingWinZip/OCFUsingWinZip.htm
http://www.jedisaber.com/eBooks/tutorial.asp

The structure of OPS 2.0 (epub) is in many respects much simpler than the previous OEBPS spec. This makes generating an epub with nothing more than a text editor entirely possible and actually, not too painful.

Only a few files (which are all text) are specific to the OPS spec. The content itself is valid XHTML 1.1 and CSS 2, which is usable in a wide variety of other ways, and can be generated by the usual web creation tools. The only caveats are that the OPS spec defines a subset of XHTML that must be supported, leaving the rest as optional. The same with CSS. This is not a major problem, as the vast majority of XHTML and CSS are required.

The few files specific to OPS are also text. In fact, they are XML. Since the content of these XML files will be very similar from one ebook to another, you can easily use one file as a template for creating another ebook.

As you can see when you have read the referenced web pages, there is only one mimetype file required and it is only one line. It doesn't change, so you can keep using the same file for all your epub ebooks. As far as compression, only this mimetype files must have no compression. The other files use standard Zip compression.

One thing to be cautious about when reading those web pages: they were written before the OPS 2.0 spec was finalized (which was very recently). There are a few differences between what those web pages recommend and the final spec requires. Nothing major, but you need to double check things.

We still need more tools to make creation of an epub easier. Doing it with a text editor is not for everyone. Even I would prefer a tool dedicated to the task. Perhaps Hadrian can offer some helpful advice, since he has setup some type of automated system on his web site.

DaleDe
10-24-2007, 12:43 PM
I don't care if it ever gets read natively on devices... If it is a good standard, and we can start converting all of our books to a single format... then regenerate them from there... Thats fine!

I was very happy when I learned I could take apart an epub document and fix it or modify it for use on my device. Regeneration is an important feature of epub.

So, anyone willing to put their 2 cents in on what it will take for this format to become popular with people who archive their own books?

Im guessing they will need to build a good editor that can be used to easily alter/generate .epub files... without having to figure out all the compression levels for files, and mime types... etc...

Maybe a version of the spec that was meant to be read by a user rather than a software rendering engineer.

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 think there needs to be at least three documents. One for the software engineer, one of the author, and one for the user. The user document is a key piece to selling the epub standard by showing the benefits and establishing the expectation. The author document is critical and supplements the authoring tools. An author is not necessarily a technical person who can edit html files manually. There also needs to be a collection of tips for authors to help with special case problems and provide examples.

I think there are more items that require implementation in the standard but what we have is a good start. I have been putting together requirements for a possible future eb1150 device on my web site. Many of the items, as it turns out, are applicable to any epub solution.

Dale

Hadrien
10-24-2007, 12:47 PM
Perhaps Hadrian can offer some helpful advice, since he has setup some type of automated system on his web site.

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

jbenny
10-24-2007, 12:51 PM
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
10-24-2007, 12:53 PM
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
10-24-2007, 12:55 PM
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
10-24-2007, 12:58 PM
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
10-24-2007, 01:00 PM
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
10-24-2007, 01:01 PM
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
10-24-2007, 01:01 PM
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
10-24-2007, 01:05 PM
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
10-24-2007, 01:05 PM
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
10-24-2007, 01:08 PM
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
10-24-2007, 01:08 PM
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
10-24-2007, 01:14 PM
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
10-24-2007, 01:14 PM
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
10-24-2007, 01:18 PM
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
10-24-2007, 01:19 PM
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.

Hadrien
10-24-2007, 01:20 PM
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.

Some of the sample files used a separate XML file and it displayed a little cross next to a word to signify that there's a footnote (clicking on the footnote displayed the xml file with the footnotes). I do understand that real footnote support is a lot more complicated to display for a reflowable format, but that's one of those key features that we need if we'd like to display e-books like real books.

nekokami
10-24-2007, 01:21 PM
I like footnotes indented after the end of the current paragraph, personally.

wallcraft
10-24-2007, 01:24 PM
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.

From Producing ePub Documents from InDesign (http://blogs.adobe.com/digitaleditions/indesign-epub.html):
Chapters: a good ePub file should contain a separate XHTML stream for each section or chapter. So every section of your eBook should be created as a different document in InDesign. This is especially important in long or complex eBooks. Dividing the work into separate documents makes styling each section easier, and will make the pages render faster in ADE. I don't think most existing .epub books (or .LIT or .MOBI books, which being OEB-based can do the same thing) have 1 file per chapter, perhaps because most publishers want to target "simple HTML" e-book formats too. I find it surprising that it matters whether chapters are in separate files or not, but perhaps this is an Adobe Digital Editions specific implementation detail.

FBReader can take a few seconds to layout (say) a multi-MB CHM file, but its primary limitation is that loads the entire document into memory. This (presumably) improves speed, but can be a limitation for really long documents. This is on FBReader's list of thinks to fix, but memory is so cheap that I'm not sure this is a big deal - particularly for Linux devices with virtual memory.

kovidgoyal
10-24-2007, 01:29 PM
Actually I don't see why supporting footnotes in a reflowable format is hard from a reader implementation point of view. You just need an bit of extra branching in the layout routine. On the other hand, I actually prefer hyperlinked footnotes to in page footnotes, they are less intrusive and almost as easy to use.

kovidgoyal
10-24-2007, 01:35 PM
From Producing ePub Documents from InDesign (http://blogs.adobe.com/digitaleditions/indesign-epub.html):
I don't think most existing .epub books (or .LIT or .MOBI books, which being OEB-based can do the same thing) have 1 file per chapter, perhaps because most publishers want to target "simple HTML" e-book formats too. I find it surprising that it matters whether chapters are in separate files or not, but perhaps this is an Adobe Digital Editions specific implementation detail.

FBReader can take a few seconds to layout (say) a multi-MB CHM file, but its primary limitation is that loads the entire document into memory. This (presumably) improves speed, but can be a limitation for really long documents. This is on FBReader's list of thinks to fix, but memory is so cheap that I'm not sure this is a big deal - particularly for Linux devices with virtual memory.

I think ADE treats each XHTML stream as a logical page that is then split up into separate pages depending on font size and screen size. It keeps a single logical page in memory at one time. As a result having a single very long logical page is likely to cause swapping and slow down page turns. The same is true for LRF (except that there it is <Page> elements than should not be too long instead of individual files.

Memory does seem to be a problem when it comes to handhelds as manufactures want to keep prices as low as possible, which often means they skimp on RAM.

Hadrien
10-24-2007, 01:45 PM
Actually I don't see why supporting footnotes in a reflowable format is hard from a reader implementation point of view. You just need an bit of extra branching in the layout routine. On the other hand, I actually prefer hyperlinked footnotes to in page footnotes, they are less intrusive and almost as easy to use.

Extra layout and more rendering issues than with XHTML+CSS.

DaleDe
10-24-2007, 01:47 PM
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.

It is true that any pagination solution requires this knowledge. It is even more important for technical manuals that may reference a page number somewhere else in the document which, in the case of ebooks, is a variable.

Taking the hit to reformat a book one time is a price that may be workable but in the long run it should not be required every time a user reselects that size so the standard could permit the build default sizes and then adjust as needed. There are standard screen sizes and font sizes so this should be possible and then the standard should provide a mechanism to store this data. This way the user can buy an epub book and have it automatically paginate for the device they choose. If they switch devices they would have a one time installation hit the first time. The standard just needs to define a format for the data storage in the .epub file.

The nice thing about zip files is that you can easily add data like this on the fly when the epub file is delivered.

Dale

Hadrien
10-24-2007, 01:48 PM
I don't think most existing .epub books (or .LIT or .MOBI books, which being OEB-based can do the same thing) have 1 file per chapter, perhaps because most publishers want to target "simple HTML" e-book formats too. I find it surprising that it matters whether chapters are in separate files or not, but perhaps this is an Adobe Digital Editions specific implementation detail.


Try opening War & Peace with DE and FBReader: you'll notice a huge difference.

Epub file: http://www.feedbooks.com/discover/get_epub/83

kovidgoyal
10-24-2007, 02:01 PM
Extra layout and more rendering issues than with XHTML+CSS.

Not really, just add special CSS class say "epub_footnote" then the layout engine renders the contents of the footnote in a block, checks if the block fits on the current page, if yes, adds it to the bottom if no puts it on the footnote stack for the next page. Shouldn't significantly change the rendering complexity.

Hadrien
10-24-2007, 02:11 PM
Not really, just add special CSS class say "epub_footnote" then the layout engine renders the contents of the footnote in a block, checks if the block fits on the current page, if yes, adds it to the bottom if no puts it on the footnote stack for the next page. Shouldn't significantly change the rendering complexity.

It acts like a "float" element that's correct. In some books, you can have very long footnotes though, and in this case, p-book usually display them on the next page too.

DaleDe
10-24-2007, 02:16 PM
Not really, just add special CSS class say "epub_footnote" then the layout engine renders the contents of the footnote in a block, checks if the block fits on the current page, if yes, adds it to the bottom if no puts it on the footnote stack for the next page. Shouldn't significantly change the rendering complexity.

This is not as simple as you say if the book is large and the layout engine is pre-paginating the entire document. It would have to scan the document and find every instance of a footnote and adjust as needed. This could take a long time for a ebook reader with its limited processor to do. People are already complaining about the start up time for a book. Making a pop up footnote in this case makes more sense since it need not be allowed for in the document pagination.

We may need to take a look at the pagination requirement and determine what is really needed. How important is knowing the last page number of a book? How important is knowing the page number of the next chapter in a book? Are these essential features?

Specific to footnotes - Where should footnotes go? end of page, end of chapter, end of book? Is links enough with a return capability?

It is interesting to look at MobiPocket on a PDA. They only provide a percentage of the book progress bar and links to chapter starts. They do not currently paginate the book but instead remember a few pagination points for previous pages so you can back up a little (5 pages I believe). This is because they provide all sorts of font sizes and the user can change them at any time. The ebook standards limit the font choices to 7 sizes so this can help a little and you can likely limit the initial pagination to a subset of those but it is still something to look at.

Dale

jbenny
10-24-2007, 02:29 PM
I don't think most existing .epub books (or .LIT or .MOBI books, which being OEB-based can do the same thing) have 1 file per chapter, perhaps because most publishers want to target "simple HTML" e-book formats too. I find it surprising that it matters whether chapters are in separate files or not, but perhaps this is an Adobe Digital Editions specific implementation detail.


Actually, most of the LIT ebooks I have looked at do make each chapter a separate file. This isn't really much harder to create than one huge file. Also, for ebook display purposes, separate files do make more sense.

In my reading of the OPS spec, they do recommend using separate files, since that is how they will show up in the TOC. Also, with separate files, you can do things with the reading order.

jbenny
10-24-2007, 02:30 PM
Some of the sample files used a separate XML file and it displayed a little cross next to a word to signify that there's a footnote (clicking on the footnote displayed the xml file with the footnotes). I do understand that real footnote support is a lot more complicated to display for a reflowable format, but that's one of those key features that we need if we'd like to display e-books like real books.

Can you remember a specific sample file which did footnotes? I'd like to take a look at it.

jbenny
10-24-2007, 02:35 PM
I like footnotes indented after the end of the current paragraph, personally.

That would be the easiest way to do them from a content creation standpoint.

In the OPS spec, they define "oeb-page-head" and "oeb-page-foot" for running header and footers on a page. Perhaps something similar could be added for footnotes. The only downside is that the head/foot are optional, according to the spec. I think it should be required that readers render these, but allow the user to optionally disable their display when reading.

kovidgoyal
10-24-2007, 02:40 PM
This is not as simple as you say if the book is large and the layout engine is pre-paginating the entire document. It would have to scan the document and find every instance of a footnote and adjust as needed. This could take a long time for a ebook reader with its limited processor to do. People are already complaining about the start up time for a book. Making a pop up footnote in this case makes more sense since it need not be allowed for in the document pagination.

We may need to take a look at the pagination requirement and determine what is really needed. How important is knowing the last page number of a book? How important is knowing the page number of the next chapter in a book? Are these essential features?

Specific to footnotes - Where should footnotes go? end of page, end of chapter, end of book? Is links enough with a return capability?

It is interesting to look at MobiPocket on a PDA. They only provide a percentage of the book progress bar and links to chapter starts. They do not currently paginate the book but instead remember a few pagination points for previous pages so you can back up a little (5 pages I believe). This is because they provide all sorts of font sizes and the user can change them at any time. The ebook standards limit the font choices to 7 sizes so this can help a little and you can likely limit the initial pagination to a subset of those but it is still something to look at.

Dale

No a pre-paginater goes page by page, so whenever it encounters a footnote, it just needs to check if the footnote goes on the current page, or the next page. Personally, I think hyperlinked footnotes to the end of the file, with support for back in the reader software is the best solution.

I think that knowing how many pages there are in the book is important from the perspective of people migrating from paper books. Also from the perspective of books with hyperlinks in them, which increasingly ebooks will have, full pre-layout is important for rendering speed.

aapezzuto
10-24-2007, 02:47 PM
wow, battle of the footnotes....

footnotes and pagenation are questions of hardware/software implementation... The only real bearing I can see they would have on assessing a format is deciding if it is asking to much from the current technology. I dont like the idea of every reader/software starts storing its short cuts and work arounds in my files... let it create a parallel file that it can get rid of at its leisure... The last thing i need when cleaning up my computer is to have to open every book i own and sweep out the extra stuff from the junk drawer.

with foot notes the real end all question is... how picky are you about exactly how it looks... because if you want perfect control, you will need a human overseeing it... use pdf... if you don't care exactly how it works its a much easier task...

so at the heart of this, has the argument become .epub is a decent format... a little new to have good support, and it is/isn't reasonable for low power computing devices natively?

jbenny
10-24-2007, 02:47 PM
Making a pop up footnote in this case makes more sense since it need not be allowed for in the document pagination.

...

Specific to footnotes - Where should footnotes go? end of page, end of chapter, end of book? Is links enough with a return capability?

...

Dale

Yes, popups for footnotes and word definitions would probably be the most workable solution, without getting into the complexities of page reformatting on the reader. However, as I mentioned above, the two CSS properties needed to make a popup work are not required by the OPS spec. And as I have seen, DE did not implement them.

Even links to a footnote may not work. Again, as I have noted elsewhere, DE does not have a "Back" button, or any way to return from a hyperlink jump. The OPS spec doesn't seem to address this directly, although support for the <a> tag is required. It seems an oversight that Adobe would leave out a "Back" button. I have tried three other methods to implement the "Back" button functionality. All of them work in a browser, but one method doesn't work at all in DE and the other two take me to the very beginning of the file, not back to where I came from. I see this a a problem with DE and not with epub itself.

IceHand
10-24-2007, 02:53 PM
There's also the option to not display page numbers at all, but instead use a progress bar and/or percentage. I know, not the best way to handle this problem, but it certainly would be a workaround.

Edit: Oh, I just saw that this has been mentioned already :smack:

jbenny
10-24-2007, 02:59 PM
wow, battle of the footnotes....

footnotes and pagenation are questions of hardware/software implementation... The only real bearing I can see they would have on assessing a format is deciding if it is asking to much from the current technology. I dont like the idea of every reader/software starts storing its short cuts and work arounds in my files... let it create a parallel file that it can get rid of at its leisure... The last thing i need when cleaning up my computer is to have to open every book i own and sweep out the extra stuff from the junk drawer.

with foot notes the real end all question is... how picky are you about exactly how it looks... because if you want perfect control, you will need a human overseeing it... use pdf... if you don't care exactly how it works its a much easier task...

so at the heart of this, has the argument become .epub is a decent format... a little new to have good support, and it is/isn't reasonable for low power computing devices natively?

I think that as far as the epub spec goes right now, it is an improvement over OEB. It is also good in the fact that several major players were behind its development (with some notable exceptions).

As far as rendering on small devices, I don't think that it will be any more difficult than current formats that are based on OEB. In fact, it may be easier, since the structure of XHTML 1.1 is more stringent and it has dropped several old HTML tags.

Since epub is designed to be reflowable, we don't need the restrictions of a fixed format like PDF. However, there does need to be some easy, standardized way to display footnotes and such. I think this is one area where the OPS spec needs improvement.

andym
10-24-2007, 04:10 PM
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.

Mobipocket handles html perfectly well (though on Windows Mobile devices it still only supports a limited subset of the epub standard - eg very limited support for stylesheets) repagination is excellent.

Until there's an reader that will read epub on a pda my vote is going to have to be 'I'll wait and see'.

Surely the most sensible user-friendly way to show a footnote (unless you are dealing with citations in an academic text) is with the title attribute and a tooltip?

DaleDe
10-24-2007, 04:24 PM
Mobipocket handles html perfectly well (though on Windows Mobile devices it still only supports a limited subset of the epub standard - eg very limited support for stylesheets) repagination is excellent.


I am surprised you say repagination is excellent. It doesn't even do repagination on PDA's. Perhaps you are saying it is fast because you don't know what pagination is doing. It is fast because it doesn't do any work. It does not compute the pages in the document at all. It only shows the size and a percentage of how far you have read on the bar at the bottom. It cannot predict when the next chapter will start. If you jump to a new chapter and then backup you will end up with a different looking page than if you approach the page in the forward direction.

My understanding is that the version for Linux does do pagination but I have not observed this version. The Linux version does not do bookmarks I am told. Bookmarks are related to pagination in that, in a real book, you bookmark pages while MobiPocket bookmarks a place in the file by distance.

Dale

kovidgoyal
10-24-2007, 04:27 PM
Surely the most sensible user-friendly way to show a footnote (unless you are dealing with citations in an academic text) is with the title attribute and a tooltip?

That's assuming your device has some sort of mouse interface and that the footnote is small, which is not always the case, for e.g. the SONY Reader. I think hyperlinks are more robust.

Hadrien
10-24-2007, 04:39 PM
That's assuming your device has some sort of mouse interface and that the footnote is small, which is not always the case, for e.g. the SONY Reader. I think hyperlinks are more robust.

Pop-ups are neat if you have some sort of touch screen or a mouse. For dedicated e-ink readers, displaying footnotes in the footer or a hyperlink should work a lot better.

I agree with kovidgoyal on this.

nekokami
10-24-2007, 04:54 PM
Pop-ups are neat if you have some sort of touch screen or a mouse. For dedicated e-ink readers, displaying footnotes in the footer or a hyperlink should work a lot better.
Even though I have an iLiad and could click a link to get a popup or a hyperlink, I'd rather just see the footnote below the paragraph it relates to, personally. I guess that's because I'm thinking about fiction authors like Terry Pratchett and Jonathan Stroud, who use footnotes extensively. For academic purposes, endnotes with hyperlinks would be fine. (How would you activate a hyperlink on something like the Sony Reader?)

kovidgoyal
10-24-2007, 05:15 PM
A footnote at the end of a paragraph is just another paragraph with special formatting. So why call it a footnote at all?

jbenny
10-24-2007, 05:21 PM
Pop-ups are neat if you have some sort of touch screen or a mouse. For dedicated e-ink readers, displaying footnotes in the footer or a hyperlink should work a lot better.

I agree with kovidgoyal on this.

Hyperlinks are the easiest to create and the least trouble for the reader to deal with. Now, if only DE had a "Back" button, so we could return from that hyperlink jump. Hopefully, when Adobe ports DE to the Sony, they will fix this oversight (and also fix it in the Windows version).

Hadrien
10-24-2007, 05:29 PM
Hyperlinks are the easiest to create and the least trouble for the reader to deal with. Now, if only DE had a "Back" button, so we could return from that hyperlink jump. Hopefully, when Adobe ports DE to the Sony, they will fix this oversight (and also fix it in the Windows version).

Well, on the Sony you always have a "Back" button. No fix needed.

DaleDe
10-24-2007, 05:37 PM
Well, on the Sony you always have a "Back" button. No fix needed.

Just because there is a button labeled back does not mean that the software will know what to do with it.

Hadrien
10-24-2007, 05:42 PM
Just because there is a button labeled back does not mean that the software will know what to do with it.

Hopefully it will, or else it would be very poorly designed ^_^

Oh and don't expect Adobe DE on the Sony PRS to be anything like the desktop version. To run on such a device it should be an almost complete rewrite.

jbenny
10-24-2007, 06:08 PM
Hopefully it will, or else it would be very poorly designed ^_^


Well, the Windows version is already poorly designed, since it is missing that functionality. Any bets on whether they make the same mistake on the Sony?

jbenny
10-25-2007, 01:40 AM
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

Another way to handle pagination is how MS Reader does it. When you open an ebook, pagination is done in the background. While this is going on, you can start reading immediately. If you change font size, another background pagination. I don't know if it saves this information to reuse. I'll have to do a test and see.

Edit: Just did a quick test with MS Reader. I does save the pagination information for an ebook when you change font sizes, but only until you close Reader. This isn't bad, but I think saving this information for the last 5-10 ebooks you read would be a better idea.

An epub reader that did background pagination like MS reader does, but saved that information for re-use would certainly be a workable solution.

andym
10-25-2007, 03:36 AM
I am surprised you say repagination is excellent. It doesn't even do repagination on PDA's. Perhaps you are saying it is fast because you don't know what pagination is doing. It is fast because it doesn't do any work. It does not compute the pages in the document at all. It only shows the size and a percentage of how far you have read on the bar at the bottom.

Mobipocket show the page number, if you change the font size then the page number changes - if that isn't repagination then what is?

DaleDe
10-25-2007, 10:47 AM
Mobipocket show the page number, if you change the font size then the page number changes - if that isn't repagination then what is?

Try this test. Jump to a new chapter and then back up one page. Look at the page and see if it is a full page down to the bottom. Now go to the previous chapter and work your way forward to that same page. Does it look the same? If not this the document is not paginated. It is easy to fake a page number that represents the distance into the file or other measures. MobiPocket is pretty good at hiding the repagination issue. For example it temporarily remembers some pagination such that if you read to a new chapter going forward and then back up a page it will look ok since it remembers where it was while going forward.

Also a paginated document knows the last page number always. Does mobi know? A progress bar is easy to show based on file sizes.

Dale

JSWolf
10-25-2007, 11:13 AM
LRF shows the new # of ## when you change the page size and the internal ToC shows the new page numbers as well.

aapezzuto
10-25-2007, 02:55 PM
I think footnotes are a strange literary phenomenon. They are an interjection (http://en.wikipedia.org/wiki/Interjection) that is allowed to have its own lexical formating, That in no way interrupts the tempo, rhyming scheme, or other literary devices of the sentence that contains it. On top of that, by nature of its identity, is known to not have a continuous contextual flow with the rest of the content. Really a wonderful way to represent the way that words will trigger associations with other thoughts.
Their other use, is somewhat less interesting, to cite a source of information.

I bring all this up because it seems that though if thought about, it is already known, It is not being focused on. are there other reasonable formating methods that can do both these things with similar grace, or is it in fact a need that .epubs next incarnation needs to address?

-----------------------
I have always felt that english needed a sarcasm mark... That would help prevent a sarchasm (http://www.unwords.com/unword/sarchasm.html) while reading, or messaging online.

jbenny
10-25-2007, 04:13 PM
I have two thoughts on this. One, hyperlinks would be an acceptable way to deal with footnotes (essentially making them endnotes). The current problem is that of the few readers that presently support epub, DE has no way to return from a hyperlink jump, rendering the method useless. Since DE is the big gorilla right now, this is a major problem.

My second thought is that other means of dealing with out-of-context information like footnotes and definitions can be more useful and less disruptive to the reading process. In particular, I'm thinking about popups, but other methods may be suitable. The problem with popups is that some of the properties required to make them work are not mandated by the epub spec. You can use them, but there is no guarantee that they will work on any given reader. As I have mentioned before, DE doesn't work with popups.

I think these issues need to be addressed, both in current reader software and in future versions of the epub spec.

andym
10-25-2007, 05:35 PM
Try this test. Jump to a new chapter and then back up one page. Look at the page and see if it is a full page down to the bottom. Now go to the previous chapter and work your way forward to that same page. Does it look the same?

Why would I want to do any of this? What possible use is it? Sorry but I can't see the relevance.

If I am reading a book in mobipocket it will tell me I am at say page 999 out of 2000. If I want to go to page 1999 I can do, if I want to go back to page 500 I can do. Why should I care whether the software is doing it for real or faking it?

DaleDe
10-25-2007, 05:39 PM
Why would I want to do any of this? What possible use is it? Sorry but I can't see the relevance.

If I am reading a book in mobipocket it will tell me I am at say page 999 out of 2000. If I want to go to page 1999 I can do, if I want to go back to page 500 I can do. Why should I care whether the software is doing it for real or faking it?

You asked for a way to test this and I gave it to you. It was only a test to demonstrate behavior. If you don't want to do it why ask? If you are happy with the behavior of a program then I am happy for you.

Dale

kovidgoyal
10-25-2007, 05:50 PM
Why would I want to do any of this? What possible use is it? Sorry but I can't see the relevance.

If I am reading a book in mobipocket it will tell me I am at say page 999 out of 2000. If I want to go to page 1999 I can do, if I want to go back to page 500 I can do. Why should I care whether the software is doing it for real or faking it?

Because its behavior wont be consistent.

andym
10-26-2007, 01:00 PM
You asked for a way to test this and I gave it to you. It was only a test to demonstrate behavior. If you don't want to do it why ask? If you are happy with the behavior of a program then I am happy for you.

Dale

That's precisely the point, I didn't ask. And I don't care. You (and Kovid) seem to be intent on proving some arcane point whose relevance to anything is entirely lost on me.

kovidgoyal
10-26-2007, 01:09 PM
It's not an arcane point, but it seems to be beyond your ability to comprehend, so I suggest moving on. You don't have anything fruitful to contribute to this discussion.

EDIT: I apologize if that was rude. The point is that with fake pagination if the file has a lot of hyperlinks, or is read in random access mode, behavior will be inconsistent, since page numbers of the same content will change on each pass.

DaleDe
10-26-2007, 03:08 PM
That's precisely the point, I didn't ask. And I don't care. You (and Kovid) seem to be intent on proving some arcane point whose relevance to anything is entirely lost on me.


You said (and I quote): if you change the font size then the page number changes - if that isn't repagination then what is?

That is your exact question! I guess it was rhetorical but I thought originally that you were really interested. Sorry for the inconvenience.

Dale

bowerbird
10-29-2007, 12:34 PM
this is a very interesting discussion. i'm pleased to see that there are
several people here who recognize the correct issues to be pondering.

i also think this demonstrates that one cannot judge an e-book _format_
in the absence of both its _viewer-programs_ and _authoring-tools_...

if a particular format has viewers that are powerful and beautiful, and
authoring-tools that make the creation task simple, it's a good format.
if not, then that format isn't gonna be much good to people...

i'd like to see _that_ as a possible answer on this poll...
(interesting to see that the answer that is closest to that
is the one that's leading the poll...)

-bowerbird

bowerbird
10-29-2007, 12:37 PM
it really drives me batty that mobipocket's "pages" aren't consistent.
it's laughable to me that they thought they could get away with that.
and even more laughable that amazon paid $3.5 million for such crap.

-bowerbird

HarryT
10-29-2007, 01:02 PM
Also a paginated document knows the last page number always. Does mobi know? A progress bar is easy to show based on file sizes.

Dale

Yes, Mobi shows you the last page number at the right hand side of its progress bar. This is true on both the iLiad and Pocket PC versions of the Mobi reader.

HarryT
10-29-2007, 01:07 PM
it really drives me batty that mobipocket's "pages" aren't consistent.
it's laughable to me that they thought they could get away with that.
and even more laughable that amazon paid $3.5 million for such crap.

-bowerbird

Do you frequently find yourself paging backward and forward through books? If you simply read a book from cover to cover (which I'd imagine is what most people do), the paging is perfectly consistent. Hardly "crap", IMHO, at least.

DaleDe
10-29-2007, 02:18 PM
Yes, Mobi shows you the last page number at the right hand side of its progress bar. This is true on both the iLiad and Pocket PC versions of the Mobi reader.

Not true. At least on my freshly download Pocket PC version 5.3 of MobiPocket. I only the see page number I am currently on. This is display on the right hand of the progress bar. I do not have a clue as to how many pages there really are in the document. I do not know about the iLiad but I do know about the Pocket PC.

Dale

bowerbird
10-29-2007, 09:04 PM
harry said:
> Do you frequently find yourself paging
> backward and forward through books?

all the time, harry, all the time... :+)

however, mobipocket's inconsistency bothers me for
_philosophical_ reasons more than _practical_ ones.

pages in paper-books have consistency. i like that...

besides, i don't want the book's text "reflowing" on me
unless _i_ reflow it. by the way, that's one reason why
i will never use adobe's digital-editions viewer-program;
i simply detest that _it_ decides how many columns i get
with a certain combination of the view-port and text-size,
and even switches them up sometimes when i do a resize.
that's a decision that _i_ want to make, thank you kindly...

-bowerbird

HarryT
10-30-2007, 03:48 AM
Not true. At least on my freshly download Pocket PC version 5.3 of MobiPocket. I only the see page number I am currently on. This is display on the right hand of the progress bar. I do not have a clue as to how many pages there really are in the document. I do not know about the iLiad but I do know about the Pocket PC.

Dale

I stand corrected - I was getting confused between the different versions. The iLiad version shows you the final page number at the right side of the progress bar. As you say, the Pocket PC version shows you the current page number there. Apologies for the mix-up.

GregS
10-30-2007, 09:20 AM
I am looking at the .epub documents at the moment.

Can anyone with experience, save me a lot of searching by telling me if the following is possible:

To have rendered in the margin an element ID number for referencing paragraphs and in plays, lines?

ie.

1.122
Chapter 1 paragraph 122

Book 2 Section 3 Chapter 22 paragraph 45
2.3.22.45

CSS can do it but will reader software be able to?

Being in one of the shades of eink grey would help as well (rather than black).

It would be nice to have a standard reference system.

It is possible to give each edition a World Unique ID which when combined with relative reference would give an absolute and unambiguous reference.

Any comment would be welcome.

jbenny
10-30-2007, 11:11 AM
I am looking at the .epub documents at the moment.

Can anyone with experience, save me a lot of searching by telling me if the following is possible:

To have rendered in the margin an element ID number for referencing paragraphs and in plays, lines?

ie.

1.122
Chapter 1 paragraph 122

Book 2 Section 3 Chapter 22 paragraph 45
2.3.22.45

CSS can do it but will reader software be able to?

Being in one of the shades of eink grey would help as well (rather than black).

It would be nice to have a standard reference system.

It is possible to give each edition a World Unique ID which when combined with relative reference would give an absolute and unambiguous reference.

Any comment would be welcome.

As to the numbering of paragraphs and such, if you will give me an example of the CSS that you use to do this, I will test it. However, it may not be possible the way you are doing it now, if at all. The epub spec doesn't require that everything in CSS 2.0 be supported. Also, some supported XHTML and CSS statements are allowed to be rendered differently by the reader software/hardware. We have already discussed similar issues regarding footnotes in an epub.

I'm not sure what you are getting at with the rest of your question about a World Unique ID. Please elaborate.

jbenny
10-30-2007, 01:31 PM
Just fooling around, I tried a few things to implement paragraph numbers. The CSS 2.0 spec talks about "Generated content" http://www.w3.org/TR/REC-CSS2/generate.html. I tried this, but the examples would not work in Firefox, so I didn't even try it in Digital Editions.

The next thing I tried was floating a span next to a paragraph, like so:
span.pnum { float:left; width:4em; }

This seemed to work. After adding the same amount of left margin to the paragraph to simulate a separate column, things looked good in Firefox.
p { margin-left: 4em; }

I then created an epub, using this method. The epub is attached. Rename if from .zip to .epub. If you want to see how this looks in your browser, just extract the HTML file from the archive.

Since FBReader still does not support CSS, of course things displayed badly. The Lector plugin, using Firefox for rendering, displayed exactly as native Firefox. The only real test at this point was Digital Editions. Sorry to say, DE got it almost right. The numbers and paragraphs are in their own columns, as they should be. However, the paragraphs all start one line below the corresponding number. This isn't what we wanted, but is still useable.

It is possible that my quickly thrown together example is not correct in some way and that this may be the reason that DE isn't doing what we want. I will have to look at this a little closer before laying the blame on DE.

EDIT: I was thinking that using span outside a block element was probably not correct XHTML, so I wrapped each span/paragraph pair in a div for correctness. This didn't make any difference in how things displayed in FF or DE.

Edit: Using a separate div for each column was my first thought (like the way you would do it on a web page). However, since these are separate block elements, how would you keep the numbers in sync with the paragraphs? Using an in-line span was a lot easier.

kovidgoyal
10-30-2007, 03:18 PM
Use tables.

jbenny
10-30-2007, 03:45 PM
Use tables.

The use of tables as a method of layout, although common, is considered poor practice. It makes separation of content and layout more difficult and can be a real mess to maintain if you change the layout. I think this might be even more of an issue with an ebook, because of widely varying screen sizes.

Yes, if we just want to make it work, tables will do the job. If trying to use the recommended standards of today and looking ahead, it's best to do the layout with CSS. I'm trying to break old habits myself and do things the "correct" way.

kovidgoyal
10-30-2007, 03:51 PM
Use tables with % specification of widths. That takes care of screen size independence. If you must use CSS use hanging indents to accomplish this. See the demo file in the html2lrf thread. Though the tables based solution is actually more robust against font size changes.

Having a multi-column layout is what tables are supposed to do.

EDIT: Using tables for layout is not considered poor practice when you're trying to create a multi column layout. Indeed they are the best way to create a multi column layout.

jbenny
10-30-2007, 04:14 PM
I hadn't thought of using an outdent for this purpose, but it does seem to work in FF. I'll have to try it in DE. As the code fragments below illustrate, you need to compensate in the body style for the outdent in the paragraphs (at least on the left side). These values can be adjusted to suit, of course.

body { margin-left: 2.3em; margin-right: 2.3em; }
p { text-indent: -2.3em; }

<p>1.1&nbsp;&nbsp;&nbsp;&nbsp;Now is the time for all good men

As usual, there is more than one way to skin a cat. Thanks for the suggestion.

Edit: I won't argue the use of tables for layout, as like any programming practice, there are proponents for both sides of the issue.

kovidgoyal
10-30-2007, 04:23 PM
The problem with that is you're stuck with using fixed space based indents in your actual paragraphs, which is really inelegant.

I really don't see how this can be solved elegantly with block level positioning, unless there's a way to force a float to have the same height as its parent.

jbenny
10-30-2007, 04:36 PM
Although I don't particularly like doing it with an outdent, I just tried it in DE and it does work ok. Using ems does make this scale correctly with font size.

Did you look at the epub I posted? What I was trying to do there was this:
p { margin-left: 4em; }
span.pnum { float:left; width:4em; }

<div>
<span class="pnum">1.1</span>
<p>Now is the time for all good men...</p>
</div>


This works just fine in FF, but DE inserts a newline after the span. I assume that it is a bug in DE, unless I'm missing something obvious.

kovidgoyal
10-30-2007, 04:41 PM
That is a bug in DE. The problem with that solution is that the second line of the paragraph will be below the number, so it wont really be a margin note. That would work only if CSS would allow a float's height to be specified as 100% of the parent's height. Unfortunately, that doesn't seem to be possible as setting height=100% has no effect.

jbenny
10-30-2007, 04:49 PM
That is a bug in DE. The problem with that solution is that the second line of the paragraph will be below the number, so it wont really be a margin note. That would work only if CSS would allow a float's height to be specified as 100% of the parent's height. Unfortunately, that doesn't seem to be possible as setting height=100% has no effect.

Did you actually try my example? The numbers and the paragraphs display as if they are in two separate colums. This certainly does what the original poster asked for.

BTW, I fixed the bad behaviour of DE by adding "margin-top: 0" to the paragraph style. It also works the same in FF and IE 6. Shouldn't be necessary, but it works.

EDIT: attached is a cropped screenshot of how it looks in DE.

kovidgoyal
10-30-2007, 04:55 PM
Oh right yeah it will work, I overlooked the margin property on <p> :)

jbenny
10-30-2007, 05:34 PM
I'm really glad that GregS asked his question about margin notes and I hope that others will ask similar questions. Myself, I am just curious to see what can actually be done with this new epub format. Asking about things like footnotes, margin notes, etc. will give me and others things to think about and to try that we might not think of ourselves. Keep 'em coming.

GregS
10-30-2007, 06:27 PM
I am so pleased with the response to my question - many thanks to especially to JBENNY for showing the problem solved.

The fact is I don't own a reader (I listed Sony because it is the one I will get when it comes out in Australia - because of its price - I am looking for a device that can be used in schools, though the Iliad has features I would very much like to see in use).

I mentioned World Unique IDs because I see absolute references as very important in study.

WUIDs are very easy to generate (contact Lestec.com.au if there is interest in this). The idea is that edition is given one ID and the work itself another. These can both be established via name-space xmlns. It works like an ISB number but can be generated by anyone anytime on the net. If adopted, it means bibliographies and references are unambiguous and electronically chasable.

My aim, long term, is to make quality textbooks available for school students via a reader (ie their complete course references), referencing is an important aspect of this. Ideally epub would have a choice of css stylesheets one rendering paragraph, illustration, picture and tables references, another normalized reading.

In the long term, while epub seems perfect for literary works, I hope the industry also embraces TEI in the future - especially important for university students.

I am looking forward over the next year of getting plays (with line numbers) available. In rehearsals and study the readers would be great, then the same text could be projected or shown on a monitor as a cheap tele-prompter via a laptop.

The future of this technology is very bright, it solves a lot of problems in my area (Photocopy madness, general shortage of textbooks and the poor quality of so many, plagues teaching - a cheap robust reader is a dream come true as I have had to resort to type condensed pdfs http://members.iinet.net.au/%7Egreg.schofield/Literature/ ).

Again thanks for all, as epub now looks like a perfect intermediate technology for my needs.

jbenny
10-30-2007, 07:34 PM
GregS,

There is no specific mechanism in epub to use your WUID, but there are several optional metadata fields that might be used for such a thing. However, any use of such a data field would have to be taken care of by custom software. Standard epub readers wouldn't know what to do with it.

The ability to select different stylesheets may be problematic, also. I see nothing in the epub spec that addresses this. In fact, I was trying to figure out a way to allow a user to switch stylesheets in an epub myself. You can't do it as you would in Firefox, as there is no defined standard mechanism for this in epub. The obvious method of providing two identical copies of the content, but with different linked stylesheets and then selecting the one you want via a hyperlink would work, but would be rather wasteful. Of course, if you use the Firefox Lector plugin for reading the epub, switching stylesheets is not a problem. I'll have to ponder this more. Any ideas?

For textbooks and such, the epub spec certainly could use some improvement. However, it is a new spec and what has been done so far is a very good effort by all involved. I'm sure that future versions will add new capabilities. I just hope that those creating the specs are keeping an eye out on forums like this one.

I applaud your efforts to provide textbooks and related material in electronic form. If only the major publishers would do more of this. BTW, I looked at one of your online PDFs - it is a good thing that younger people have good eyesight. I wouldn't want to read too many documents formatted that way :)

Look for a PM. I want to ask you about something related to all of this.

jbenny
10-30-2007, 07:49 PM
WUIDs are very easy to generate (contact Lestec.com.au if there is interest in this). The idea is that edition is given one ID and the work itself another. These can both be established via name-space xmlns. It works like an ISB number but can be generated by anyone anytime on the net. If adopted, it means bibliographies and references are unambiguous and electronically chasable.


An additional comment on this: Each epub must have a unique ID (but not each copy). For commercial ebooks, this would normally be the ISBN. For privately created epubs, you can use any method you like, as long as the ID does not conflict with any other epub. One method that I am using is simply a combination of a name and a Julian date. For example: jbenny2454404.4892939813. You could use an organization's name, a domain name, etc. The Julian date includes the date, hours, minutes and seconds. Such a combination is highly unlikely to collide with any other such epub ID.

I don't see any reason why you couldn't use such a technique to give each copy of an epub its own unique ID, if you wanted. Or, it may be easier to manage by using one of the other metadata fields for an individual copy ID, as I mentioned before.

Hadrien
10-30-2007, 10:00 PM
An additional comment on this: Each epub must have a unique ID (but not each copy). For commercial ebooks, this would normally be the ISBN. For privately created epubs, you can use any method you like, as long as the ID does not conflict with any other epub. One method that I am using is simply a combination of a name and a Julian date. For example: jbenny2454404.4892939813. You could use an organization's name, a domain name, etc. The Julian date includes the date, hours, minutes and seconds. Such a combination is highly unlikely to collide with any other such epub ID.

I don't see any reason why you couldn't use such a technique to give each copy of an epub its own unique ID, if you wanted. Or, it may be easier to manage by using one of the other metadata fields for an individual copy ID, as I mentioned before.

We use UUIDs on Feedbooks: http://en.wikipedia.org/wiki/UUID
A few samples provided by IDPF used them too.

jbenny
10-31-2007, 01:37 AM
OK, that makes more sense now. Just different terminology. GregS calls them WUID, the WikiPedia says UUID. I am familiar with the use of a GUID. I didn't know that they were also used in ebooks. This would certainly be another method for those without an ISBN to use.

Hadrien, are you using a UUID for each individual ebook that is generated on your site, or just for each title? If for each individual ebook, why bother?

GregS
10-31-2007, 05:16 AM
OK, that makes more sense now. Just different terminology. GregS calls them WUID, the WikiPedia says UUID. I am familiar with the use of a GUID. I didn't know that they were also used in ebooks. This would certainly be another method for those without an ISBN to use.

Hadrien, are you using a UUID for each individual ebook that is generated on your site, or just for each title? If for each individual ebook, why bother?

JBENNY, it is early days in many ways - but UUIDs are dangerous - they are just big numbers there is no verification that the same number cannot occur in different contexts, just that it is unlikely.

GUID suffer the same problem.

WUIDs, which I might add have been used by Microsoft after an article of mine was published are absolutely unique. Lestec, developed the idea and has it implemented - it requires only a small script to run on servers and relies on two factors - unique IPs followed by a serialised date and number (only one applicant allowed within the time frame).

There is some compression involved and a randomising reversal and it is represented in base32 (the only system where the value remains the same in lower and upper case - there are some refinements base36 +).I would like it standardised, date stamps from a local machine can be added so one "head" can generate endless "tails" - all unique. Please if you want a system of WUIDs contact Lestec - it is simple and guaranteed to work without any chance of duplication - which was my purpose when I wrote the article years ago.

I am not directly associated with Lestec (I cannot program to save my life).

It needs some refinement (reducing the WUID letter size below 22) the server script is trivial however, the conversion routines are not difficult - but it needs to work the same way for everyone to banish any chance of duplication, if you see it as important, please contact Les Moul.

Hadrien
10-31-2007, 06:29 AM
Hadrien, are you using a UUID for each individual ebook that is generated on your site, or just for each title? If for each individual ebook, why bother?

For every title. Once we've generated it once, the epub stays in cache. But if I dump the cache (while editing the book or because we changed the epub output), it'll be generated once again with a new UUID.

Edit: Anyone tried soft-hyphens yet in epub ?

jbenny
10-31-2007, 11:37 AM
WUIDs, which I might add have been used by Microsoft after an article of mine was published are absolutely unique. Lestec, developed the idea and has it implemented - it requires only a small script to run on servers and relies on two factors - unique IPs followed by a serialised date and number (only one applicant allowed within the time frame).


Can you provide a link to the article you wrote? If not, how about a URL to other information on WUIDs? Are WUIDs some type of standard, or are they proprietary to Lestec (whoever they are)? Unless they are an open standard, I don't see any widespread adoption of them happening.

jbenny
10-31-2007, 02:18 PM
Edit: Anyone tried soft-hyphens yet in epub ?

If you want to point me to a sample file, I can see how things look. FBReader already supports hyphenation, so should be ok. I don't know what Lector would do, but it would be whatever Firefox does. As for Digital Editions, I doubt that they support hyphenation at this point, as they don't yet support justified text.

Darn, we need more epub reader programs! :)

GregS
11-02-2007, 04:13 AM
JBENNY the original article seems to have disappeared, I have some preliminary discussion from September 2004 (http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=6674&forum=14&start=20&viewmode=flat&order=0), a submission was sent to W3.org, but no replies.

You are absolutely right it should be a standard, strictly speaking it is not owned by anyone, as I placed the idea in the public domain. Lestec.com.au merely got it working and now has some plans of using it in the future - but as a simple method it would benefit by being made into a standard.

I would avoid MS implementation, besides which they seemed to have done nothing with it.

The implementation is so simple I am amazed no-one has created it elsewhere.

The only thing that could go wrong is non-standard uses that look like WUIDs and end up with the chance of reproducing the same ID.

I will ask Lestec if we can produce a simple free generator and some documentation soon and notify the forum when it is available (they are in the middle of something right at thw moment).

This is stupid, but how would we go about making it a standard - any suggestions?

In terms of publishing I have come up with my own little system two WUIDs:

1) a EID that is an edition ID.

2) a WID a work or Title ID.

A WID needs a public listing, Ie "The War of the Worlds" by HG Wells has a single WID that is used by anyone in any language that produces the work in anyform so long as the text stems directly from the work.

The EID identifies the particular rendition.

Given these two bits of information any work produced any where can be unambiguously referenced even if the particular edition cannot be found, the work could be.

Other information such as the language, the publisher's name and edition numbers etc.,. can be read from headers, along with the actual title and author, original publication date.

ISBN numbers work well enough for printed works, but with the possibilities of epublishing, we need something that is more flexible and guarantees unique identity.

Other WUIDs identifying everything from authors, to publishers may be useful and should over time become standardized INMO.

If people think in general this is a good Idea, I could write a submission to the .epud/IDEF. I am, however, new to the forum and this whole side of things, and need a little longer to perfect (shorten) the system, ideally, a simple server based script would make it available to anyone, while convincing servers to have load the script would ensure more than enough bandwidth for widespread usage.