02-11-2011, 09:15 PM | #31 | |
US Navy, Retired
Posts: 9,864
Karma: 13806776
Join Date: Feb 2009
Location: North Carolina
Device: Icarus Illumina XL HD, Nexus 7
|
Quote:
|
|
02-11-2011, 11:40 PM | #32 |
Groupie
Posts: 180
Karma: 558490
Join Date: Jan 2011
Device: Kindle 5, Amazon Fire 5th Gen, Moto Z Play Droid
|
I wish this was available for K2. =\
|
02-12-2011, 08:08 AM | #33 | |
Addict
Posts: 342
Karma: 533558
Join Date: Feb 2010
Location: WOB / Germany
Device: Kindle
|
Hi,
Quote:
Thanks to you and Kovid for the fast implementation. But I have one question: Is it possible not to send the apnx file automaticly to the Kindle? Because I figured out, that all pagenumbers from my books wich I have tested are way to high! For example: print version: 416 pages ADE: 282 pages Kindle: 813 pages Or an other book: print version: 864 pages ADE: 646 pages Kindle: 2193 pages In this case, I prefer the locatin numbers only. Therefore I would like that the apnx file will not be transferred automaticly. OK, I can delete the file by myself. But I would prefer, if there is an option to choose between to send or not to send. Bratzzo |
|
02-12-2011, 08:37 AM | #34 | |
US Navy, Retired
Posts: 9,864
Karma: 13806776
Join Date: Feb 2009
Location: North Carolina
Device: Icarus Illumina XL HD, Nexus 7
|
Quote:
Good info this will give the developers something to go on. |
|
02-12-2011, 08:58 AM | #35 |
Connoisseur
Posts: 77
Karma: 9324
Join Date: Feb 2010
Device: Sony PRS-650, Kindle 3
|
You can use ApnxGen in meantime, and override the apnx file generated by Calibre with your custom file.
|
02-12-2011, 09:02 AM | #36 |
Sigil & calibre developer
Posts: 2,488
Karma: 1063785
Join Date: Jan 2009
Location: Florida, USA
Device: Nook STR
|
The location number is still shown in addition to the page number from the apnx file. Having the apnx doesn't prevent you from seeing the location number.
|
02-12-2011, 09:32 AM | #37 |
Enthusiast
Posts: 41
Karma: 3948942
Join Date: Jan 2011
Device: Kindle 3
|
Hi all,
I have also noticed that the current page counting algorithm overestimates the number of pages. In the example I have checked a 464-page book is coming out as 980, so it seems that we are around a factor of 2 out. Cheers, Dan |
02-12-2011, 09:47 AM | #38 |
Sigil & calibre developer
Posts: 2,488
Karma: 1063785
Join Date: Jan 2009
Location: Florida, USA
Device: Nook STR
|
I've tweaked the character count for estimating a page. It about doubles the number of characters per page. I've changed it from 1024 to 2300. This takes into account the average number of characters in a page in my test book and gives some overhead for markup.
Please remember this is never going to be 1 to 1 in a paper back book. In some cases it will be more and some cases it will be less. We are estimating page length based on the number of characters because we cannot take the time to decompress and parse the text. The disadvantage of using a character count is pages with short (dialog) will create longer pages then long paragraphs. Making the page count shorter than the paper back. A better but much more resource intensive and slower method to calculate the page length would be to parse the uncompressed text. For each paragraph we would want to find how many lines it would occupy in a paper back book. 70 characters per line and 32 lines per page. So divide the number of characters (minus markup) in each paragraph by 70. If there are less than 70 characters in the paragraph then it is 1 line. Then, count every 32 lines and mark that location as a page. However, I'm not going to use the better method because it will take a lot of resources and too much time processing for such a feature. Sending to device should take seconds not minutes. If someone (goaspy) wants to make an external tool that will generate pages based on the above method, that would be your best bet for getting almost 1 to 1 page numbers. |
02-12-2011, 10:46 AM | #39 |
Guru
Posts: 655
Karma: 64171
Join Date: Sep 2010
Location: Kent, England, Sol 3, ZZ9 plural Z Alpha
Device: Sony PRS-300, Kobo Aura HD, iPad (Marvin)
|
I had an idea, don't know if it's feasible or not...
What if the source has <a id="calibrekindlepage###" />, that the creator can insert for the 'pages', could calibre identify them an use them rather than calculating the positions. Would allow for exact 1:1 match to paper book. Might take too long to loop through getting positions. Just an idea. |
02-12-2011, 10:58 AM | #40 | |
Sigil & calibre developer
Posts: 2,488
Karma: 1063785
Join Date: Jan 2009
Location: Florida, USA
Device: Nook STR
|
Quote:
I'm going to run some tests with decompression and parsing. If the added time it takes to do this isn't obscene I'll look into making it an option. Fast or accurate pseudo page numbers for instance. |
|
02-12-2011, 11:09 AM | #41 | |
Comparer of the Ephemeris
Posts: 1,496
Karma: 424697
Join Date: Mar 2009
Device: iPad
|
Quote:
G |
|
02-12-2011, 11:44 AM | #42 |
creator of calibre
Posts: 43,858
Karma: 22666666
Join Date: Oct 2006
Location: Mumbai, India
Device: Various
|
@user_none: You can have the MOBI output plugin do the calculation for you and embed the result in some unused MOBI EXTH header for the driver to use. For non calibre generated MOBI files, it can fall back to a default, fast algorithm.
|
02-12-2011, 12:28 PM | #43 |
Sigil & calibre developer
Posts: 2,488
Karma: 1063785
Join Date: Jan 2009
Location: Florida, USA
Device: Nook STR
|
Here are my results:
Upload time Accurate 14 books - 29 sec 5 books - 8 sec 3 books - 5 sec Fast 14 books - 13 sec 5 books - 6 sec 3 books - 3 sec Looking at set of 14 books we have approximately double the time to transfer. This is due to decompression and parsing the text. My parser only looks at the amount of visible text. Each page is comprised of 32 lines and each line can have up to 70 characters. A paragraph always starts a new line. The accuracy can be increased by adding support for handling <div class="mbp_pagebreak" /> and <br> tags. One of my test books at page 105 mapped 1 to 1 to the print version. I did not do extensive testing of the other pages. Other books mapped very closely to the print edition. Over all the more accurate APNX generator gives much closer results. With handling for the two additional elements OCRed texts and ones that use the same type setting as their print counter parts should give nearly 1 to 1 page mappings. Now for the big question. Is doubling the time it takes to transfer the book to the device worth a more accurate mapping? The mapping will be thrown off if the print book physical dimensions are different than the average paper back size I'm using. So a hard cover, larger or smaller paper back will cause the mapping to be off. Also, if it is worth the extra time for using the accurate parser would it be worth increasing the time even more by changing the parser to accommodate the two previously mentioned elements and make it even more accurate? |
02-12-2011, 12:31 PM | #44 |
creator of calibre
Posts: 43,858
Karma: 22666666
Join Date: Oct 2006
Location: Mumbai, India
Device: Various
|
I suggest making it an option in the kindle driver and/or putting it into the MOBI output code.
|
02-12-2011, 12:48 PM | #45 |
Sigil & calibre developer
Posts: 2,488
Karma: 1063785
Join Date: Jan 2009
Location: Florida, USA
Device: Nook STR
|
I'll go with the option that way it works with user's existing MOBI format books. If the user selects accurate I'll have it fall back to fast if there is DRM on the book.
|
Tags |
apnx, page numbers |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Firmware Update Kindle adds Page Numbers (and more) | koland | Amazon Kindle | 304 | 07-02-2011 03:54 AM |
Kindle adds Page Numbers (and more) | koland | News | 53 | 03-03-2011 04:30 PM |
Is there a hack for displaying page numbers rather than location numbers? | nesler | Kindle Developer's Corner | 16 | 02-15-2011 12:00 AM |
Epub to Kindle and page numbers | apropos | Calibre | 11 | 12-09-2010 01:42 PM |
Page numbers in iphone vs Real Kindle | palex481 | Amazon Kindle | 26 | 03-16-2009 05:28 PM |