Home / Option to display Real Page Number

I was wondering if the developer of Sumatra Pdf would be kind enough to add an option that you can click under setting menu to contigure Sumatra to display the “Real Page Number” when viewing PDF’s rather than the Page Number that it think’s its one based on OCRing the page and extracting the page number information??? (If that’s what it doing… In any event… I’ve found this feature just gets in the way and is too often wrong…)

All I want is to have a check box somewhere i can click that makes it match the exact page number starting from 1 and counting up to however many pages there are in the document…

For example, If you are on page 2, it should say page 2 instead page “ii”… etc… if you are on page 10, if should say page 10 instead of page “3” simply because for some odd reason it started counting pages as “i”, “ii”, “iii”, 1, 2, 3 instead…

Any ways … i’m only asking for an option to override the default behavior in the event there’s something that actually likes it counting like that… in my experience… its almost never right anyways when it starts counting “i”, “ii”, “iii”…etc…

Sumatra’s simply displaying the page ‘numbers’ (Cover, i, ii etc.) as defined in the PDFs themselves. No OCR being done AFAIK. However it does also display the actual page numbers right alongside. Do they not show up for you?

I agree, would be nice.

@SumatraPeter
The page mumbers ARE shown as you illustrate, only if the “Author” bothered to do their job and include them, unfortunatly too many self-publishers (myself included) dont know their value to the reader and forget or dont bother to embed them.

@sumatraking2
It is not SumatraPDF “at fault” rather the PDF generator not using “best practice”

I’m actually having a hard time coming up with a PDF where the page numbers are shown completely incorrectly. Either it looks like my screenshots above where to compensate for pages ‘numbered’ as i, ii, Cover etc. Sumatra displays (x / Total) alongside, or the PDF displays the page numbers correctly as integers and so Sumatra simply shows / Total alongside:

Can you share a PDF that does neither of these and thus has Sumatra not displaying the actual current integer page number at all?

I seem to remember some Adobe products and possibly not SumatraPDF had problems when pages had been extracted from a larger sequence of numbers

While testing my gallery of PDFs I could not find one that did not exhibit anything other than the two cases you suggest

BUT when I view Adobe’s “INTERNATIONAL STANDARD” SumatraPDF seems confused by the page break note the 3 consecutive pages are viii (=8) 1 (=9) 1 (=10)

untitled.PNG1400×600 112 KB

Your example actually seems to indicate that Sumatra’s doing its job perfectly. As far as I can tell it’s the PDF itself that has the stupidly defined page ‘numbers’ as viii followed by 1 and then 1 again. As I surmised above, whenever a PDF has this sort of non-integer funky ‘numbering’ Sumatra cleverly knows to display the actual integer numbering alongside in the form (x / Total), and from your screenshot it’s obvious that it’s doing just that.

In short, although I’m not an expert on PDF internals, IMO the textbox simply displays whatever’s defined inside the PDF itself (even if incorrect as in your example), but if that text contains non-integer values then Sumatra displays the actual number alongside for the entire document. Frankly, I don’t see any buggy behavior at all, and as I said above it seems the OP’s feature request is already part of the app.

Hmmm
Not withstanding that the standard states the first page is to be stored as 0 and Sumatra will often start as 0/xxx but in common with other viewers increments it to 1 (you may on occasion see the number change from 0 to 1 whilst loading larger files)

I agree SumatraPDF is “correctly” showing that the start of 10th sheet is now visible thus reports the viewer may be on page (10/xxx) the 10th Page is tagged as Page 2 in the TOC and has 2 in the bottom corner which is not going to be visible until the whole page is in view !
However the focus is on 9th page (tagged as 1 in the TOC and off screen shot you would see 1 in bottom RH corner, thus it “knows” Bookmark 2 is on “Page: 1” (9th page) which is ALSO what it should report

So in a way it IS correct in reporting 1 and 9/xxx then 1 and 10/xxx as it rolls down, however this can be very confusing to a less experienced reader

All this is academic for rolling pages since when using page view it will correctly show 1 (9/xxx) and 2(10/xxx)

As a simpler example see the following where I am clearly showing ALL of page 2 (1 is no longer visible) however in this case

1. I am in continuous mode, normally SumatraPDF will flip the page number as the page break moves past the mid page point, BUT
2. my link from the table of contents was a focus on page 1 (there are NO bookmark entries) and thats where my cursor was focused, I can refocus and select text and the page number will not change to 2, so in this rare case of using links to navigate, sumatraPDF (unusually) is not following my other keyboard related actions, only when moving on to page 3 and rolling back to page 2 will it “catch -up”.
   I seem to recollect this was not uncommon in other readers

untitled.jpg721×1021 156 KB

Haven’t really noticed this, but makes sense to me. Irrespective of whether the standard or the programmer dictates that the internal index is to be zero-based, displaying the first page’s number as zero to the reader would just be plain silly.

We seem to have diverged from the thread topic a little, which was a feature request to display the current integer page number that I think already exists.

Your specific example seems to be about when and how exactly Sumatra’s ‘page turn’ logic (i.e. page number increment/decrement) is triggered, and how it can be improved (if at all) in specific cases so that there’s less of a seeming mismatch between what page’s on-screen and what number is currently being displayed. That I’ll leave to @kjk to look into the code and figure out, if he’s interested of course.

I agree the OP request was for the user to “alter” the “base” page numbers so in the 1st of my examples they could change 9th page (actually 8 in Adobe parlance) to be 1 as per the TOC / header / footer, this would also help where extracts are say page 11-21 from a larger journal

My observation was that even if the numbers are changed there can be a 1 page difference / hiccup related to using scroll mode

They are two seperate issues but to the casual user they can appear as randomness especially if combined

What should be done in Sumatra PDF to make the sequence page numbers visible?

Number of pages can be seen multiple ways. The most common for pdf are the file properties and toolbar.

Note: For reflowing dynamic PDF or ePub they can be variable within the same file:

image1180×400 37.5 KB

IF the author bothered to add page number ranges then they will show in the Page: ## box in the toolbar.

IF you are in a fullscreen mode the current page info is shown using i:

For epub modes it’s shown at the bottom:

In the above case the same image may be found at different locations each time it is opened, so the relevant page number is dynamic, which with using re-flow in ePub or PDF can lead to problems so page numbers can mean less than named destinations or tags.

There are several discussions about Real Page Number (see above for instance), but it is up to the user to decide if they wish to accept what the author or their agent determine the numbers will be when forced, OR use an editor to replace those ranges to the user preference.