View Single Post
Old 05-19-2015, 01:19 PM   #1130
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,733
Karma: 5444398
Join Date: Nov 2009
Device: many
Further response:

[QUOTE][*]My source OPF has <meta property="ibooks:binding">false</meta> in its metadata, which disables the fake spine shadow in iBooks and is innocuous in Kindle. If present, though, it is also required that the prefix attribute in the package declares the prefix ibooks: …. Kindle does not produce that fake shadow, so all the more reason to have KindleUnpack add that metadata to EPUB 3 FXL. The reasons for doing so are admittedly subjective, and the syntax is admittedly iBooks-only, i.e. non-standard, but it still does not make the EPUB 3 invalid and is not incompatible with Kindle.
[QUOTE]

Again, sorry but nothing ibooks specific that doesn't appear in the AZW3 raw source or metadata will be created during the unpack phase.

Quote:
[*]I would add the explicit attribute properties="renditionage-spread-center" to the cover in the spine. It's not like not having it is incorrect, though. Besides, the value of adding it is subjective and, at any rate, even though part of the EPUB 3 spec, no major ereader app cares about the property yet.
Again, only if there is either info in the azw3 header, or RESC section, or metadata will anything be added to the unpacked epub structure.

Quote:
[*]When the source has no HTML document identified as cover in the OPF guide or nav.xhtml's landmarks, KindleUnpack will create one with the name cover_page.xhtml and give it the attribute linear="no" in the spine.
linear="no" is the default so this is not needed but linear="yes" may not be correct as many ebooks are not meant to open at the cover or force its inclusion.

That said, KindleUnpack should be adding the "svg" as a manifest property to correctly identify the use of svg in the cover image for an epub3. If it doesn't do that properly, it is a bug and something I will look into fixing.

All in all I see 8 potential issues here:

1) if viewports meta exists in azw3, force conversion as epub3

2) add viewport metadata to each xhtml when viewport is found in azw3 metadata (if and only if kindlegen removes it when present in the input source)

3) properly setting the language metadata as specified in the azw3 header

4) adding metadata charset for xhtml docs (including nav) that matches the charset as specified in the azw3 header for epub3

5) adding the proper svg manifest property under epub3 for created cover images with svg

6) check / verify the proper prefixes for use with epub3 (ie. for epub

7) make sure opf: prefixes are removed from all dc metadata tags under epub3

8) make sure ncx meets valid daisy spec if present.

KevinH
KevinH is offline   Reply With Quote