Ok, to be honest, I have difficulty seeing this as a problem. It's more a matter of convenience.
We were worried there might have been some side-effect of the changes that were made to fix the issues with chapter splitting, but it seems this is not the case.
The spine retains the logical ordering of the files as specified in the Book Browser, and there's nothing that breaks the standard or produces an incorrect output.
The only place where ordering matters in the opf is in the spine. Outside that, this is essentially the same as the other issue about the ordering of a metadata attributes - it just doesn't matter, and any program that assumes things will occur in a certain order is broken. The ids used have no purpose other than to allow the spine to reference items in the manifest.
It could be fixed, but the cost would be to slow the program down unnecessarily and introduce more things that could go wrong. Remember that the opf file is only meant to be read by an XML parser - in fact one of the points of Sigil is that it removes the necessity to code or alter it yourself except in specialised circumstances. I'm having trouble thinking of anything you might want to edit in the manifest or spine that you couldn't do much more easily and safely in the Book Browser. Sigil uses filenames for the ids more as a matter of coding convenience than anything else. Again, this is code that's only meant to be read by an XML parser and making it easier to read doesn't confer any functional benefit.
So, it might get changed at a later date if the code is refactored, but I really wouldn't worry about it.
|