W3C home > Mailing lists > Public > public-digipub-ig@w3.org > August 2015

RE: Little help from my (publisher) friends - W3C Technical documents and EPUB?

From: George Kerscher <kerscher@montana.com>
Date: Thu, 13 Aug 2015 04:20:13 -0600
To: "'W3C Digital Publishing IG'" <public-digipub-ig@w3.org>
Message-ID: <003301d0d5b1$a516ffe0$ef44ffa0$@montana.com>
Hello Ivan,

Perfect example why the work at epubtest.org is so important. Also note accessibility testing of the various reading systems. 
Go to: http://www.epubtest.org/

The support grid shows a table of the various reading systems.


-----Original Message-----
From: Ivan Herman [mailto:ivan@w3.org] 
Sent: Thursday, August 13, 2015 3:38 AM
To: W3C Digital Publishing IG
Subject: Little help from my (publisher) friends - W3C Technical documents and EPUB?

Hi guys,

some of you may know that, a while ago, I have made a python script to turn W3C TR documents into EPUB3 files. I looked at my script again the last few days, with the ultimate goal of incorporating it into the respec[1] workflow. The idea is that the user, who can already generate an HTML file ready for publication through the respec user interface, should also have the possibility to produce an EPUB3 file of the same document. If that works, people may more routinely provide the EPUB3 version as a (non-normative) alternative format for a TR document. Some sort of a first step towards EPUB+WEB:-)

Because respec is in JavaScript, the way to do this is to have a Web Service to make the conversion. That is still in a T.B.D. But the underlying library, which can also be used through a command line tool, is in a reasonable shape now[2], although there are still improvements to do; I hope to set up a Web Service wrapper soon.

However... it may come as a shock to some of you:-) but the various EPUB readers are not mutually interoperable, i.e, they do not provide the same output as what one sees on the Web (and they are mutually different). Plus there is the minor issue of the effects of pagination:-). One the other hand, I am sure there are some in the group who have already faced this issue and may have some advise on how to massage the underlying CSS files to at least make the situation better. That is where I would hope somebody could find some time helping me...

I have generated two examples. [3] is an EPUB 3 version of the tabular metadata[4] document, and [5] is the EPUB 3 version of the csv to json conversion document[6]. Both documents have lots of code and example blocks, [5,6] also have tables. The particularity of [3,4] is that it has two SVG images (via an <img> tag) but also explicit references to SVG and its PNG equivalents. One of the images also have a longdesc, pointing at an HTML file. The particularity of [5,6] is that it also uses a small javascript to hide/reveal long tables (look for a series of buttons towards the end of the file).

There are a bunch of CSS files coming either from the W3C core, or generated in the file via a <style> tag. I suggest these should not be changed. There is a separate book.css file that, currently, is almost empty except for a reference to an image that is displayed, as background, on the opening page (to denote the status of the document). The book.css is generated by my script, so all changes should go there...

The differences in rendering are interesting. iBook almost works well both on my Mac and on my iPad, except for that status background image: on [4] and [6] there is a margin for the body text that includes the image, whereas on the iBook the margin is not kept (?) and the text is overlayed. Readium in Chrome is dramatic (I use the readium installed via google play, I do not know whether there is a way to get a newer release): all code examples go wrong, they are overlayed with the text making the whole thing unusable. BlueFire on iPad renders nicely, but the links to the SVG/PNG images do not work (and the placement of the caption is funny); it also does not wrap the code (which iBook does) (the script does not work either, but I did not expect it; BlueFire is, afaik, a EPUB2 reader). The Mozilla EPUBREader plugin does not do any pagination; I presume it just goes down to the Mozilla renderer (ie, it actually looks fine all along). The Adobe Digital Edition (on Mac) does not do the script, and has the same problem is BlueFire for the SVG images. Kobo had the same problem with the background image as iBook and it could not use the linked SVG and PNG, and the code does not wrap (otherwise it looked nice); and I could not load it into Google Play (the program crashed when I tried to upload it:-(

So... anybody has some extra time to try to reduce the differences? Any of these effects sound familiar? With all these differences, I am a little be skeptical whether it makes sense to release this tool, at least not until the EPUB3 reader situation stabilizes a bit… We should have it rendering properly with iBook, and I probably should test it with the latest version of Readium (I am not sure how to use/install that) and the upcoming BlueFire renderer that is supposed to be EPUB3. Others?



[1] http://www.w3.org/respec/
[2] https://github.com/iherman/respec2epub
[3] https://db.tt/pqEwnIYD
[4] http://www.w3.org/TR/2015/CR-tabular-metadata-20150716/
[5] https://db.tt/NOJ99t2C
[6] http://www.w3.org/TR/2015/CR-csv2json-20150716/
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704
Received on Thursday, 13 August 2015 10:20:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:08 UTC