Print Page Approximator for EPUB and EPUB3 v1.1.3

[Aleron Ives]

Originally Posted by Thertzler

I'd love to update the opening post with this as well but I don't see the edit button mentioned in the FAQ... some restriction for new users I assume?

Yes. New users cannot access all features until they reach certain post count thresholds. I've sent a report to a moderator to see if somebody can grant you that ability sooner, since you're obviously not a spambot.

Originally Posted by Thertzler

But maybe a feature like that, some sort of page count suggestion, could be added.

Thanks for taking it under consideration. I know it's not the kind of page counting mechanism you originally envisioned, but it would be nice to have one CLI tool for all our EPUB page numbering tasks.

As far as word counting goes, I would think that you'd count any group of characters preceeded and followed by a space or newline as a word, so that differences in punctuation would not influence the count.

For instance, my text editor's word counter says the preceeding sentence has 37 words, even though it contains commas and a contraction, which matches how I would count the words myself.

[Sirtel]

Yes, it works now with epub. Kepubs, of course, still use 1 screen=1 page.

[Aleron Ives]

Isn't there a patch to force KEPUB to use the regular EPUB page numbers? Maybe that would work (if you're willing to flash new firmware to test)?

[Sirtel]

Originally Posted by Aleron Ives

Isn't there a patch to force KEPUB to use the regular EPUB page numbers? Maybe that would work (if you're willing to flash new firmware to test)?

I found a post by late Davidfor saying that this doesn't work anymore. Kepubs use screen/page system no matter what.

Well, there's an option to display Adobe numbers on the side margin and perhaps that would work for kepubs as well. But it's a lousy option, as it would cover text if you had narrow margins. I have it disabled at the moment on my Kobos, but I'll probably try it some day. Still, I don't think I'll want to use it on a regular basis.

Edit: I found another discussion where it's confirmed that those side numbers only work with epubs (where they're redundant anyway). So no joy there.

[Aleron Ives]

Yes, that option is only for EPUB, and whether it works depends upon the CSS of each book. Some books properly show the page number in the margins, whereas others show the page number on top of the text, making some words at the end of a line unreadable. It's too bad the WebKit renderer won't let you use other page numbering schemes anymore.

[Thertzler]

Originally Posted by Aleron Ives

Thanks for taking it under consideration. I know it's not the kind of page counting mechanism you originally envisioned, but it would be nice to have one CLI tool for all our EPUB page numbering tasks.

While not part of the orignal plan, it turned out that the feature was not actually that complicated to add (honestly, adding the page-map.xml was almost trickier).

Print Page Approximator v1.1.5 should implement pretty much everything you've described.

There's now a new flag, "--autopage" which tells the script to automatically calculate the pages using the numeric second argument as a definition of a single page.

For example:

.\page_approximator.exe .\example_book.epub 30 --autopage --pagingmode lines

...will paginate your book with 30 lines per page for however many pages that results in.

As usual more details are in the readme on GitHub.

Originally Posted by Aleron Ives

As far as word counting goes, I would think that you'd count any group of characters preceeded and followed by a space or newline as a word, so that differences in punctuation would not influence the count.

That's certainly an easy programmatic definition which the Python split() method already incorporates natively so that's what I went with.
Personally I still think that defining pages by word count is a bit questionable because one word could have 2 letters or maybe it could have 16 letters and both would be the same with this method. But well, offering the option doesn't hurt I guess.

[Aleron Ives]

Thanks for your hard work. It's good to have one tool for all your potential EPUB pagination needs.

I can't run the precompiled binary on Windows 7 due to missing DLLs, so I guess I'll have to try it out on one of my Linux machines.

Originally Posted by Thertzler

Personally I still think that defining pages by word count is a bit questionable because one word could have 2 letters or maybe it could have 16 letters and both would be the same with this method.

Yes, and the number of words that can fit on a page varies widely depending upon how much dialogue there is. Even so, it provides a standardised metric for comparing book lengths, which may be useful.

Similarly, the idea of judging paper book length by page count has always been rather silly, as the page size, font size, margin size, and line spacing differ wildly between books. Page count was just the only easily obtained metric with paper books, so it was better than nothing.

[Thertzler]

So during the last month I've continued tweaking the tool, adding some more niche features. I think all functionality should be covered now, which makes this a good time to post the update here.

Version 1.1.6 was the big Roman Numeral update that adds lots of functionality for handling front matter sections. You can either tell the book outright how many front matter pages there are as with the normal page count, or you can combine it with the page=>ToC map and really go nuts micromanaging.

Version 1.1.7 added mostly bug fixes and some more options for handling documents that are either not included in the ebook's "spine" definition or were designated as not "linear", as those were special cases that I was not aware of when I started this project but now they can be handled in a variety of ways.

Since I am now able to edit the opening post, and can just update its Attachments I also no longer need to duplicate them across many posts, so check out the new versions there.

...Still thinking about reworking it into a calibre plugin in the future.

[Thertzler]

Recently I noticed that one of my ebooks contained 'span' tags with the epub:type pagebreak attribute that were theoretically valid page markers, but my reader didn't recognize them because they were not properly listed in the nav file.
There were also some other curious books which had other kinds of non-standard page markers that naturally also didn't work "properly" but since they were there I thought it would be a nice feature to detect such page markers in a book and use them for pagination instead calculating pages manually.

So I went and updated my Print Page Approximator script with that feature and the result is version 1.1.8.

Besides passing a page number as the first argument after the filename you can now pass a css-like selector to find page marker tags to be used as the basis for the page list.

for the most basic constellation in which the tags are already valid, fixing the page list is as easy as this:

.\page_approximator.exe .\example_book.epub "[epub:type=pagebreak]"

For more "custom" page markers the selector might have to be more involved, the more advanced documentation can be found on GitHub.
Needless to say this is more of a power user feature for people who already like to mess around with the innards of their books in editors like Calibre and such, but still... less manual work.

As usual, the attachments are updated in the opening post.