[GUI Plugin] Quality Check

[JSWolf]

Originally Posted by btfoster4545

ah- thank you!

If you're not going to help us by giving us the details we need to try to help you, then we can't try to help you.

[DNSB]

Jon, given the information from btfoster4545 and thiago.eec and the last post from btfoster4545 saying thank you, it appears that the issue was, as suggested, that instead of library, selected books was selected in the Search Scope.

[jenrar]

Okay, I did a search and didn't find anything, so hopefully I just didn't miss it.

I used this mainly to search for certain cover sizes. I just realized it's put a pin on the left on some of the books. Hovering over it shows Marked with text "cover_check". Is there a way to get it not to do that or to batch remove that now so I don't have to do it one at a time?

Thanks in advance.

[BetterRed]

Originally Posted by jenrar

Is there a way to get it not to do that or to batch remove that now so I don't have to do it one at a time?

Try Mark books->Clear all marked books:



Ctrl+Shift+M is my shortcut, afaik there's no default.

BR

[kiwidude]

Release Notes:
https://github.com/kiwidude68/calibr...y_check-1.14.8

Some minor bug fixes mostly with the Check broken image links function in log output or very baldy formed urls preventing the plugin from scanning the entire ebook.

[enuddleyarbl]

Is there a way to search for books that do NOT contain a specific string in their CSS stylesheets? I've got version numbers on my stylesheet.css iterations and I'd like to find those books that aren't using my latest version ("v20261013").

[JSWolf]

Originally Posted by enuddleyarbl

Is there a way to search for books that do NOT contain a specific string in their CSS stylesheets? I've got version numbers on my stylesheet.css iterations and I'd like to find those books that aren't using my latest version ("v20261013").

Try this search in CSS.

^((?!v20261013).)*$

[enuddleyarbl]

Originally Posted by JSWolf

Try this search in CSS.

^((?!v20261013).)*$

It appears to be working-ish. I have 608 books in my library. If I run that search in Quality Check's "Search ePubs" against CSS files, it returns 575 hits. If I run a search looking for just v20261013, it returns 67 hits. Unfortunately, the total of those two searches is 642 books instead of the 608 I have. So, someplace, books are being counted twice.

I'm trying to parse what that search is doing. If it were just

^(?!v20261013)

, I'd think it would match the start of the line not followed by v20261013. But, with the parentheses and .*$, I'm guessing it somehow modifying that so that it's looking for any group on a line that does not include v2026103. But, I'm not sure how that's working.

So, I tried

^(?!.*v20261013)

to match the start of line not followed by any string ending with v20261013. That gives me (what looks like) the same 575 hits as yours. Unfortunately, I still don't see where the duplicate hits are coming from.

But, I'm still working on it.

EDIT: There's also a problem that I can make a case for those searches meaning find a CSS file with a line it in *somewhere* that does not contain v20261013. But, if that were true, EVERY file would satisfy that. And, even if I turn off the "Show All Occurrences" option (so the search would stop at the first hit in an ePub), I still get that same 575 hits. Looking at the log of the search, it looks like it's stopping at the first line of each book's CSS file because it does not contain v2026103 (which matches the search criteria).

[enuddleyarbl]

Let me go back to

^((?!v20261013).)*$

since that's the kind of thing I see elsewhere on the web for finding things not in a line.

An awful lot of the time, if I look just for the search term (just entering that text) and then the NOT search term (using an edited version of the above), the two searches do not sum up to the total number of books I'm searching on.

For instance, I just tried the search term of div.play in my CSS. Seven results pop up. If I search for

^((?!div.play).)*$

, 602 results pop up. That's 1 more hit than the 608 books I'm searching on. Comparing the two sets of results, I found the book that's in both lists. "div.play" is sitting there in the CSS. I have no idea why the negative lookahead version seems to be dropping odd numbers of results that are also in the straight positive search. And the number of "duplicates" changes with the search term.

[JSWolf]

The problem seems to be with multiple CSS. The regex fails when there are multiple CSS and what's not being searched for is not in any of the CSS.

I just tested it looking for @font on a book that has two CSS files. One with @font and one without @font. When I do the search, I get a match. but if I delete the CSS without @font, I get no match as I should.

This (IMHO) is a bug in the plugin.

[enuddleyarbl]

Originally Posted by JSWolf

The problem seems to be with multiple CSS. The regex fails when there are multiple CSS and what's not being searched for is not in any of the CSS.

I just tested it looking for @font on a book that has two CSS files. One with @font and one without @font. When I do the search, I get a match. but if I delete the CSS without @font, I get no match as I should.

This (IMHO) is a bug in the plugin.

I think you've nailed it. When I started embedding a few fonts here and there in the Calibre Editor, it adds the @font-face at-rule via its own CSS page (called fonts.css). That looks like the culprit here. Thanks.

[JSWolf]

Originally Posted by enuddleyarbl

I think you've nailed it. When I started embedding a few fonts here and there in the Calibre Editor, it adds the @font-face at-rule via its own CSS page (called fonts.css). That looks like the culprit here. Thanks.

You should check for all ePub with multiple CSS and edit them to make just one CSS. It's what I do.

[enuddleyarbl]

I've opened an Github issue on this:

https://github.com/kiwidude68/calibr...ins/issues/188

[kiwidude]

Originally Posted by enuddleyarbl

I've opened an Github issue on this:

https://github.com/kiwidude68/calibr...ins/issues/188

We can debate whether it is a "bug" vs "unexpected behaviour", but yes there is an issue here with any kind of negative lookup. The way the plugin works is it iterates through the content files in the ePub, applying the regex to each file individually.

For positive lookups that approach works fine. However as you found for negative lookaheads that approach doesn't work - if file #1 doesn't have a match, file #2 does have a match, you get a different result than searching "file 1 + file 2".

So why did I not just always compare "file 1 + file 2"? Well (a) that is extra processing, but (b) there is the risk of a false positive coming from a match across the file boundaries being merged together.

I don't like that idea too much. Equally it is expecting too much for the plugin to parse your regex to understand that it is a "negative lookup" and behave differently.

My proposal is to have an additional checkbox with something like "Does not contain". Thereby discouraging such negative-lookahead expressions. So you write the (simpler) normal lookup and tick the checkbox instead.

EDIT: rather than waiting for feedback I'm just going to push ahead with it... test version attached, will wait for translations for official 1.15.0 release.

EDIT 2: officially released as 1.15.0

[enuddleyarbl]

I downloaded the test zip file and installed it via Preferences > Plugins > Load Plugin from File. It appears to work just fine. That "Does Not Contain" option makes searching for negative much easier. Thanks for the quick turnaround. I appreciate it.