Version: 0.8.1 (using 4.2.1 (KDE 4.2.1) "release 103", KDE:KDE4:Factory:Desktop / openSUSE_11.1)
OS: Linux (i686) release 220.127.116.11-8-pae
I am working with ebooks, thesises and scriptums in pdf-format a lot. Most of these documents do not provide clickable links in their table of contents.
Hence one has to enter the page manually, if you want to jump to a certain section.
Table of contents says:
bla bla .................... 23
superinformation ........... 45
Entering ctrl-g -> 45 will not jump to "chapter "superinformation" on page 45 but to "pdf-sheet nr. 45" which might be page 23 or so. That is, because these pdf-documents feature rich prefaces that are not numbered in arabic numbers.
Since I know adobe's reader is able to recognize that, I figured, maybe it is just a matter of changeing the respected counter from pdfpage to pdfpagelabel or something similar.
Maybe that feature is already there and I just could not find it. Forgive me if i wasted your time and thank you for your amazing work!
Practically speaking, this is not a real issue.
One of the reasons why it is not there yet is because there's need to clearly distinguish (in a non-intrusive way) which page search method you want.
Using your example:
> superinformation ........... 45
if I tell I want to go to page "45" does it mean
a) the page labelled "45"? (because the pages can have a label)
b) the page #45 of the document?
You could say: "first look for the label, then go to the page number". And if I want to go to page 45 even if there's a page labelled "45"?
Suggestions (bonus points if they don't add up new options and they don't break the current behaviour) welcome!
*** Bug 231000 has been marked as a duplicate of this bug. ***
Answer from the other report:
> The logical page numbering is actually shown in the TOC, if the document has
Some ebooks don't have it, and Acrobat Reader displays them in page thumbnails pane. It would be useful to have it too for okular.
> One of the reasons why it is not there yet is because there's need to
> clearly distinguish (in a non-intrusive way) which page search method you
Yes, it is a problem and it is confusing what page number really means then.
It could be done by using page number and section number with one artificial secion "document" added every time and used as default item. If you choose this ("document" section) you would get physical numbering, if you select any section other than "document" you will be limited to that section.
I suffer from this issue too, and usually the solution that works for me is to find out the "offset" between pdf-pagenumber and book-pagenumber.
For instance, I find the pdf-pagenumber of book's page number 1. Suppose it's 12. Then I know that when I want to go to book's page N, I must refer to N+11.
Therefore I'd like to propose the implementation of a simple offset right next to the page selector. Okular then would record such offset for every document it ever opens (like it does with last page viewed). It wouldn't solve EVERY incarnation of the problem, but I guess it would suffice for at least 90% of the cases.
Just thought of a straightforward GUI for my last comment: a "This is the first page" button, in the CTRL+G dialog, which would set the offset accordingly!
I agree with both of André's suggestions:
1) A spinbox for offset.
2) A keyboard shortcut and icon for setting Page 1.
*** Bug 268973 has been marked as a duplicate of this bug. ***
*** Bug 271755 has been marked as a duplicate of this bug. ***
Please read the discussion at bug 271755. There, I have included a quote of the PDF specification (the part that I feel Okular is violating at the moment) and attached an example.
In bug 271755 Evert Mouw makes the argument that according to the PDF spec a document may optionally have page numbering that differs from the page ordering. Additionally, that page numbering may be either Arabic or otherwise, or even two different types in the same document. For instance, the first three pages of a document may be I, II, III and the next pages would be 1, 2, 3 (the forth page is the one that starts the Arabic numeration).
In that bug, Every requests that Okular should automatically detect and show these numbers (not OCR, the info is in the PDF as per PDF spec), as does Adobe Acrobat and other PDF readers. In my opinion, that bug is _not_ a dupe of this bug. This bug asks for user-selectable page numbering, not the automatic implementation of bug 271755.
(In reply to comment #10)
> This bug asks for user-selectable page numbering, not the automatic
> implementation of bug 271755.
This bug is about adding a way for the user to go (either in the "Go to page" dialog and in the bottom bar) to a page by inserting its label (like "14", "iii", "IL", etc) instead of the 1..N page number.
(In reply to comment #10)
> In bug 271755 Evert Mouw makes the argument that according to the PDF spec a
> document may optionally have page numbering that differs from the page
> ordering. Additionally, that page numbering may be either Arabic or otherwise,
> or even two different types in the same document. For instance, the first three
> pages of a document may be I, II, III and the next pages would be 1, 2, 3 (the
> forth page is the one that starts the Arabic numeration).
This implies also the fact that your request (the "spinbox for offset") will not be done, given it has no sense at all: there is no such thing as "offset" in page labels, and a document can have different numbering systems across the document.
> This bug is about adding a way for the user to go to a page by inserting its
> label instead of the 1..N page number.
Exactly. Bug 271755 is about adding a way for Okular to correctly number the pages as per the meta information in the PDF document. Not the same thing, hence, not a dupe.
> This implies also the fact that your request (the "spinbox for offset") will
> not be done, given it has no sense at all: there is no such thing as "offset"
> in page labels, and a document can have different numbering systems across the
Not every PDF document contains the page labeling data, furthermore Okular supports other formats in addition to PDF.
In summary, Okular currently displays only the page index + 1 (because the page index itself starts counting from 0). If everyone were to get his wish, then these features would be added:
1) A way to change the page index offset (be that spinbox, keyboard shortcut, or something else).
2) Display of the page label, which may be Roman, Arabic, or something else and may contain multiple types in the same document. This label is encoded in the PDF file and is not user-set.
3) A way to link to the correct page label (actually the OP of this bug).
I'm not an Okular dev, just a very happy user, so please understand that my enumeration of the issues is with the intention of summarising the information in this bug and dupes. I make no claim as to the viability or possibility of coding the solutions, and I respect any decision that the devs do make in that regard. I appreciate all their efforts.
(In reply to comment #12)
> > This bug is about adding a way for the user to go to a page by inserting its
> > label instead of the 1..N page number.
> Exactly. Bug 271755 is about adding a way for Okular to correctly number the
> pages as per the meta information in the PDF document.
That bug is about showing informations we already have.
The resolution of this bug might include also showing the page labels in "go to page" dialogs, bottom bar and consequently also the thumbnail list (the TOC has them already). I don't see how this and that bug are that different.
> Not every PDF document contains the page labeling data, furthermore Okular
> supports other formats in addition to PDF.
In every PDF there are always labels, which in most of the cases are strings equal to the 1..N page number.
> In summary, Okular currently displays only the page index + 1 (because the page
> index itself starts counting from 0). If everyone were to get his wish, then
> these features would be added:
> 1) A way to change the page index offset (be that spinbox, keyboard shortcut,
> or something else).
Again, this is nonsense, and will not be done. I understand this is your pet wish and you want it, but you are assuming things that simply do not hold.
> 2) Display of the page label, which may be Roman, Arabic, or something else and
> may contain multiple types in the same document. This label is encoded in the
> PDF file and is not user-set.
> 3) A way to link to the correct page label (actually the OP of this bug).
If for "link" you rather mean "go", you are correct.
Created attachment 61907 [details]
Patch for adding Page Labels support
small patch to include Page Labels support in the bottom bar.
-if the document provides labels different from the "natural" numbering a second page selection field becomes visible.
-direct navigation to pages by inserting its label
Hi Daniel, thanks a lot for the patch, i am not sure i like the look and feel of the two different line edits there. What do you think about this.
Just one lineedit that shows text in the form of
when the user types something there the following algorithm applies:
* If a number
* If valid page number go to that page number
* else if a valid page label go there
* else if not a number
* If a valid page label go there
* else if "[" + a valid page label + "]" go there
if you want to go to page number 2, you write 2
if you want to go to page with label 2, you write 
if you want to go to page with label ii, you write ii or [ii]
What do you think? Do you think you can work on implementing this?
( Yes, I know I promised to not write anything in Okular reports, exception is made because this is work of somebody outside Okular team ).
Characters really matters, I don't mind [ or ], but tripling the number
is not good (it looks nice when reading, but user has to type it -- and typing takes effort). Also enclosing the number (I typed "[i" and error showed up). Single character is more appropriate -- # or : maybe.
and so on
Maciej, i am the maintainer, so i think i will be the one that decides what we want, not you.
Actually it seems you did not even bother to read my comment since you can perfectly just write "i" if you want to go to the page with label "i" since "i" is not a valid number.
i don't know if the "number [label]" style is very user friedly:
-it doesn't follow the paradigm one infomation per (input) field
-you have to apply the (very basic) syntax which is easy with your explanation but maybe not intuitive if you just run the programm. i second label lineedit should be self explaning as in 95% the label is also printed on the current page
-i think the normal use case is to go to certain arabic numbered page in a large document (see "offset discusion") so you would prefer a posibbility to directly enter the (label) number
-there is enough space in the minibar, so a second lineedit doesn't squeeze the look/bears other limitations
anyway for me the main aspect is AN implementation. i'm going on vacacion till end of august. if it isn't done up to then, write me again and i'll see what i can do.
Created attachment 61975 [details]
okular patched by Daniel, now shows page labels too
I just tried the patched version of Daniel. Concerning the user interface discussion, I feel that mixing two different meanings into one field might be confusing so I prefer two fields when page labels are present. But if the "one field" prevails, than I would like more emphasis on the page labels (when present), like so:
* if a number
* if a valid page label go there
* else if valid page number go to that page number
* else if not a number
* if a valid page label go there
* else if "[" + a valid page label + "]" go there
I mailed to Daniel:
Page label functionality is there. It's great :-) Of course the usability / user interface thing will be discussed and I think that's a minor thing compared to adding this functionality. I suggest a small UI change.
Current: << [pagenumber] ( [pagelabel] ) of totalnumber >>
Suggestion: << [pagelabel] ( [pagenumber] of totalnumber ) >>
At least, okular is now showing correct page labels for the PDF which I used for my techmonks article at
which I will update soon. Thanks a lot, and if I can do more testing, just let me know.
uname -a output: Linux niflheim 2.6.39-ARCH #1 SMP PREEMPT Sat Jul 9 15:31:04 CEST 2011 i686 Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz GenuineIntel GNU/Linux
Git commit 84980e75744aae78c5ab5da1641b24d94dfb1839 by Albert Astals Cid.
Committed on 12/08/2011 at 15:39.
Pushed by aacid into branch 'master'.
For documents with page label, make the lower bar lineedit be the page label instead of number
We show the actual number in a separate qlabel too
Based on a patch by Daniel Oberländer
M +119 -42 ui/minibar.cpp
M +55 -2 ui/minibar.h
Great (In reply to comment #22) that actually works.
But for real ease in reading large books, it would be even more important to have a keyboard shortcut to move to a page based on these page labels.
I have these in one or two documents that I need to add 11 (for example) to each page mentioned in the index to jump there, which is really inconvenient, especially when the topic of the book is quite complex.
I always have to switch concentration layers in my brain between the topic of the book and that old algorithmic machine I once trained when I was a young boy.