[elmimmo]

Originally Posted by KevinH

Please post links to a completely valid fixed layout KF8 made via kindlegen (no drm) and the valid fixed layout epub3 that was used as input to kindlegen and I will work out how to properly unpack it and make the needed changes to KindleUnpack.

KevinH, thanks for the interest. I got pumped so here's the KF8 you request, with the source embedded so KindleUnpack will extract it along with KF8's resources, and a buck load of requests (including the one already mentioned) when outputting FXL books to EPUB 3 (which, again, I feel should be the default).

Taking the source inside EPUB 3 FXL with linear cover.mobi as source:

• XHTML documents in my source have the size of their canvas declared in their head block, as required by the EPUB 3 spec, with:
  
  

  <meta name="viewport" content="width=794, height=1122"/>

  with same values as those written by KindleUnpack in the output OPF's metadata:
  
  

  <meta name="original-resolution" content="794x1122"/>

  The latter is what Kindle requires but does nothing in EPUB 3 ereaders. The former is EPUB 3's way but does nothing in Kindle. Both are needed for the EPUB 3 to render properly in EPUB 3 ereaders and be safely convertible (back) to mobi.
  
  I assume that the internal XHTML of most mobi files will lack EPUB 3's viewport's size declaration since Kindle makes no use of it (so no reason for the original author to have added it). KindleUnpack should add it if missing when outputting EPUB 3 FXL so that ereaders display them properly.
  
• KindleUnpack is being unnecessarily redundant by adding to EPUB 3 FXL's metadata both <meta name="fixed-layout" content="true" /> and <meta property="rendition:layout">pre-paginated</meta>. Both accomplish the same thing in Kindle, but only the latter does so too for EPUB 3 ereaders. KindleUnpack should therefore only add the latter.
  
  The same thing goes for <meta name="orientation-lock" content="portrait" /> and <meta property="rendition:orientation">portrait</meta>, only the latter being EPUB 3 proper syntax.
  
• My source OPF has its ISBN specified in EPUB 3 syntax:
  
  

  <dc:identifier id="uid">urn:isbn:9781234567890</dc:identifier>
  <meta refines="#uid" property="identifier-type" scheme="onix:codelist5">15</meta>

  but KindleUnpack's output EPUB 3 has it like:
  
  

  <dc:identifier opf:scheme="ISBN">9781234567890</dc:identifier>

  which is not valid EPUB 3. No opf: prefix is, so the same goes for
  
  

  <dc:date opf:event="publication">2011</dc:date>

  KindleUnpack should just drop that attribute when outputting EPUB 3. Note that adding it, is, however, valid and actually the right way to do it when outputting EPUB 2.
  
• My source NCX (document which is not part of the EPUB 3 spec, but some consider good practice to add for backwards compatibility) is simpler than KindleUnpack's output. The extra stuff that KindleUnpack adds is cruft (irrespective of whether it is exporting to EPUB 2 or 3). Some parts of it:
  
  

  <meta content="1" name="dtb:depth"/>
  <meta content="mobiunpack.py" name="dtb:generator"/>
  <meta content="0" name="dtb:totalPageCount"/>
  <meta content="0" name="dtb:maxPageNumber"/>

  are innocuous but still pointless since no EPUB ereader (neither Kindle) needs nor supports them in any way; some other parts, particularly, the DOCTYPE and each playOrder attribute, are, actually, harmful IMHO as they complicate post-editing by hand.
  
  The EPUB 2 spec does not require any of that. Neither does EPUB 3's since NCX is not even a part of it. More details if you are interested, with further elaboration in the comments after the code snippets in that link.
  
  Besides, if KindleUnpack is adding the NCX to EPUB 3 FXL for backwards compatibility purposes, then it should also generate the file com.apple.ibooks.display-options.xml that my source contains, as that file was Apple's method of tagging an EPUB 2 as a FXL book before EPUB officially embraced FXL in EPUB 3.0.1 (which uses another method to do so, but including that legacy file does not make the EPUB 3 file non-valid).
  
  Still, I, for one, do not see value in generating EPUB 2 FXL backwards compatibility cruft in EPUB 3 FXL(the NCX, the spine's toc attribute, the OPF's guide and the file com.apple.ibooks.display-options.xml). FXL was originally a non-standard Apple extension to EPUB 2 which Apple itself now considers obsolete in favor of proper EPUB 3 FXL, and all major platforms that once supported Apple's EPUB 2 FXL now support EPUB 3 FXL.
  
  The source inside EPUB 3 FXL without EPUB 2 markup.mobi has all that taken out so that you can compare and see what the redundant data exactly is.
  
• The language of the source ebook is Spanish, as specified in the OPF's metadata:
  
  

  <dc:language>es</dc:language>

  yet KindleUnpack's output's is:
  
  

  <dc:language>en</dc:language>

  The wrong language is carried on to some other output XHTML documents, like the EPUB 3 Navigation Document, which KindleUnpack outputs with the name nav.xhtml and whose html element has lang and xml:lang attributes with the same wrong value, or the HTML cover cover_page.xhtml that KindleUnpack creates if the source did not have one. This one has only the xml:lang attribute, again with the wrong value.
  
• In nav.xhtml, the namespace URI for the epub namespace is wrong. KindleUnpack's current output is:
  
  

  <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2011/epub" …>

  while it should be:
  
  

  <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" …>

• The source nav.xhtml has a meta tag declaring the text encoding:
  
  

  <meta charset="UTF-8"/>

  but KindleUnpack's output nav.xhtml does not. That might produce incorrect rendering of non-ASCII characters when accessing this book's TOC. The same goes for cover_page.xhtml. While the latter contains no text, it's still good practice to declare the encoding if anything to account for potential post-editing.
  
• In spite of what the Kindle Publishing Guidelines (4.1, 5.1, 5.6) document claim, this does nothing whatsoever ever:
  
  

  <meta name="RegionMagnification" content="true" />

  AFAIK never has, and is just bloat. Kindlegen and Kindle Previewer will instead parse all HTML documents upon conversion in search for explicit region magnification markup, and will label the ebook accordingly irrespective of what that metadata value says.
  
  The HTML doc part0000.xhtml in my source contains region magnification markup, but the OPF lacks the metadata above altogether. Kindlegen and Kindle Previewer still flags the book as having Region Magnification correctly, or not, which you can verify by:
  
  1. Converting with Kindlegen or Kindle Previewer as is.
  2. Adding that metadata and set its value to false (even though the book does have markup for it) and converting.
  3. Setting its value to true and delete the region magnification markup in part0000.xhtml, and converting.
  
  You will see in Kindlegen's log that in all cases the presence and value of that metadata does nothing.
  
• I am not aware that the OPF metadata <meta name="output encoding" content="utf-8" /> in KindleUnpack's output accomplishes anything whatsoever, resulting in mere bloat, but it might be that I am not well informed.
  
• If the source has no spine item with the attributes properties="page-spread-right" or properties="page-spread-left", it might be considered appropriate that KindleUnpack adds <meta property="rendition:spread">none</meta> to the output OPF metadata of an EPUB 3 FXL, so that EPUB 3 ereaders like iBooks do not group pages in 2-page spreads just like Kindle doesn't.
  
• 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.
  
• I would add the explicit attribute properties="rendition:page-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.

Taking the source inside EPUB 3 FXL with no HTML cover.mobi as source:

• 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.
  
  IMHO linear=no in the cover is a misuse of the attribute's purpose, and I am against it despite this practice being admittedly widespread. An ereader honoring it would make the cover, as important as it is to a book, unreachable, effectively making it bloat. That attribute's purpose is not for making content unreachable but non-linear (you have to have some way to access it). It might be because of this widespread bad practice that iBooks, Google Play Books and Kobo ignore the linear=no attribute in FXL books (ADE 4 does not, though). So while KindleUnpack adding it actually has little to no effect, I am more in favor of doing things right instead of having ereaders trying to outsmart improper markup.

Edit (2015-05-19T06:00:30Z): The source of EPUB 3 FXL with a linear HTML cover.mobi had some weird forgotten test CSS in cover_page.xhtml. It is irrelevant, but I still corrected and updated the attachment just in case.