.epub format

[Robert Marquard]

Originally Posted by Hadrien

I'm going to work on epub this summer: this is the future standard for xml e-books.

Are you sure that soft hyphens are supported though ? Hyphenated e-books based on an xml format would be MUCH better than LRF for example.

Soft hyphens are supported in .epub by telling that it is XHTML for the text. What the reader software can do is another question. I bet Digital Editions handles it.

[Hadrien]

Originally Posted by kovidgoyal

Yeah but BBeB has no ability to define semantic information. It's a total waste of the power of XML. Not that HTML is much better.

I agreee 100%, and that's the main reason why on Feedbooks our source file is not HTML, but something with semantic information.
A book is not pure presentation, and we need both semantic and metadata information too.

[nickbogaty]

Hello,

Apologies for the .epub files on idpf.org being temporarily unavailable. We fixed our MIME Type issues on the server and they are now available.

A brief rundown on the sample .epub files on the IDPF website:

1. http://www.idpf.org/2007/ops/samples/hauy.epub

This is a sample OPS 2.0 publication marked up in DTBook by the DAISY Consortium. DTBook and XHTML are the two allowable XML vocabularies for OPS 2.0 publications. DTBook provides publishers compliance under NIMAS for people with print disabilities.

2. http://www.idpf.org/2007/ops/samples...reTheMast.epub

This is an OPS 2.0 publication produced directly from Adobe InDesign CS3. FYI, there is an CS3 update as it relates to .epub creation at

http://www.adobe.com/support/downloa...jsp?ftpID=3622

It adds TOC support, font embedding and some other minor fixes.

3. http://www.idpf.org/2007/ops/samples/myantonia.epub

This is an "hand-made" OPS 2.0 publication submitted by Jon Noring of DigitalPulp Publishing.

4. http://www.idpf.org/2007/ops/samples/WhiteFang.epub

This is a jointly compatible OPS 2.0 and OEB 1.2 publication. The "jointly compatiable" factor being valid XHTML.

A brief status update on implementation and the specs:

1. .epub is an official spec, but OPS 2.0 (the next generation of OEB) is not officially approved. We need to go through an IP review period and final vote before it is. I'd expect August. We will post the newest (and final) version of the spec shortly. We received significant input on previous drafts from places like mobileread.

2. Adobe Digital Editions, eBook technologies & OSoft have already implemented .epub and OPS. Mobipocket will in the next couple of months. SONY will with Digital Editions support. VitalSource Technologies accepts .epub from publishers.

I hope this helps. Over the next several months, I am sure we'll see additional product releases that implement the specs from a variety of vendors.

Thanks,
Nick

--
Nick Bogaty
Executive Director
International Digital Publishing Forum (IDPF)

[kovidgoyal]

With CSS you can make HTML semantic, though it is a hack.

[Hadrien]

Originally Posted by kovidgoyal

With CSS you can make HTML semantic, though it is a hack.

Well that's pretty much what I'm planning for epub since there's CSS support. I need to take a better look at the specifications though, I hope they support real footnotes at least...

[NatCh]

Welcome to MobileRead, nickbogaty!

We're very glad to hear from someone in the IDPF.

Especially when he comes with some concrete details to offer!

You don't happen to know any sort of guesstimate on what sort of time-fram Sony, et. al., might be looking at for Digital Editions on mobile devices, do you? We'd be extremely interested in any rumors you could offer here.

Thanks! And welcome again!

[nickbogaty]

Originally Posted by NatCh

Welcome to MobileRead, nickbogaty!

You don't happen to know any sort of guesstimate on what sort of time-fram Sony, et. al., might be looking at for Digital Editions on mobile devices, do you? We'd be extremely interested in any rumors you could offer here.

Thanks for the welcome.

I don't have any knowledge regarding timeframe for Digital Editions on SONY. Since this was already announced in the DE press release, I'd imagine the timeframe to be relatively short. But, again, I have no specific knowledge on this one.

[NatCh]

Ah, well, "hope springs eternal" and all that.

[nickbogaty]

FYI,

I thought this was an unusually informed piece covering .epub and software and publisher development plans around it.

http://newsbreaks.infotoday.com/nbRe...rticleId=36819

-Nick

[MishaS]

Originally Posted by nickbogaty

1. http://www.idpf.org/2007/ops/samples/hauy.epub

This is a sample OPS 2.0 publication marked up in DTBook by the DAISY Consortium. DTBook and XHTML are the two allowable XML vocabularies for OPS 2.0 publications. DTBook provides publishers compliance under NIMAS for people with print disabilities.

Interesting Specs are explicitely saying that mimetype file should not be compressed, however the sample has it compressed. Is it a valid file? Or that requirement is just a guideline?

[nickbogaty]

Originally Posted by MishaS

Interesting Specs are explicitely saying that mimetype file should not be compressed, however the sample has it compressed. Is it a valid file? Or that requirement is just a guideline?

Misha,

I apologize. You are correct and this is an error in the file. I will ask DAISY to redo the file and I will upload a corrected one.

In the .epub spec is the following which you correctly reference:

--
The first file in the ZIP Container MUST be a file by the ASCII name of ‘mimetype’ which holds the MIME type for the ZIP Container (i.e., “application/epub+zip” as an ASCII string; no padding, white-space or case change). The file MUST be neither compressed nor encrypted and there MUST NOT be an extra field in its ZIP header. If this is done, then the ZIP Container offers convenient “magic number” support as described in RFC 2048 and the following will hold true:

The bytes “PK” will be at the beginning of the file
The bytes “mimetype” will be at position 30
The actual MIME type (i.e., the ASCII string “application/epub+zip”) will begin at position 38
--

We require that the file be *not* compressed so it can be found and externally probed and found at a fixed file offset location.

A step-by-step example of how this is done can be found at:

http://www.ebooktechnologies.com/OCF...singWinZip.htm

Thank you for the finding the error,
Nick

[nickbogaty]

Originally Posted by MishaS

Interesting Specs are explicitely saying that mimetype file should not be compressed, however the sample has it compressed. Is it a valid file? Or that requirement is just a guideline?

I apologize for the delay, but a revised sample file which fixes this error can now be found at:

http://www.idpf.org/2007/ops/samples/hauy.epub

Thanks,
Nick

[jmurphy]

Originally Posted by MishaS

OK, for what it's worth. Here's a simple python script that takes a directory with an OEB book (converted from .lit, hint-hint ) and supposedly creates a .epub file. (BTW, .py does not seem a valid extension for this forum... )

If images are in a subdirectory, the script fails.
Easy enough to just drag the subdirectory into the zip after the fact, though.

[MishaS]

Originally Posted by jmurphy

If images are in a subdirectory, the script fails.
Easy enough to just drag the subdirectory into the zip after the fact, though.

Could you please provide a bit more information? What is the directory layout?

[jmurphy]

Running on Windows:
folder "Test"
file "Test\Content.opf"
file "Test\Chap01.html"
file "Test\Chap02.html"
file "Test\toc.ncx"
folder "Test\Images"
file "Test\Images\imag01.jpg"
file "Test\Images\imag02.jpg"


oeb2epub.py test
Traceback (most recent call last):
File "G:\!DATA\!downloads\epub\oeb2epub.py", line 90, in <module>
epub.addFile(realfile, 'OEBPS', itsname)
File "G:\!DATA\!downloads\epub\oeb2epub.py", line 30, in addFile
self.epub.write(fullname, os.path.join(subdir, relativeName))
File "C:\Python25\lib\zipfile.py", line 563, in write
fp = open(filename, "rb")
IOError: [Errno 13] Permission denied: 'test\\images'