Let me first add that I just mentioned what I perceive as issues for obtaining a valid EPUB 3 out of a mobi. I understand not everything asked might align with the purpose of KindleUnpack, and I am fine with you tackling just some or none of the requests based on that. I appreciate that you consider them.
Quote:
Originally Posted by KevinH
I wonder why kindlegen removes the [viewport] meta values in the xhtml page head tag if they do no damage.
|
It doesn't. If KindleUnpack's output does not have them the source did not either. KindleUnpack's output of my mobi has them, as my source has them too. I just mentioned that they are necessary for the output EPUB 3 FXL to display correctly in ereaders, so asked that KindleUnpack added them when the source lacked them. By your answer, I understand that going that extra mile is not the purpose of KindleUnpack.
Quote:
Originally Posted by KevinH
Actually according to the epub3 spec, old style metadata is allowed and should be ignored by an epub3 device. So these [redundant metadata] will stay as they do not hurt things and help to document exactly what was present in the source.
|
But the Kindle-only metadata was actually not present in my source:
Code:
<meta name="fixed-layout" content="true" />
<meta name="orientation-lock" content="portrait" />
KindleUnpack is generating the above, even though the corresponding EPUB 3 metadata that my source did have:
Code:
<meta property="rendition:layout">pre-paginated</meta>
<meta property="rendition:orientation">portrait</meta>
produces identical effect in both Kindlegen and EPUB 3 ereaders.
Quote:
Originally Posted by KevinH
epubcheck 4 has fixed this bug in epubcheck 3
|
What bug was that?
Quote:
Originally Posted by KevinH
I will look at the DAISY spec to see about the extra meta data. If needed for the spec it stays, otherwaise I will remove it.
|
Please have a look first at the EPUB 2 spec, which states that while "this specification uses the NCX defined in the DAISY/NISO Standard […] some optional elements and metadata items are not needed to implement the NCX for this specification", and follows in to note that it is valid in EPUB 2 to not include the NCX DOCTYPE, in which case the playOrder attribute, mandatory in the NCX spec, becomes optional in EPUB 2. The sample NCX in the very EPUB 2 OPF spec follows this practice, and lacks the superfluous metadata (that my source lacks but KindleUnpack is outputting) too.
The point of not outputting the playOrder attribute (which my source lacks too), which in turn requires not outputting the DOCTYPE as per the EPUB 2 spec, is to make post-editing of that file easier by avoiding its nasty requirement of it having to have consecutive values.
Quote:
Originally Posted by KevinH
Again sorry but, if [<meta name="RegionMagnification" content="true" />] exists in the metadata in the azw3, it will be output. That is the whole point of KindleUnpack. You may consider it "cruft", I consider it documenting the metadata that is provided by the azw3 to the extent it can.
|
Such metadata does not exist in my source. Kindlegen is adding it upon detecting that my source contains region magnification HTML markup. I'm fine if you still want to output that metadata, but please do consider that it might give the false impression to those using KindleUnpack to learn how to author KF8 files that Kindlegen uses that metadata in order to produce such KF8 and/or that it existed in the source.
Again thanks for taking the time to consider my ideas.