Re: EPUB Test Suite

Ric-

The part of this that DAISY has taken over is just the accessibility testing, which they are moving forward with quickly.

We discussed this with the Publishing@W3C SC today and it is still unclear beyond the testing that is necessary for HTML/API checks within the W3C world for spec writing what other kinds of tests are necessary to support the advancement of the publishing community.

What kinds of tests are you looking for here? What would help you? It would be greatly appreciated if you could help us with more context so that we can work on figuring out where and how this should be developed.

Thanks much!

Liisa

From: Bill Kasdorf <kasdorf.bill@gmail.com>
Date: Friday, July 27, 2018 at 11:00 AM
To: Ric Wright <rkwright@geofx.com>
Cc: W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: EPUB Test Suite
Resent-From: <public-publ-wg@w3.org>
Resent-Date: Friday, July 27, 2018 at 11:08 AM

Correct, this isn’t part of epubcheck, it’s part of epubtest.org<http://epubtest.org>. Daisy is in control of the test suite at this point and they’re currently working on a bit of re-engineering to better optimize the accessibility testing. We currently have no clear path forward for the mainstream testing. The decision was made to keep it alive but with prominent notices that it is out of date. Not sure if the latter got implemented yet.
Sent from my iPhone

On Jul 26, 2018, at 5:40 PM, Ric Wright <rkwright@geofx.com<mailto:rkwright@geofx.com>> wrote:
Who owns this now?  I am in the midst of a number of tests of our Readium-based RS.  For part of it I use the TS, but it is not a very thorough set of tests (excellent as far as it goes, but it has a lot of shortfalls so I get a little frustrated).  Who is working on improving it?  I don’t believe this is part of the “EPUBCheck” reset.

Thanks
Ric


From: Ric Wright <rkwright@geofx.com<mailto:rkwright@geofx.com>>
Date: Thursday, July 26, 2018 at 11:59 AM
To: W3C Publishing Working Group <public-publ-wg@w3.org<mailto:public-publ-wg@w3.org>>
Subject: Cover-image redux
Resent-From: <public-publ-wg@w3.org<mailto:public-publ-wg@w3.org>>
Resent-Date: Thu, 26 Jul 2018 19:01:09 +0000

<Garth, brace yourself, more of Ric’s nutty graphics ahead>

After listening to the discussion on Monday about covers and cover-images, I started thinking about what kinds of graphics could be on a cover page. Naturally, given my background, I thought of SVG and OpenGL. There is also CSS3, with all its bells and whistles too.  So to see what it might be like, I created an EPUB with an OpenGL (WebGL) animation on the title page.  You can see the result here (Tiny-EPUB GLCover<https://readium.firebaseapp.com/?>).

One cannot specify a “cover-image” property which references a XHTML page (EPUBCheck throws an error). So I just leave that property out.  In Readium, our UA doesn’t see a  cover page, so it just fetches the metadata and creates a plain title page, just like normal.  But when the book itself is opened, the real, WebGL-enabled title page is shown and voila!  an WebGL animation is displayed.  In iBooks, the result is the same except that iBooks has a bit of a problem laying out the title page so it’s not quite right, probably because iBooks doesn’t handle mixed (reflow/fixed) pages very well.

One could also create SVG animations or CSS3 animations as well.  In theory, the UA could even figure out that the library page with thumbnails should be animated, but the overhead would be huge and the idea of a significant number of animations occurring in the library page at one time is kind of dizzying. Probably not a good idea.

I am not suggesting that this is a great idea or plan to do it with all my books, just demonstrating that within the scope of the EPUB spec as it stands you can do some “interesting” demos.

Ric