View Single Post
Old 11-07-2011, 07:02 PM   #19
kiwidude
calibre/Sigil Developer
kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.kiwidude ought to be getting tired of karma fortunes by now.
 
Posts: 4,230
Karma: 1345754
Join Date: Oct 2010
Location: London, UK
Device: Kindle Paperwhite 3G, iPad 3, iPad Air
There seems to be some confusion from the original poster and some of the subsequent replies about his non dc: metadata issue, so here is the "skinny" from me.

As Dwanthy found, the "Update metadata" option does *exactly* the same as a "Save to disk" does. Which means calibre will insert both dc:xxx elements, but also its own <meta> elements. The latter <meta> elements (along with those created by other ePub editing applications like Sigil) are what are not part of the official ePub specification and hence are not in the dc: namespace.

Do these cause a problem for people? For 99.99% of calibre users, the answer is "not in the slightest". The *only* use case I am aware of that a number of people have asked for is where you are self publishing your own book for uploading via websites. Some of these sites that have rules in place that reject ePubs that have elements in this part of the manifest that are non-compliant with the ePub specification. It's arguably a poor reason to reject ePubs, but nonetheless sometimes there are battles you cannot win.

So using this option in Modify ePub/Quality Check allows that small minority of calibre users to detect and fix such issues prior to publication. For any other user of calibre, you should just ignore the option, it will achieve very little for you.

If you try to tick *both* removing non DC: metadata *and* updating metadata, then you are in some ways shooting yourself in the foot. As I explained above, calibre is one of the "culprits" responsible for inserting non dc elements.

As to why I do not run them in the other order, that is intentional. One of the reasons for using update metadata is to allow people to get their book in the same state as if they did a "Save to disk" without exporting and reimporting it. The only way I can guarantee that this is the case (and that all elements calibre generates for updating metadata are present) is to do this action after any other selection in the Modify ePub dialog. Were I to flip them the other way around, you would be missing for instance the calibre timestamp. Which breaks the "integrity" of "Update metadata". The alternative way around it means it breaks the integrity of "remove all non dc:". Either way something "breaks". As I saw the remove non dc: thing as something few users would bother using, I chose the way I did. If the genuine users of that functionality want it the other way around, then I can look at changing it.

One thing this discussion has highlighted is that the logging could offer a better visual indication as to what it is removing - I will sort that out for the next release.

So - if your intention is to remove all non dc: metadata elements, then don't tick "Update metadata" at the same time - do it in two passes. If you want to remove non dc: elements (such as from other editing applications) except for the calibre generated ones, then you can tick both at the same time.

Last edited by kiwidude; 11-07-2011 at 07:08 PM.
kiwidude is offline   Reply With Quote