Links section not accurate

[mastasushi]

Describe the bug

Hi, I'm currently using your lib and I'm facing some issues with the links section.

I think the documentation is misleading (maybe wrong)

https://pdfviewer.net/extended-pdf-viewer/links

It says that you have to listen to the pageRendered event to get all the links displayed in the current page, but the problem is that the links are not in the DOM yet, they are present when the annotationLayerRendered event is triggered (I guess, because the links are created inside the annotationLayer).

Different types of URL links

I'm not a big PDF format specialist, but I figured that there were 2 types of links and they behave differently in PDF Js (or your lib, from my early tests, I can't really tell which does what).

1. The ones that are explicitely present in the file (I can see them with PDF editing tools, I'm using PDF XChange Editor), where you give to URL to the target. These links seems to be added correctly when the annotationLayerRendered is called.

2. The ones that are auto-detected in the displayed text, for example https://github.com or mailto:test@gmail.com . Those links do not seem to be rendered when annotationLayerRendered is called, the seem to be added after. So to detect them, I need to do some tricks like set a timeout.

Could you confirm my theory and maybe have a reliable way to detect them all ?

Some random errors

I also encounter some random error when the links are displayed :

#injectLinkAnnotations: Error: `render` method must be called before `injectLinkAnnotations`.
    at AnnotationLayerBuilder.injectLinkAnnotations (viewer-5.4.1105.min.mjs:31:252339)
    at PDFPageView._injectLinkAnnotations (viewer-5.4.1105.min.mjs:31:322631)
    at async viewer-5.4.1105.min.mjs:31:317656

I don't know if they influence the link detection or not ?

Full stack here :
PDF JS injectLinkAnnotations render error.txt

Version info

• I'm using ngx-extended-pdf-viewer version 25.6.4

Demo PDF file

I created a simple PDF with both types of links :

preview.PDF

Thanks

[TomaszStanik]

We're facing same issue in our application for .pdf previews.

[mastasushi]

If it might help you, I solved the problem differently with this code :

  pdfLoaded() {
    // Clean up the previous listener before creating a new one to prevent memory leaks
    this.unlistenFunction?.();

    const pdfViewerContainer = this.elementRef.nativeElement.querySelector(
      '#viewer'
    ) as HTMLElement;

    this.unlistenFunction = this.renderer.listen(
      pdfViewerContainer,
      'click',
      (event: MouseEvent) => {
        const targetElement = event.target as HTMLElement;
        if (this.shouldInterceptLinkClick(targetElement)) {
          event.preventDefault();
          this.handleCustomLinkClick(targetElement);
        }
      }
    );
  }

  private shouldInterceptLinkClick(
    link: HTMLElement
  ): link is HTMLAnchorElement {
    return link.getAttribute('href')?.startsWith('http') ?? false;
  }

I catch any clicks in the parent container, then if the real targetElement is a classic URL link (not mailto or ftp), I prevent default and customize my behaviour.

That does not solve the random #injectLinkAnnotations errors, but I can handle my links consistently this way.

[stephanrauh]

As for the #injectLinkAnnotations errors: try version 26.0.0-rc.1. It solves a race condition that caused these errors.

[TomaszStanik]

@stephanrauh

Unfortunately, this version looks to be broken - few errors are being throwed into the console.
All errors are from the toolbar.

Check this page & open the console.
https://pdfviewer.net/extended-pdf-viewer/custom-toolbar

viewer-5.4.1354.min.mjs:31 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'addEventListener')
    at new CommentSidebar (viewer-5.4.1354.min.mjs:31:53511)
    at new CommentManager (viewer-5.4.1354.min.mjs:31:49638)
    at Object._initializeViewerComponents (viewer-5.4.1354.min.mjs:37:3085)
    at Object.initialize (viewer-5.4.1354.min.mjs:31:431520)
    at async Object.run (viewer-5.4.1354.min.mjs:37:8759)

Logs from my app:

[stephanrauh]

@TomaszStanik Good point - but that's a different issue. I've opened a new ticket (#3143).