Version: 0.12.1 (using KDE 4.6.0) OS: Linux Full article with screenshots: http://techmonks.net/pdf-support-for-multiple-page-numbering-styles You want your book to use Roman numbers for the first few pages, and Indian (often called “Arabic”, although the Indians invented them) numerals for the rest of your book? PDF supports multiple page numbering styles, even in the same document. This was added since PDF version 1.3, and can be found in the 1.7 specification under “12.4.2 Page Labels”. Each page in a PDF document shall be identified by an integer page index that expresses the page’s relative position within the document. In addition, a document may optionally define page labels (PDF 1.3) to identify each page visually on the screen or in print. Page labels and page indices need not coincide: the indices shall be fixed, running consecutively through the document starting from 0 for the first page, but the labels may be specified in any way that is appropriate for the particular document. Unfortunately, not all PDF readers follow the specs. I have tried a few common readers under Windows, all of them recently updated. Acrobat Reader X and Nitro PDF Reader 1.4 (beta) do great. Sumatra 1.5 and PDF-Xchange_2.5 fail miserably. Linux applications show the same variety. I used ISO images from the latest Fedora 15 distribution. Evince 2.91, the default PDF viewer when using Gnome, did great. But for KDE, Okular 0.12.1 failed badly. Reproducible: Always Steps to Reproduce: Open a PDF that contains different page numbering symbols (page label ranges).
Part of this is already covered by bug #187237. What else is left out of it? Would be nice if you could actually list the issues, not generic "page labels are broken" and "I tried okular and it failed".
I mentioned the specific part of the PDF spec that Okular is violating. I guess that is issue enough. If it isn't, that's fine with me, I just continue using a PDF viewer that follows the specs.
Please attach a pdf file that shows the problem.
Created attachment 59375 [details] example: pdf containing different page labels (dutch) A Dutch PDF document showing different page labels. Note that the first three pages are Roman numerals (i, ii, ii), then followed by Indian (Arabic) numerals 1, 2, 3, ...
Evert, it would be helpful if in your bug summary and description you said what it is you think should be changed. It is not strictly true that Okular or other PDF readers mentioned in your blog post "don't follow the specs" -- they simply display the page *index* in the UI. If you propose that the UI used to navigate to pages instead use the page *label*, then please say so. (And if that's indeed the case, then see bug 231000, which has already asked the same thing.)
@Davor: the page index starts with zero (o), by definition, so Okular and others do not display the page index (but might display the page index plus one). Either way, they do not follow the specs. Your interpretation to use page labels for page navigation would be idential to Adobe's implementation, and would IMHO be correct behaviour for any PDF viewer.
Thanks for the clarification, Evert. This can be marked a duplicated of bug 187237.
Agreed, first I thought 187237 was about OCR (PageLabels were not mentioned) but it seems indeed a duplicate. I will mention the discussion here for readers of bug 187237. *** This bug has been marked as a duplicate of bug 187237 ***
Bug 187237 asks for user-selectable page numbering, not automatic as this bug requests. I argue that this bug is therefore not a dupe of bug 187237.
Additionally, Okular is not violating the PDF spec. Okular is not implementing the full spec. There is a difference between violating the spec and not implementing part of it.
Dotan, please read comment #6 about the adherence to the spec. As for the duplication issue, it's not my call, but here is how I see it: displaying page labels and navigating ("go-to") by page label are not the same, but they are related issues. (And Evert brings both up in this bug.) One could track them separately, but until someone actually expresses an inclination to work on them, we may as well keep them together for simplicity sake. But in that case the summary (at least) should reflect that there are multiple aspects of the bug.