MobileRead Forums - View Single Post

ElMiko · 10-26-2011, 07:55 AM

D'oh! As per usual, asked and answered!

Thank you for your explanation, though (and the interesting discussion that you linked). I am constantly being reminded that merely because something may be simply conceived, it's rarely simply achieved.

Unsurprisingly, you raise valid questions about the design characteristics involved in integrating this kind of functionality into the Count Pages plugin, particulary what kinds of processes woudl be most efficient for dealing with metadata retrieval exceptions. My inclination would be to answer "Yes" to all of the hypothetical solutions you propose! But, of course, I'm not the poor bastard figuring out how to do it and writing the code for it! I can, however, be more constructive in responding to the philosophical (rather than functional) question/concern you raise in the final sentence about pagecount consistency. Short version: I don't think this would be a problem. Longer version: As it stands, the Count Pages plugin (as I understand it) is using one of two algorithms to estimate the number of pages in a book. This quality of "estimation" is further evidenced by the substantial difference in page counts depending on which of these algorithms the user selects. One will result in page counts similar to the Kindle's, and another will results in page counts similar to Calibre's internal e-reader. And even there, it's not entirely consistent. And sometimes (rarely), due to hinky (yeah, technical term) formatting in the source file, Page Count will give up the ghost and come up with a page count of 1 (or 4, or 7, or 12) for what ought to be a novel-length work. At which point, the user goes in and manually changes the page count to what he thinks is closer to the reality he's aiming for. Given this, I would imagine that most users of the plugin are using it to establish a general concept of book-length, not some scietifically, objectively abosolute measure. Referring to physical pagecounts from a online source would merely be yet another (useful) way to conceptualize book-length, but it wouldn't be any more objectively "real" than the two page count algorithms currently available. In the event that a metadata retrieval came up empty, as I see it the user would either find that one of the available algorithms closely approximated the page count of the physical book, or he would manually input a page count that made him happy. The point is, since we're dealing with flexible process to begin with -- one of approximations -- I doubt that a user would lose too much sleep over small differences between algorithmically generated page counts and page counts retrieved from an external source.

---

PS - Not Page Count related: In the link you provided, I was gratified to see interest -- if only passing -- in extracting literary award information from Goodreads (or some other online source) to Tags. These kinds of functionality fantasies set my heart aflutter.

10-26-2011, 07:55 AM	#150
ElMiko Evangelist Posts: 480 Karma: 65460 Join Date: Jun 2011 Device: Kindle	D'oh! As per usual, asked and answered! Thank you for your explanation, though (and the interesting discussion that you linked). I am constantly being reminded that merely because something may be simply conceived, it's rarely simply achieved. Unsurprisingly, you raise valid questions about the design characteristics involved in integrating this kind of functionality into the Count Pages plugin, particulary what kinds of processes woudl be most efficient for dealing with metadata retrieval exceptions. My inclination would be to answer "Yes" to all of the hypothetical solutions you propose! But, of course, I'm not the poor bastard figuring out how to do it and writing the code for it! I can, however, be more constructive in responding to the philosophical (rather than functional) question/concern you raise in the final sentence about pagecount consistency. Short version: I don't think this would be a problem. Longer version: As it stands, the Count Pages plugin (as I understand it) is using one of two algorithms to estimate the number of pages in a book. This quality of "estimation" is further evidenced by the substantial difference in page counts depending on which of these algorithms the user selects. One will result in page counts similar to the Kindle's, and another will results in page counts similar to Calibre's internal e-reader. And even there, it's not entirely consistent. And sometimes (rarely), due to hinky (yeah, technical term) formatting in the source file, Page Count will give up the ghost and come up with a page count of 1 (or 4, or 7, or 12) for what ought to be a novel-length work. At which point, the user goes in and manually changes the page count to what he thinks is closer to the reality he's aiming for. Given this, I would imagine that most users of the plugin are using it to establish a general concept of book-length, not some scietifically, objectively abosolute measure. Referring to physical pagecounts from a online source would merely be yet another (useful) way to conceptualize book-length, but it wouldn't be any more objectively "real" than the two page count algorithms currently available. In the event that a metadata retrieval came up empty, as I see it the user would either find that one of the available algorithms closely approximated the page count of the physical book, or he would manually input a page count that made him happy. The point is, since we're dealing with flexible process to begin with -- one of approximations -- I doubt that a user would lose too much sleep over small differences between algorithmically generated page counts and page counts retrieved from an external source. --- PS - Not Page Count related: In the link you provided, I was gratified to see interest -- if only passing -- in extracting literary award information from Goodreads (or some other online source) to Tags. These kinds of functionality fantasies set my heart aflutter. Last edited by ElMiko; 10-26-2011 at 08:19 AM.