View Single Post
Old 07-26-2013, 06:26 PM   #464
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by jackie_w View Post
I believe it's the Save-to-disk which is updating the metadata, not the import or the TOC Edit. I haven't tested this but try Import, then TOC edit then copy (not move, or you'll mess up the library) from calibre library directory to whereever using the Op Sys. I realise this is not 'recommended practice' but if you're careful it may give you what you want.
That's a whole lot more effort than I'd like to have to put into the process. By comparison, I can currently right-click on an EPUB in Windows Explorer and select an option from its context menu to execute the "Modify ePub" script with my chosen options. I get a modified copy of the EPUB in the original directory within seconds.

Yes, granted, setting up the context menu option was a bit of a hassle, but once that was done...

EDIT: Inspecting the Calibre version of the above example in place, I do find that the OPF is intact there; it's even still a true UTF-8 file. However, the "open and save the TOC in Calibre's editor" recommendation resulted in a broken TOC, in that the dtb:depth had been improperly changed from 2 to 3. In addition, the !DOCTYPE had been removed, Calibre had added itself in as a new dtb:generator element, and (oddly) the content and name attributes of the meta elements had switched places, which serves no purpose beyond making the data hard to decipher. The only reason I can imagine why that should happen is that the parser is mindlessly alphabetizing attributes, which is a bad idea in this context.

Further, looking at the actual navPoint elements, all of the perfectly good, logical ID values (like "copy" for the copyright page, "intro" for the introduction, "pt03" for Part 3, "ch05" for Chapter 5, et al.) had been replaced with mile-long UUID values. That is in no way the "minimal change" level that I'm after; I want a process that does exactly what it's told - no more, and no less.

Last edited by Rev. Bob; 07-26-2013 at 06:51 PM.
Rev. Bob is offline   Reply With Quote