Bookmarks in recent pre-release builds of SumatraPDF are not functioning correctly. The bookmark for the first page (i.e. the first bookmark) is missing and the bookmarks for the last 2 pages are going to the same page. I have created bookmarks in PDF-Exchange Editor and verified that they are functioning correctly in earlier versions of Sumatra and in MS Edge.
Please provide a document that shows the problem and preferably create a bug report via https://github.com/sumatrapdfreader/sumatrapdf/issues/new (as described in https://www.sumatrapdfreader.org/docs/How-to-submit-bug-reports.html)
I updated to 3.2 yesterday, but since then I noticed that bookmarks are not working properly. Instead of going to the correct point on the destination page I instead get sent to the very lowest point of that page.
This leaves only a sliver of the page visible.
I have tried installing the pre-release build and the error still evident there. Does anyone know how to fix this?
I am using SumatraPdf on the latest version of windows 10. If you need to know anything more don’t hesitate to ask.
Using the preview build you can rightclick and export the bookmarks
Usually if it goes to the bottom of the page that is actually what you will find is the destination, with the toc editor you can now save a corrected virtual pdf, but probably easier to use a bookmark edito to correct any that are wrong.
We always need access to a copy of any file to confirm if it is working correctly
Thanks for the response. It seems that the bookmarks in question do indeed have pos values like “0,666”, which I assume is the cause of the problem.
The problem I have however is that these bookmarks worked properly in the previous version of SumatraPDF, as well as other viewers (like chrome), these still put the top of the page at the top of the screen as is intended.
Exported bookmarks:
This was encountered as a common problem that some Authors or their bookmark apps place the destination at the lower page boundary instead of correctly at the top, in such cases the viewer e.g. adobe Acrobat (or in this case SumatraPDF) are expected to be in page only mode similar to browsers not continuous pages.
If working in previous version perhaps that was by default open in page mode
No, I always open in continuous mode, that includes the other viewers that I tested where the same bookmarks go to the top of the page.
Was there maybe some functionality in the previous versions or a setting that fixed the issue? I’m surprised no one else seems to have the same problem, and that it works differently in other viewers.
It seems to me that in continuous mode a bookmark that is off the bottom of the page it should go to the top instead.
Sorry took a while to track down discussion here it is
it is an error on the editors part that can be corrected for in SumatraPDF .bkm or vbkm files but better to change it in the original file.
I get that it is an error in the editor used to create those pdfs, but what is bothering me is that the way SumatraPDF handles the errors has changed. Is there a way I can get the previous behavior back? Is this actually an error/unintended in SumatraPDF and will it be changed back in a coming version?
I don’t have a pdf editor and having to change an indeterminate number of pdfs for years to come is rather a large usability detriment. If it is going to stay this way i’d just like to know.
Is there an option to put this not as a bug but to propose it as new functionality?
There are several conflicting ways bookmarks can be assigned and how a viewer is expected to cope with them is not always clear, SumatraPDF usually tries to emulate Acrobat as much as is possible and if single pages are relaxed (continuous modes) then the title destination (e.g. a heading) should be placed top left of screen i.e. in this case resulting in the start of next page.
3.1.2 did not handle several types of bookmark the same way so you could use that version for files that place heading markers as footnotes
It would be interesting to know from the file info which sources are placing start view at end of page
Thanks, guess I’ll keep using the old version for a while then.
Using the export bookmarks features its fairly quick to correct for one or two rogue entries but if all pages are wrong I would suspect they were not added by the source outline editor or they did not employ a proficient checker.
I seem to have run into the same issue.
It seems to be caused when the bookmark Zoom is set to Inherit in PDF XChange.
These open fine in Acrobat, Firefox, Chrome, PDF XChange and pre 3.2 sumatra.
A quick fix is to just use something like pdftk to dump the bookmarks and re import them. This sets the zoom level to “Fit Page” on all the bookmarks which fixs the issue in Sumatra 3.2
The preferable solution would be for Sumatra to natively accommodate bookmarks automatically regardless of the page mode that it is in. Or, perhaps a simple option to “Always use top of page” for bookmarks. The solution should be transparent with respect how or with what software the PDF was created.
While the thought is greatly appreciated, exporting/importing using “pdftk” may be a workaround but, it is not a practical solution for those folks who may have hundreds or thousands of documents to deal with. A tweak to Sumatra would completely resolve this issue.
Oh I Agree. It has driven me nuts over the last day trying to figure out why some bookmarks work and others didn’t.
I ended up with an Adobe subscription just to see if it was a PDF-Xchange issue. However it actually seems to be a Sumatra error in handling inherent zoom as acrobat and everything else works fine.
batch file for the lazy, outputs the bookmarks as a txt, reimports bookmarks then saves the fixed files in the output folder
forfiles /m *.pdf /c “cmd /c pdftk @FILE dump_data output @FNAME.txt”
forfiles /m *.pdf /c “cmd /c pdftk @FILE update_info @FNAME.txt output output/@FILE”
forfiles /m *.pdf /c “cmd /c del @FNAME.txt”
If you want a particular issue fixed:
As far as I can tell, this thread talks about different issues.
Either way: no sample document => can’t investigate and fix the issue.
Perhaps you have forgotten, I did just that back in January. Your team’s review of the issue concluded with the comment that Sumatra was functioning as intended and thus there was no issue to be addressed. The issue was “closed” by your team. And yet…here we are…
I have opened a fresh issue for the In Design C#8 flip flopping example quoted above
Other examples e.g. from tracker products should be posted under seperate issues
Thanks for making a new issue, I hope I posted enough information for you.
I’m not a skilled enough programmer to fix it myself so I was happy with my batch script workaround. I only use it to open the same 10 or so PDF’s in separate instances everyday so it wasn’t that annoying!
