Quote:
Originally Posted by JimmXinu
Have you considered making a separate "Search ePub" plugin? I can see a lot of casual users wanting to search inside books, and Quality Check is not necessarily an intuitive place for it. (I don't understand what half of Quality Check does and I write epubs.  ) |
Not seriously considered it, no. Momentarily, yes. It would be one more plugin people would be finding space on the toolbar for, one more plugin to install and update, and contain a lot of replicated code from this plugin that I have to maintain. People using it for its intended purpose of searching for some specific characteristics will think of this plugin as being the right place. People wanting a general search content tool will not, but as implemented it won't fulfill their needs. Your suggestions if implemented are focused on the latter which sways it towards being available separately as an option. I think perhaps will see how it evolves and stabilises and then consider duplicating it, so non QC users can have a standalone option.
Your comments about not understanding some of the features QC has - have you looked at the help file? I have tried to explain what they all are and when you might use them. They are very granular which is why so many, but some things matter more to some people than others. I may one day attempt a single "fix my epubs" option, which combines some QC checks with modify ePub features so all the submenus get left to advanced users, but it is a maybe one day thing for now.
Quote:
Originally Posted by JimmXinu
The detail/log view after searching; if that could show some context on either side of the found text, it would be helpful. Perhaps try and report finds by chapter instead of file?
|
Finding by chapter will never happen, an ePub has no concept of chapters. They could be a simple number, a character name, an image, non existent at all, multiple in a file, split across files.... It just isn't feasible.
I agree text either side would be nice sometimes, but not trivial to implement. Users won't want giant log files if their search expression covers a large content match, so it would have to be an option. And rendering output on the log window is problematic since it is HTML itself. I think this option should only apply during a text only search you suggest below.
Quote:
Originally Posted by JimmXinu
Include a 'text only' search that ignores HTML perhaps? So that the search 'We can only hope' will still find 'We can <i>only</i> hope'?
|
It sounds nice in theory but not sure how well it would work. Stripping the text of all HTML tags is fine but will cause paragraphs to run together, which means words will run together if your ePub is a crappy PDF conversion. And you have stuff like if it has an inserted in the middle rather than a space. Or double spaces causing a lack of match. Or smart quotes failing a match of apostrophes and quotes the user types. So lots of stuff that will impact general search success.
It is good food for thought, appreciate the feedback.