Quote:
Originally Posted by JSWolf
Well, what I think is to run whatever is selected against each book and then if any issue is found, present it to the user for that one book. Then when that is over, move on until the next book has an error. That would do in the short term until a better way can be figured out.
|
Unfortunately that isn't quite as simple as it sounds to me at least. How does the user "progress" to the next book? That implies there is some sort of state being kept of the search being made, with all the implications that carries of a UI for controlling it and the ability to cancel, see where you are up to etc. And you still need a way of seeing what is "wrong" with that particular book to do something with it.
And while there are times where you might work book by book, there are other users/times where doing the fix in bulk makes sense across a batch of books. After all it is easier to select a bunch of books and use modify ePub once against them with the common settings checked, than it is to book by book do various combinations.
It may be that the ultimate solution is going to have to involve another window (modeless), allowing the user to view the results in various ways such as by issue or by book etc. I've been trying to avoid doing that for various reasons but it might be the most appropriate solution here. In Find Duplicates I took the approach of using highlighting groups, but that had the advantage of the context being identical between and across groups. Another possibility would be to store the data about what is wrong with a book in the database with that book, but a user would still need to choose a menu item to actually see that info which is a bit clumsy to use. So my gut feel at the moment is that some sort of navigational window allowing the filtering of results in various ways and displaying of the associated log data for that result set is going to be the way to go. But alternative ideas welcomed...
Quote:
|
Sure, the ePub in question may have some file that's not UTF-8, but to the user, it looks like it's crashed. The OPF & CSS were encoded in ANSI and when I converted them to UTF-8 without BOM, the crash stopped. Another check you can add in is for proper UTF-8 without BOM encoding. Also, to not have it blow up on ANSI.
|
This is a handled situation where I chose to put the entire error message into the log file to help the user understand why a particular ePub could not have that check run against it. It isn't what I call a crash - that would be if the plugin stopped working. Had I just left the error message at "Unable to open ePub", then you wouldn't know why, and I couldn't tell you either without you sending it to me. I could have added some wordy message in there to that affect of telling the user not to panic, but (a) users are generally lazy and would still post about it anyway to double check what it meant, and (b) it is such a rare occurrence it hasn't been a priority.
There is however probably something I can do with the xml parser to have it avoid that error situation, which I will experiment with. Thanks for posting the exact details of what triggered it/solved it.
As for having a check for UTF-8 without BOM, I'm not quite sure how feasible that is. From what I know and have googled in the past, it isn't possible to tell from a file what encoding it actually has. You can attempt to open it (like with an xml parser) and see if it errors (like has happened here) but I'm not sure what else you can do to identify it. Perhaps Kovid or someone may have a suggestion...