Cannot use nameddest url param while bookmarks are accessible from viewer

[maximekl]

Attach (recommended) or Link to PDF file here:

test_bookmark.pdf

Configuration:

• Web browser and its version: Chrome version 84.0.4147.105 (64 bits)
• Operating system and its version: macOS Mojave 10.14.5
• PDF.js version: 2.4.456
• Is a browser extension: No

Steps to reproduce the problem:

1. make an object with the viewer :

<object id="cg" data="http://localhost:9000/your-path/web/viewer.html?file=test_bookmark.pdf#pagemode=none&nameddest=bookmark1"></object>

What is the expected behavior?

We go to the bookmark

What went wrong? (add screenshot)

Cannot retrieve my bookmark with url nameddest, but accessible from viewer bookmarks panel

PDFLinkService.navigateTo: "null" is not a valid destination array, for dest="bookmark1"

Try with pre-release 2.5.207 :

[Snuffleupagus]

There's not actually any destination called "bookmark1", or any other destination either, in your PDF document. Please note that there's neither a /Names nor a /Dest entry in the PDF document catalog, hence this simply cannot work as you expect and it's a limitation of the PDF document itself and not of the PDF.js library; this issue is thus INVALID.

Also, please note that the titles you see in the outline, from a PDF-specification perspective, are not the actual destination objects; see https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G11.2063217

[maximekl]

In Acrobat Pro, we created a specific bookmark named bookmark1, so how can i use it in viewer.html url if it's only available in UI ? How can it is a PDF limitation if PDF.js implement this feature. I

[timvandermeij]

Closing since https://github.com/mozilla/pdf.js/issues/12164#issuecomment-668104121 is the correct answer here.

[GitHubRulesOK]

@timvandermeij You may wish to reconsider closing since the sample provided by OP does have /Dest entries and of those Bookmark1 is acceptable by practically every other reader as a URL #nameddest=bookmark1 here I download above example I am not saying it is a good example or validly constructed HOWEVER PDFium will respect the acrobat style URL even if its only at page level

[Snuffleupagus]

You may wish to reconsider closing since the sample provided by OP does have /Dest entries

As mentioned in https://github.com/mozilla/pdf.js/issues/12164#issuecomment-668104121 those do not exist if you actually look at the /Root dictionary of the document, which is what matters here! (The contents of the /Outlines dictionary, which I'm guessing is what you're looking at, doesn't really apply here.)

I am not saying it is a good example or validly constructed HOWEVER PDFium will respect the acrobat style URL even if its only at page level

It definitely doesn't seem valid, from a PDF specification perspective, and given that most documents actually use destinations correctly I'm thus not convinced that we need to add "hacks" to support such a (broken) use-case.