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

Re: [AudioTF] Agenda 2018-12-14

From: Brady Duga <duga@google.com>
Date: Thu, 13 Dec 2018 15:00:26 -0800
Message-ID: <CAH_p_eUm0HRy9EYdSmS2r=kuJU8pwA9AZ+xahgSVb1sMLQokOQ@mail.gmail.com>
To: Leonard Rosenthol <lrosenth@adobe.com>
Cc: Ric Wright <rkwright@geofx.com>, Dave Cramer <dauwhe@gmail.com>, Matt Garrish <matt.garrish@gmail.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
I am not sure what you mean. From the OCF spec:

Magic number(s):
0: PK 0x03 0x04, 30: mimetype, 38: application/epub+zip

That's a pretty explicit statement that this is a magic number. We could
change the way the signature works (just a known name in the zip file?),
but is that really that much better? Seems like a minor tweak that might be
a little better for content creators (maybe?), though now requires
understanding of ZIP files in whoever is assigning the mimetype.

On Thu, Dec 13, 2018 at 2:49 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> As Brady said, you need the mimetype file for systems that handle multiple
> types of ZIPped content.   However it need not be first **unless** (as
> noted) that system is also using it in a “magic number” scenario.  But such
> a scenario has **never** been suggested or recommended…
>
>
>
> Leonard
>
>
>
> *From: *Ric Wright <rkwright@geofx.com>
> *Date: *Thursday, December 13, 2018 at 1:55 PM
> *To: *Dave Cramer <dauwhe@gmail.com>, 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: *Thursday, December 13, 2018 at 1:54 PM
>
>
>
> 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 23:01:03 UTC

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