W3C home > Mailing lists > Public > public-publ-wg@w3.org > December 2018

Re: [AudioTF] Agenda 2018-12-14

From: Ric Wright <rkwright@geofx.com>
Date: Thu, 13 Dec 2018 10:52:45 -0800
To: Dave Cramer <dauwhe@gmail.com>, Matt Garrish <matt.garrish@gmail.com>
CC: W3C Publishing Working Group <public-publ-wg@w3.org>
Message-ID: <D837E9D0.66EACE%rkwright@geofx.com>
Right.  I was going to say that I believe that Readium-1 will throw an
exception if the mimetype is not present (Did you check Readium, Dave?).
And, at least when I was in charge,  RMSDK would throw an exception if the
mimetype was missing. From the fact the Digital Editions fails, I suspect
that code is still present.

Ric

From:  Dave Cramer <dauwhe@gmail.com>
Date:  Thursday, December 13, 2018 at 7:57 AM
To:  Matt Garrish <matt.garrish@gmail.com>
Cc:  W3C Publishing Working Group <public-publ-wg@w3.org>
Subject:  Re: [AudioTF] Agenda 2018-12-14
Resent-From:  <public-publ-wg@w3.org>
Resent-Date:  Thu, 13 Dec 2018 15:57:38 +0000

On Tue, Dec 11, 2018 at 6:40 AM Matt Garrish <matt.garrish@gmail.com> wrote:
> The one ³feature² of OCF that everyone seems to hate is that it requires the
> mimetype file be the first in the ZIP container. That makes packaging an EPUB
> more complicated than just zipping up all the files, since the mimetype
> typically wonıt get inserted first in general zipping scenarios.
>  
> If we remove this restriction from OCF 3.2, then we possibly break the loading
> of publications in reading systems that wonıt process a publication without
> first encountering the mimetype. I have no idea how many that is, or if itıs
> common to fall back to finding a mimetype elsewhere in the zip if itıs not
> first.
>  

Yesterday I made an EPUB without a mimetype, and just zipped it. Changed the
file extension to EPUB. It would not load at all in iBooks, Adobe Digital
Editions, Kobo, or AZARDI. It worked in Google Play Books. Kindle Previewer
did process it, and the resulting Mobi worked in Kindle/Mac.

Dave
Received on Thursday, 13 December 2018 18:54:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:33 UTC