Beta testers for calibre 9 needed

[un_pogaz]

Originally Posted by Sirtel

I've attached the scrambled epub with the egregious page count (as the book is in copyright).

Quicl looking, the epub use image use ornamental, wich could add a lot.

@Kovid, I see what you want do by giving 1000 to the image, but I personally recommend transferring them and count them (and SVG) as block, and ignore them in the text.
We coulnd underestimated the number of pages, but it would be better than overestimate. Especially since some ePubs also use "character images" like emojis, so giving them a virtual lenght of 1000 is a bad method for me.
(especialy that image is "not a content" for me)

[bustacap]

Originally Posted by kovidgoyal

Pages counting happens only once so I doubt its that. Not to mention that for comics it doesnt even extract the comic files, just counts the number of image files in the comic archive.

Look at the calibre temp directory and see what is taking up the space.

it creates temp named epubs (for example 6h1m6u6u.epub) of my entire library in the "c:\users\[user]\appdata\local\temp\calibre-v_u8bqvq" folder (characters after "calibre-" are randomized) for whatever reason and never removes them, unless calibre is closed.

if you have an idea what else could cause this, let me know

edit: did the recount pages option to be sure and its doing it again, and only with epub it seems. kfx got removed normally, if i saw it correctly

[un_pogaz]

Originally Posted by BetterRed

Given the degree of inaccuracy (e.g. 38 for 28, 410 for 226) I suggest calibre should not calculate the Pages column for Books that only have a DOCX format.

If a book has multiple formats, which format takes precedence in calculating the Pages column ? Apologies if that's already been addressed.

One thing I like about the count page of Calibre is it don't care of the text formating, only of the raw content (with samll tweaks). It is relatively easy to create a document with 100 word but that have vitrualy 10 pages because you use a big font, or use little font because you have shard eye.
Calibre Page normalize that. This is certainly inaccurate for anyones, but it a standadized average that can be used to compare books, based on their actual content.

[Sirtel]

Originally Posted by un_pogaz

Quicl looking, the epub use image use ornamental, wich could add a lot.

So do a lot of other books in my library without getting such a huge page count.

[kovidgoyal]

Originally Posted by Sirtel

Yes, I already saw that after I posted, so I deleted that part from my previous post.

I've attached the scrambled epub with the egregious page count (as the book is in copyright).

Fixed by: https://github.com/kovidgoyal/calibr...26b098245b588f The test book now gives a page count of 580

[kovidgoyal]

@unpogaz emojis are not counted as images unless for some reason the book is using actual images for emojis, they are usually just normal unicode characters and counted as such.

[kovidgoyal]

Originally Posted by BetterRed

My Input order has manuscript formats (DOCX, ODT, RTF. MARKDOWN... TXT) at top of list. I also keep alternative covers in CBR files, so my War and Peace shows 4 pages .

BR

Why not use the builtin facility for storing alternate covers in the data folder instead? Then you wont have this issue.

[kovidgoyal]

@bustacap: OK I'll take a look at it tomorrow unfortunately real life intrudes in my dev time today.

[Sirtel]

Originally Posted by kovidgoyal

Fixed by: https://github.com/kovidgoyal/calibr...26b098245b588f The test book now gives a page count of 580

Thank you!

[nqk]

Originally Posted by kovidgoyal

yes, the page count in such cases is the number of unique page entries in the EPUB pages metadata.







yes.

Excellent.

It's exactly what I need

Sent from my Pixel 7 Pro using Tapatalk

[BetterRed]

Originally Posted by kovidgoyal

Why not use the builtin facility for storing alternate covers in the data folder instead? Then you wont have this issue.

Most of the CBRs were created before the data folder feature existed, there are 2,351 of them in one library and 799 in another.

If I move them into data folders, I will also want to create a file link in a custom column (I have the column) to view them.

BR

[un_pogaz]

Originally Posted by kovidgoyal

@unpogaz emojis are not counted as images unless for some reason the book is using actual images for emojis, they are usually just normal unicode characters and counted as such.

Yeah, I know, but I talk about this case, which is common for circumvent the limitations of some ereader.

<p>I'm happy <img src="smille_emoji.png"/></p>

Also, their is this case wich is very common (is in the scrambled book):

<p>paragraph paragraph</p>
<div class="center"><img src="ornemental.png"/></div>
<p>paragraph paragraph</p>

In don't very know how the algorithms handled such cases, but using a value of 1000 seems to me to be a bad approach.
I know that give a value of 1000 to img is to simulated a full page that the image can take, but ornemental image are much common, used several time inside a book, wich result to greatly over-estimate the book size. Not to mention the number of examples where the illustrative images do not take up the entire page.

Personally, I much prefer to ignore the images and just treats them like special block that alway return a value of 1 line, and so that we count only the real character. And if the image is a full page, in the vast majorité des cas, is in a specific XHTML file wich is always count at least a 1 page. Yes, this risk to "underestimate" pages count, but it seems to me to underestimate image content than overestimate them.

Maybe give to "get_num_of_significant_chars()" a optional argument for img etc. so we can control which value give to such special block depending of the context. The avantage of the algorithms that we have is we can teak it to have satisfactory and balanced behavior.

[kovidgoyal]

1000 is under half a page. And no that smiley workaround isnt common enough to warrant consideration given with time it will get even less common, since there is no need for it anymore. Adjusting the algorithm should be done on the basis of evidence that its actually a problem. Are there a large number of books where using a value of 1000 causes very bad numbers and is this larger than the number of books where using 0 causes very bad numbers. Fake emoji I think we can safely dscount. What remains is dividers used between schenes/chapters and things like header images per chapter. Add half a page for each of these is not a bad tradeoff when in any imae heavy books, such as, say calibre news downloads, or technical books, or history books with images, it causes undercounts.

[un_pogaz]

Yeah.
I probably think way too much about it. At least I raised my concern, subjet close.

[un_pogaz]

Originally Posted by JSWolf

Maybe Count pages could be itngrated into calibre so we can set the count to different formats based on the format. For example, ADE page number for ePub and calibre's count for Kindle formats.

Reponse to this since it was not.
No, probaly not. First one because it doesn't really make sense to have different algorithms for such similar format.
And frankly, the ADE pages is not that great because it use the xhtml file size, wich lead to count also indent space and the tag itself. It not that much, but can be better.

Originally Posted by kovidgoyal

No DOCX metadata has only a page count if word bothers to update it, it doesnt always, sometimes leaving it wildly off and other software does not set it. Thus I chose not to use it.

Is realy a shame that we can use the metadata page count of DOCX (and probably ODT if so).
On one hand, these file types are a hybrid between static like PDF and fully reflowable like ePub, so their page count has a sens... but since we cannot be reliable on it, yeah better to processes them as fully reflowable.