Re: The non-polyglot elephant in the room

On 22/01/13 10:18, Henri Sivonen wrote:

> I mean: There is the fixed well-known path META-INF/container.xml
> anyway. The file there points to the OPF to allow the OPF to live at
> an arbitrary path. What's the point? Why did the designers of EPUB
> just require the OPF to live at a well-known path under META-INF and
> do away with the container.xml layer of indirection?

There are tons of things like that in the EPUB spec that don't make
sense if you see them from our desktop browser world. Like having the
mimetype file first in the package or using no extra field for the
ZIP. Once you switch perspective and imagine you're on a very low
end device, see that broadband is not everywhere, or understand EPUB
must be a common denominator for pre-existing zipped packages of
xml-based ebooks, you start seeing the light.

> Except you still need to care about NCX if you want the table of
> contents to work in all Reader Mobile SDK-based e-readers out there.

Compatibility in the EPUB world is an illusion. See
http://is.gd/5EKJ4N (I'm sure you already read it).

>> I am probably the only one in the world who implemented EPUB 3 metadata
>> authoring _fully_ . EPUB 3 metadata are incredibly powerful, probably
>> too powerful but the thing I know is that their power is currently
>> impossible to express in html.
>
> Who is consuming that metadata fully if nothing but BlueGriffon
> supports authoring it fully? If metadata falls in the forest and there
> is no one to hear it, does it make a sound?

I said "authoring". I never said readers don't implement EPUB3 metadata
entirely, in particular asian ebook readers.

> I mean a piece of software that makes sure the mimetype is the first
> file in the zip and is uncompressed, takes care of font mangling,
> generates NCX from some more human-friendly representation, etc.

I know lots of people who do that by hand. They're not individual
authors, they do that as part of their daily job for big companies.
Ask Mohamed Zergaoui (Innovimax) too.

</Daniel>

Received on Tuesday, 22 January 2013 09:32:48 UTC