Command+Shortcut for setting page to Next/Previous Bookmarked page

[MarcG2]

I would greatly appreciate a shortcut for navigating to the next or previous nearest bookmarked page. E.g. Let's say Bookmark1 is addressed to page 10 and Bookmark2 is addressed to page 20. If I'm page 15, I'd be able to able to immediately navigate to either page 10 or 20.

I dug through the full command list and couldn't find a command for this.

EDIT I just noticed the feature request forum. I'll create a post there.

[GitHubRulesOK]

generally no concept of proximity in a PDF all pages are written in random order and so too are any bookmarks.

What happens is that on loading a PDF the list of pages and bookmarks are searched for the first and then in effect a list drawn up of those following here are 15 pages placed in reading order without bookmarks

7 0 obj  <</Pages 1 0 R/Names 13 0 R/Type/Catalog>> endobj
1 0 obj  <</Type/Pages/Kids[10 0 R 3 0 R 9 0 R 22 0 R 20 0 R 21 0 R 12 0 R]/Count 15>> endobj
10 0 obj <</Type/Pages/Kids[6 0 R 18 0 R 14 0 R 23 0 R 5 0 R]/Count 5/Parent 1 0 R>> endobj
6 0 obj  <</Type/Page/Parent 10 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[17 0 R]>> endobj
18 0 obj <</Type/Page/Parent 10 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[17 0 R]>> endobj
14 0 obj <</Type/Page/Parent 10 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[17 0 R]>> endobj
23 0 obj <</Type/Page/Parent 10 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[17 0 R]>> endobj
5 0 obj  <</Type/Page/Parent 10 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[17 0 R]>> endobj
3 0 obj  <</Type/Page/Parent 1 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0>> endobj
9 0 obj  <</Type/Page/Parent 1 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0>> endobj
22 0 obj <</Type/Page/Parent 1 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0>> endobj
20 0 obj <</Type/Page/Parent 1 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0>> endobj
21 0 obj <</Type/Page/Parent 1 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0>> endobj
12 0 obj <</Type/Pages/Kids[8 0 R 15 0 R 2 0 R 4 0 R 11 0 R]/Count 5/Parent 1 0 R>> endobj
8 0 obj  <</Type/Page/Parent 12 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[19 0 R]>> endobj
15 0 obj <</Type/Page/Parent 12 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[19 0 R]>> endobj
2 0 obj  <</Type/Page/Parent 12 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[19 0 R]>> endobj
4 0 obj  <</Type/Page/Parent 12 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[19 0 R]>> endobj
11 0 obj <</Type/Page/Parent 12 0 R/Resources<<>>/MediaBox[0 0 595.276 841.89]/Rotate 0/Contents[19 0 R]>> endobj

so to guess which book mark is before or after another is hard work unless you use the sidebar and try up 1 or down 2 and then try to interrogate their list of pages.

It might be trivial in some cases but not in others where bookmarks can even be external file entries of many pages.

[MarcG2]

I think it would make the most sense to just go by the order of bookmarks and assume they're arranged by sequential page order and not bother trying to calculate anything. Sumatra already keeps track of which bookmark is "active". So the program would only need to activate the next one in line (preferably skipping ahead to the next if a bookmark has no target).

[GitHubRulesOK]

I showed pages are not in order that is true for most PDF contents and especially bookmarks so they to are like tree branches with parents and children (prior and next, simple you say use those!) but children can be their grandparents too, the Acrobat symbol is a juggler for historic reason that the code name for PDF was carousel and just like that merry-go-round it goes round in cycles. The theory was based on Turin Engine language as PostScript (but is not) so follows similar upside down constructs like pages start at the bottom thus numerically the bottom of page 2 is immediately after top of page 1, like stacks of plates on sticks. the computer blindly follows the trail of crumbs up-screen or down-screen is not a decision it just needs up key or down key

Take 3 bookmarks 7 8 & 9 luckily are in order 7 and 9 belong to parent 4 and 8 belongs to parent 7 so easy we can go up from 8 to 7 and down to 9 in the navigator or from 9 to 7 and down to 8 and up to 7 simple. but which one is nearest to which they are all sub parts of 4 and go to 6

4 0 obj
<</Count 2/First 7 0 R/Last 9 0 R>>
endobj
7 0 obj
<</A<</D[6 0 R/XYZ 0 740 2]/S/GoTo>>/C[1 0 0]/F 1/Parent 4 0 R/First 8 0 R/Last 8 0 R/Next 9 0 R/Title(All text is "Body" text.)>>
endobj
9 0 obj
<</A<</D[6 0 R/FitR 90 90 300 300]/S/GoTo>>/C[0 0 1]/F 3/Parent 4 0 R/Prev 7 0 R/Title(Hello World!)>>
endobj
8 0 obj
<</A<</D[6 0 R/XYZ 100 500 2]/S/GoTo>>/C[0 1 0]/F 2/Parent 7 0 R/Title(Jane)>>
endobj

[MarcG2]

Sorry but I don't think I understand the exact point your trying to make with that example.

I mean, why not just query the bookmarks side bar for the correct sequence and current "bookmark position" (i.e. highlighted entry) if necessary?
Let's say Sumatra was programmed to navigate between bookmarks in the sequence they appear to the user in the bookmarks side bar. Parent bookmarks would precede their children in the sequence. Navigating the PDF by the order would result expected behavior for 99.9% of the PDFs I've encountered.

[GitHubRulesOK]

The order is assembled as required in a tree based array and the bookmarks follow human order so first is top of first bookmarked page and bottom of tree is last bookmarked page so to go to one earlier it follows Microsoft provided global shortcut key-in methods (thus not affecting canvas area commands) Up or Left for earlier entry and Down or Right for later entry (Plus the ability to go to next by Searching next Initial)

The key-ins for the Bookmarks are simply dependent on that focused area so to jump up or down by bookmarks you need to press F6 (and or F12) +Up or F6 (and or F12) +Down or [F12+] any suitable letter but without any significant coding to decide which is which since as described above relative distance is unknown.

That's a lot of logical decisions as to what key sequences work in one case compared to a seemingly similar but different case thus the developer could need to spent a lot of time adding bloat and potential for bugs in an MS control out of their hands

So not saying its not possible (as part of other changes) simply not likely to be high on a priority list as non trivial