MobileRead Forums - View Single Post - A too strict decision?

arspr · 08-03-2014, 11:10 AM

Hi Kovid, (and rest of users),

I've just noticed that because of this recent commit Check Book has stopped showing errors when critical parsing ones have been found. And I understand this is probably a needed tweak because, if you cannot properly "read" a book, what the hell are you going to say about its contents.

The problems I see with this decision:

Possibly habit, (because of the way Calibre has worked till now and therefore I'm used to the previous behaviour), but Calibre doesn't inform the user that it is not showing more errors/warnings/whatever because it has stopped performing tests, not because everything else seems perfect... Is it possible to explicitly tell the user that the tests have been aborted?
Different types of files and parsers. I mean, OK I've got troubles in a malformed CSS file, I understand that Calibre stops informing about that CSS file but why cannot it inform about warnings in any other CSS file? Or why cannot it inform about warnings or other errors in html or opf files which are not affected about that malformed CSS file? Or about the book containing the Calibre bookmarks file?
Maybe some parsing errors are not so critical for other tests within the same file? In the recent book I sent you because of the Live CSS issues I posted in launchpad, there are a lot of parsing errors in its CSS file because of:
Code:
```
 border-width: 1;
```
I mean that a lot of styles lack measurement unit in that property. Is not CSS spec supposed to say that wrong lines (un-parsable) should be ignored?
Another example: imagine an html file with parsing errors (typically missing ending tags), why should the too-big-HTML-file warning be blocked? (Fixing the parsing errors is not probably going to really affect the approximate global size of the file).

As a summary: maybe your decision is fully right, but I think that there's some room for improvement around it: 1st) the user should be explicitly notified, and 2nd) this abortion doesn't need to be absolute but specifically chosen on really affected secondary tests.

08-03-2014, 11:10 AM	#1
arspr Dead account. Bye Posts: 587 Karma: 668244 Join Date: Mar 2011 Device: none	A too strict decision? - Check Book with parsing errors Hi Kovid, (and rest of users), I've just noticed that because of this recent commit Check Book has stopped showing errors when critical parsing ones have been found. And I understand this is probably a needed tweak because, if you cannot properly "read" a book, what the hell are you going to say about its contents. The problems I see with this decision: Possibly habit, (because of the way Calibre has worked till now and therefore I'm used to the previous behaviour), but Calibre doesn't inform the user that it is not showing more errors/warnings/whatever because it has stopped performing tests, not because everything else seems perfect... Is it possible to explicitly tell the user that the tests have been aborted? Different types of files and parsers. I mean, OK I've got troubles in a malformed CSS file, I understand that Calibre stops informing about that CSS file but why cannot it inform about warnings in any other CSS file? Or why cannot it inform about warnings or other errors in html or opf files which are not affected about that malformed CSS file? Or about the book containing the Calibre bookmarks file? Maybe some parsing errors are not so critical for other tests within the same file? In the recent book I sent you because of the Live CSS issues I posted in launchpad, there are a lot of parsing errors in its CSS file because of: Code: border-width: 1; I mean that a lot of styles lack measurement unit in that property. Is not CSS spec supposed to say that wrong lines (un-parsable) should be ignored? Another example: imagine an html file with parsing errors (typically missing ending tags), why should the too-big-HTML-file warning be blocked? (Fixing the parsing errors is not probably going to really affect the approximate global size of the file). As a summary: maybe your decision is fully right, but I think that there's some room for improvement around it: 1st) the user should be explicitly notified, and 2nd) this abortion doesn't need to be absolute but specifically chosen on really affected secondary tests.