[GUI Plugin] Count Pages

[kiwidude]

Preferences -> Toolbars, there are different toolbars for when a device is and is not connected, you have to add the plugins to both. Grumble, mumble, hate that "feature"...

[theducks]

Originally Posted by kiwidude

Preferences -> Toolbars, there are different toolbars for when a device is and is not connected, you have to add the plugins to both. Grumble, mumble, hate that "feature"...

That feature is good in that there are 'context sensitive' items
The alternative is for the Item itself to recognise the 'Connected' status and grey itself out if no connected device (My favourite way)

[kiwidude]

Sorry theducks but there is nothing "good" about that feature in my opinion. It is completely and totally unprecedented in any application I have ever used - applications do not remove their main toolbar when "context changes" in such a minor way like this. Add a new toolbar by all means, but not swapping out the main one.

Besides which, it should not be a "context switch". Just because I have a device plugged in does not change context. In all probability it could well be plugged in just to charge. That changes nothing about how I want to be using calibre, but this nonsense about adding icons to multiple toolbars *forces* the user into either working differently, unplugging their device, getting confused, or faffing around with the clumsy process of putting icons on multiple toolbars, and trying to keep them all in sync or else icons get moved around just because their device is plugged in.

It is a silly idea that I hate with a passion. But as I have said before, my views on this are based around using and supporting a lot of plugins - and GUI plugins didn't exist when this implementation was created in calibre.

[Dopedangel]

Originally Posted by kiwidude

Sorry theducks but there is nothing "good" about that feature in my opinion. It is completely and totally unprecedented in any application I have ever used - applications do not remove their main toolbar when "context changes" in such a minor way like this. Add a new toolbar by all means, but not swapping out the main one.

Besides which, it should not be a "context switch". Just because I have a device plugged in does not change context. In all probability it could well be plugged in just to charge. That changes nothing about how I want to be using calibre, but this nonsense about adding icons to multiple toolbars *forces* the user into either working differently, unplugging their device, getting confused, or faffing around with the clumsy process of putting icons on multiple toolbars, and trying to keep them all in sync or else icons get moved around just because their device is plugged in.

It is a silly idea that I hate with a passion. But as I have said before, my views on this are based around using and supporting a lot of plugins - and GUI plugins didn't exist when this implementation was created in calibre.

I agree with you completely that's why I use the 2nd toolbar for all my plugins etc and the main toolbar I just keep the basic buttons.

[kovidgoyal]

@kiwidude: Specially for you: http://bazaar.launchpad.net/~kovid/c...revision/11768

[Culex]

Count ePub/Mobi Statistics
-------------------------------
Logfile for book ID 411 (The Rolling Stones - lit)
FAILED TO COUNT PAGES
FAILED TO COUNT WORDS
411
InputFormatPlugin: LIT Input running
on C:\Users\Culex\AppData\Local\Temp\calibre_0.8.46_t mp_t5h0w6\cfvcox_count_pages\411.lit
Parsing all content...
Forcing HEINLEIN, Robert A - The Rolling Stones.htm into XHTML namespace
Estimated accurate page count
Lines: 8059 Divs: 4 Paras: 2699
Accurate count: 259 Fast count: 221
Page count: 259
Word count: 65625
Traceback (most recent call last):
File "calibre_plugins.count_pages.jobs", line 128, in do_statistics_for_book
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: u'C:\\Users\\Culex\\AppData\\Local\\Temp\\calibre_ 0.8.46_tmp_t5h0w6\\cfvcox_count_pages\\411.lit'

I get this error whenever I do a word count on any LIT or LRF book. AZW, EPUB, CBR, MOBI, PDF, ZIP all work without error.

Has anyone else had any trouble with LIT or LRF files? It used to work in the previous version of count pages. If there is both a MOBI and LIT version, Count Pages defaults to LIT.

[theducks]

Originally Posted by Culex

Count ePub/Mobi Statistics
-------------------------------
Logfile for book ID 411 (The Rolling Stones - lit)
FAILED TO COUNT PAGES
FAILED TO COUNT WORDS
411
InputFormatPlugin: LIT Input running
on C:\Users\Culex\AppData\Local\Temp\calibre_0.8.46_t mp_t5h0w6\cfvcox_count_pages\411.lit
Parsing all content...
Forcing HEINLEIN, Robert A - The Rolling Stones.htm into XHTML namespace
Estimated accurate page count
Lines: 8059 Divs: 4 Paras: 2699
Accurate count: 259 Fast count: 221
Page count: 259
Word count: 65625
Traceback (most recent call last):
File "calibre_plugins.count_pages.jobs", line 128, in do_statistics_for_book
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: u'C:\\Users\\Culex\\AppData\\Local\\Temp\\calibre_ 0.8.46_tmp_t5h0w6\\cfvcox_count_pages\\411.lit'

I get this error whenever I do a word count on any LIT book. MOBI works without error? Has anyone else had any trouble with LIT files? It used to work in the previous version of count pages. If there is both a MOBI and LIT version, Count Pages defaults to LIT.

Count pages should not even try LIT files. EPUB and Mobi are the listed formats. You set the priority of which gets done (it is NOT both)

[Culex]

On a different note, when comparing the length of 2 books which is more accurate? Page Count or Word Count? I have 1 book that is 304 pages and 115k words, and a 589 page book with 95k words. Which is the longer read?

[kiwidude]

@Culex - re your error - change your "Preferred Input Format Order" in Preferences -> Behaviour so that MOBI is higher than LIT.

Re "accuracy" - word count will always be more accurate. But bear in mind that if your books are from different sources, even word count will differ if for instance there are contents pages, previews of the next book, author information, copyright etc etc.

[Culex]

Originally Posted by kiwidude

@Culex - re your error - change your "Preferred Input Format Order" in Preferences -> Behaviour so that MOBI is higher than LIT.

Re "accuracy" - word count will always be more accurate. But bear in mind that if your books are from different sources, even word count will differ if for instance there are contents pages, previews of the next book, author information, copyright etc etc.

Thanks for the quick reply. In Preferences, it's EPUB -> MOBI -> LIT already.

[kiwidude]

Hmmm... interesting. I just tried that same scenario and like you got the same error. It should be looking at the MOBI, not the LIT file based on those preferences but clearly something isn't working as it should.

@Kovid - my code is calling:

from calibre.gui2.convert.single import get_input_format_for_book
...
input_format, input_formats = get_input_format_for_book(self.db, book_id, None)

My preferred input order is set to: EPUB, ZIP, MOBI, PRC, LIT

However the result I get back from the function above seems to be an *alphabetical* sort, not a preference sort. As it will give me [ 'epub','lit','mobi','zip'] or ['lit','mobi','zip'] for a book with those formats respectively.

Clearly not what I wanted. Is the function in calibre not working right, am I using it wrong, or is it actually right but just not doing what I want? It has code in it saying "sort_formats_by_preference" which led me to believe it was the right thing but clearly not...

[Culex]

I have also noticed that Word Count on PDF's is totally inaccurate. I have a EPUB that gives me 434 pages w/ 119k words, and the PDF gives me 539 pages with 8.9k words. I've noticed as a trend it seems to be close with the page counts but word counts are exceptionally less w/ PDF. I don't really consider it to be a big deal as I hate PDF anyway. Just FYI.

Oh, you can't disable the LIT plugin either as a temporary workaround.

[kovidgoyal]

What that function returns depend on whether you have converted the book in the past. If you have then it returns the format you used as the input.

You want to be looking at the first return value which is the preferred input format, not the second which is just a list of formats available for the book.

For example:

calibre-debug -c "from calibre.library import db; db = db(); from calibre.gui2.convert.single import get_input_format_for_book as g; print g(db, 1053, 'asdff')"
gives
(u'mobi', [u'lit', u'mobi'])

Where I passed in 'asdff' as pref to ensure that a previous conversion was not used.

[kiwidude]

Thxs for the reply Kovid. Hmmm, guess that function isn't doing what I want then. All I wanted was an ordered intersection of the users preferred input formats, and the formats available for a book which I had thought (clearly wrongly) that function gave me.

I'll figure another way, thanks.

[kiwidude]

Originally Posted by Culex

I have also noticed that Word Count on PDF's is totally inaccurate. I have a EPUB that gives me 434 pages w/ 119k words, and the PDF gives me 539 pages with 8.9k words. I've noticed as a trend it seems to be close with the page counts but word counts are exceptionally less w/ PDF. I don't really consider it to be a big deal as I hate PDF anyway. Just FYI.

That isn't overly unexpected (I assume you meant 119k vs 89k words rather than 8.9k). Remember that it has to convert the pdf to epub to count words/pages. And as has been said a thousand times on these forums pdf conversions to anything as a general rule will suck. Plus you have to make sure the books were identical to have any basis for comparison anyway. Header/footers, page numbers, broken words etc are all going to distort the page/word count for a pdf conversion.

Oh, you can't disable the LIT plugin either as a temporary workaround.

Patience... I'm going to push a new version shortly.