booktype
Page offset for Arabic page numbering, set as 'pageOffset' field in book-config.js.
Set with 'pageOffset' int in book-config.js. modified: book-config.js modified: book.js
Author: Julian Oliver [email protected] Committer: Julian Oliver [email protected]
Hey, this might be a good idea for your special case, but for BookJS as a whole, it seems rather broken. In practice it will mean that page numbering will go this way:: I, II, III, IV, 26, 27, 28, 29
That just doesn't make a lot of sense for average users. So therefore I will not merge this patch.
I understand your underlying problem is that you just want one single numbering system for the entire book, so that those who read the book in a PDF reader only have to deal with one single numbering system and that page numbers will correspond to the page numbers the pdf reader uses.
This problem can be fixed by making BookJS work with a single page numbering system. If you (or someone else) programs this, I promise to merge it immediately. Doing this is a little more complicated, and my own time is now managed by the Booktype feature manager. It has been mentioned to him and so he will have to see whether and how I can be assigned to do this.
This might be a good idea for your special case, but for BookJS as a whole, it seems rather broken. In practice it will mean that page numbering will go this way:: I, II, III, IV, 26, 27, 28, 29
Yes, though only if pageOffset is set to something other than 0.
That just doesn't make a lot of sense for average users. So therefore I will not merge this patch.
OK, no problem.
I understand your underlying problem is that you just want one single numbering system for the entire book, so that those who read the book in a PDF reader only have to deal with one single numbering system and that page numbers will correspond to the page numbers the pdf reader uses.
Yes, that was quite a complaint with the existing book we put out. PDF reader pages don't correspond to the actual pages read. It makes it hard to seek in big books, forcing people to hunt with the scrollbar.
This problem can be fixed by making BookJS work with a single page numbering system. If you (or someone else) programs this, I promise to merge it immediately. Doing this is a little more complicated, and my own time is now managed by the Booktype feature manager. It has been mentioned to him and so he will have to see whether and how I can be assigned to do this.
OK, well that shouldn't be too hard. If I find the time I'll send in the patch ;)
The reason why I set it up this way (roman numbers for frontmatter, arab numbers for the contents) is because there is at least theoretically a chicken and egg problem: when you add an item to the TOC, it will take up more space and could therefore push the just listed item onto a later page. A procedure would have to be set up to go through the toc process so many times until page numbers no longer change (in 99.9999999% of cases that will be the case by the second round).
Maybe the easiest would be to store the html code of the TOC. The rerun the TOC creation until it doesn't change anymore. As far as I can tell, this should be safe.
Now with later additions, the book is being "rerendered" several times anyway for the purpose of setting footnotes, etc. . running it another time shouldn't matter if it's only done once. But sya you have it in an editor view, then one should probably watch out not to do it every other second.