Manifest mess - tools for resorting?

[Fitz Frobozz]

Well, not a mess per se, but it's confusing for me to read and it would be nice to have an option for resorting things so that the order in which they are listed actually matches the order in the book (more closely, that is). This came up while working my way through bugs identified by the Kindle Previewer tool.

Anything come to mind for anyone?

Edit: Oh, I found the Rebase OPF Manifest IDs on Current Filenames feature in Sigil and it appears to achieve almost exactly what I had in mind.

Edit #2: Oops, I was wrong. I like the tool but it doesn't actually sort in the order I'm wanting to see (book/part/chapter/chapter-section order, essentially). Not fully, anyway. Can't figure out why but my first guess is some items are ordered the way they are because something is using creation date/time info as one of its criteria.

[JSWolf]

Why does it matter the order of the manifest in the OPF?

[KevinH]

Yes, the manifest order is meaningless and can never be seen by a reader of the epub. The spine determines the display order by providing an ordered list of manifest ids.

And understand that the manifest will include many resources not part of any one xhtml file such as images, css, fonts, and therefore not part of the spine. So what "order" would you use for those?

If you use Sigil or Calibre, epubcheck can be used and the error information from the validation window will take you directly to the file with the error, and drag, and drop can be used to reorder the spine. And of course using Find when editing the OPF can be used to track down manifest entries if you have really large manifest.

[Fitz Frobozz]

Thanks for the thoughtful replies! Sorry for any confusion. My motivation was based on a misunderstanding, which I figured out soon after the above.

I have been correcting errors in an ambitious ePub project and was struggling with the the Kindle Previewer GUI tool's shortcomings as far as making it clear which files it is actually referring to when multiple files of a given type happen to have the same title in the Table of Contents (in this case, "Notes"). My misguided thinking had been that I would try to use the manifest to help with that but I quickly realized that it wouldn't be of any help here. Instead, I wound up just temporarily renaming the TOC titles for the files in question, which resulted in me actually knowing which ones needed fixing when I ran the test again.