Bookmark Issue with Full Page references

[GitHubRulesOK]

A previous Issue was closed as amongst other problems in the file one Bookmark References was pointing at the base of page rather than the top

This issue has been opened since that case appears to be more common as a result of bookmarking tools using different methods that appear to be acceptable in Acrobat. The claim that version 3.1.2 worked the same as Acrobat is only partially true depending on page mode and certainly not 100% of mis references. Certainly version 3.2 is more accurate thus less forgiving of such bad page references.

From https://forum.sumatrapdfreader.org/t/bookmark-errors-in-recent-versions/2600/8

One example given on the forum where the page referencing can be clearly seen switching backwards and forwards (thus a common rule or toggle per document would not work) is publicly available from https://www.packtpub.com/gb/mobile/c-8-0-and-net-core-3-0-modern-cross-platform-development-fourth-edition as

C-8.0-and-.NET-Core-3.0-–-Modern-Cross-Platform-Development-4th-Edition-by-Mark-J.-Price-2019.pdf

[Witchdoctr]

Thanks for setting this up. I tried to make an example PDF to show the issues.

This will work fine in most PDF viewers (acrobat, chrome, firefox and earlier Sumatra versions.)

The issue seems to be the bookmark references as you state.

Example of a broken bookmark settings:

Broken PDF Attachment sumatra-bookmark-test.pdf

Fixed PDF Attachment sumatra-bookmark-test - fixed.pdf

Basically setting the bookmarks to fit page seems to "fix" the issue by making it jump to the page vs the section

[GitHubRulesOK]

@Witchdoctr I have only just checked your above files, but note they are not related to the primary issue here as SumatraPDF does not change zoom value or use other programmed actions (which can be driven by javascript etc. thus it generally ignores such settings)

SumatraPDF uses the x and y values to position the top left corner of the current zoom.

This is different to the way that Acrobat authors can and will often reset the zoom factor against the readers requirement.

You files actually highlight that version 3.1.2 was not using the x value. Where as the current version now does and moves the view correctly to the left hand edge.

The key factor in this issue is that some editors will set the page extent (which affects the y value such that the view shows the bottom edge of the page (and the next page) rather than the top of desired page.

[GitHubRulesOK]

@kjk it looks like acrobat and other editors may use a full page goto range (say 0,666) for a full page view, which SumatraPDF in continuous mode goes to bottom left corner and shows as the next page. It works for full page view but not continuous

see in the OP C#8 sample Preface page:28 destkind:scrollTo destname:# 28,0,666 pos:0,666

[GitHubRulesOK]

I am closing this mixed issues as many changes have been implemented since above last tests

Moving forwards, any Odd Page reference behaviour needs to be measured against versions after 3.4.13750