I am in 100% agreement with you. The only question in my mind is if we could make the ImportEpub.cpp code be more robust to broken manifest entries somehow, without adding potential problems.
Something like take each manifest entry and try the following:
1. try url % decoding manifest entry to see if it matches a file in the epub zip archive
2. if not, try xml decoding the manifest entry to see if it matches a file in the epub archive but report a url encoding warning in the manifest.
3. finally, if not, try taking it at face value (no xml decoding or % decoding) and see if the manifest href matches a file in the epub zip archive.
4. if not report the manifest entry url not being present in the epub as a warning...
After doing this for every manifest entry, report any leftover files in the epub zip as unmanifested.
That may help Sigil read in epubs with broken manifest hrefs.
Quote:
Originally Posted by DiapDealer
As far as I'm concerned, Sigil is handling filenames with ampersands correctly. You can rename files within the epub and Sigil will properly encode the path in the opf manifest. Sigil will also open any epub that has a filename with an ampersand so long as the ampersand is encoded correctly in the opf manifest (and the path exists).
The only time there's a problem is if an existing epub has an opf with an invalid ampersand character in it. And even then, it's not because of the illegal ampersand character (directly) that files might be discareded when subsequently saving the epub. It's the fact that the illegal character makes the path to the file incorrect. Which means it's not properly manifested. And improperly manifested files have always been discarded when opening them.
|