Lector was reviewed on Teleread a year ago (http://www.teleread.org/blog/2007/12/04/an-e-reader-that-accepts-any-xml/).

Unfortunately it has not been updated for the latest version of Firefox, and the link to its homepage redirects to an empty blog. It’s a great shame, because this was a promising project. Does anyone know any more about it?

That would be great! The acceptance of e-books would accelerate if Firefox, Safari, Opera, IE and other browsers could read a dominant e-book format. This approach would leverage the pre-existing wide deployment of web browsers on large and small devices.

The publisher Tor has been releasing e-books in a simple format that is readable by browsers. It consists of a zipped file containing an HTML file together with a folder containing image files. The images are in JPG and GIF formats. However, reading this format raises a difficulty. How can a reader using a browser create a “bookmark” or “stopping point” within a very long HTML file when there is no convenient anchor point?

The “bookmark” would point to a phrase within a text or an offset within an HTML file. Do any browsers implement this function? This should be doable in the current generation of web browsers I think for simple HTML files. It probably would be tricky in complicated HTML files.

I have not used an ePub reader. How do you create a “bookmark” within a text while reading? Does it automatically paginate? Do page numbers change when fonts are resized?

Much thanks to the posters on this thread. I appreciate the expertise that is displayed and I am grateful for your attempts to move e-books forward.

Publishers will discover as they move to ePub that the XHTML they produce will likely be better formed and much more repurposeable.

It’s about time that the e-book industry grows up and does things right – the winners will be the publishers, small and large.

Being strict for strictness sake stifles innovation and development. The e-book format crowd needs to learn lessons from the Web and loosen up.

But the larger point is, if validation is not part of your workflow because it always produces error messages (even if they’re non-critical), then people learn to ignore the validation output altogether, or even disable it. The whole process of validation becomes meaningless, and ultimately systems will produce seriously non-conforming documents.

This is bad for everyone: the consumer, because some ostensibly-portable documents now look bad on some devices; the device-maker, because they get blamed for not handling invalid markup; and the publisher, because readers are turned off by the whole ebook experience.

Software engineers are the first line of defense here, and we should whenever possible build tools that include validation, and push hard for documents that can be accurately encoded.

This is a conflict between declared and actual doctype, as seen in the validation errors for the OPS spec itself:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.idpf.org%2F2007%2Fops%2FOPS_2.0_final_spec.html&charset=%28detect+automatically%29&doctype=XHTML+1.1&group=0

The publicly-available TEI/XHTML stylesheet will automatically convert xml:id (from TEI) to HTML id attributes. It will also helpfully create anchor links to those paragraphs.

If you ask it to generate HTML 4.0, you get:

<p id=”id123″><span name=”id123″/>

which as Jon points out is not valid XHTML 1.1 because ‘name’ has been removed from the spec. (In fact it wasn’t valid anyway because ‘name’ was never allowed on a span.)

…but if you ask it to generate XHTML you get:

<p id=”id123″><span id=”id123″/>

…which is also invalid XHTML 1.1 because of the duplicate IDs.

I couldn’t find the right combination of arguments to the base TEI stylesheets to get the behavior I wanted so I had to modify them directly. I’ll be passing a bug report on to the TEI folks.

In fact, here are the actual differences between XHTML 1.0 Strict and XHTML 1.1:

1. ‘lang’ attribute becomes ‘xml:lang’ for XHTML 1.1.

2. On the <a> and <map> elements, the ‘name’ attribute is not supported in XHTML 1.1. Use ‘id’ instead.

For those with really legacy HTML, “HTML Tidy” may be used to get you much of the way to XHTML 1.0 Strict.

Btw, here’s an interesting article describing the benefits of XHTML 1.0 Strict over “tag soup” HTML. I probably don’t need to comment why IDPF, from the beginning in 1999, specified XHTML.

“The link element allows for the specification of various relationships with other documents. Reading Systems must recognize external style sheet references specified via the href attribute and the associated rel attribute (for the values rel=”stylesheet” and rel=”alternate stylesheet”.)”

This means single file XHTML conversions can still use CSS, either in external files (via URL) or inline (via style elements).

As for the flavor of XHTML needed for epub, XHTML 1.1 is bleeding-edge enough that not only will you not find many web sites out there using it, you’ll have trouble conforming to it. It’s extremely intolerant of much current Web content. The BookGlutton tool will convert HTML to XHTML Strict, which for all practical purposes (such as being viewable in Digital Editions) is enough.

Soon we’re releasing an upgrade to the converter which will support multi-file zip archives with JPG, SWF, GIF, XML, CSS and PNG files.

Aaron

I’m not denying that the concepts involved in ePub seem pretty easy to grasp, and that it probably wouldn’t be terribly difficult for those with the right skills to write a program to do the conversion.

My point, however, is that I shouldn’t have to. Unlike other standards (such as the JPEG and PNG image formats you mention) there does not seem to be any “reference implementation” for ePub. If it’s not hard to write code to handle, then it would be advantageous if someone were to step up and create an open source ePub-handling library which developers can simply plug in to their application. Sure, it will have some problems to begin with, but every project does, and by making it open source, anyone with the right skills could join in and help instead of it becoming the sort of proprietary spaghetti we all dread.

As far as I myself am concerned, at the moment my ebook library consists mainly of HTML documents (usually exploded from Microsoft Reader files, although I also have some Baen books which are natively HTML) which are of varying code standards. Some have CSS and images and some do not. That means that as well as an ePub packaging utility I’d also need something which can take any old HTML file and process it into whichever XHTML version ePub is expecting, rather than simply saying “hey, this isn’t XHTML, rejected!”. In addition, it also needs to be able to follow links, as for example Baen books are often split into chapter files, whereas MS Reader books are a mixture depending on the application that was used to author them.

Most browsers have never made these visible, but it seems you can do it yourself with JavaScript.

http://www.alistapart.com/articles/dynanav