Incorrect annotation layer position when a parent div container has the "postion: relative" CSS property

Product: @pdftron/webviewer

Product Version: 8.9.0

Incorrect annotation layer position when a parent div container has the “postion: relative” CSS property

Description:
When a custom PDF viewer is initialized on a relative positioned div that has some distance from the viewport top, the annotation layer seems to be placed incorrectly.

Steps to reproduce:
When I activate the text hightlight tool and try to highight some text, the text highlighted seems to be shifted down by a number of pixels corresponding to the distance of the webviewer container div from the viewport top edge.

Minimal sample link:
https://github.com/ThomasIommi/pdftron-issue-test

Thanks for your attention!

Hello, I’m Ron, an automated tech support bot :robot:

While you wait for one of our customer support representatives to get back to you, please check out some of these documentation pages:

Guides:APIs:Forums:

Hi ThomasIommi,

Thank you for reaching out to WebViewer Forum support,

Indeed when I remove the position:relative within the css, the highlight seems to work fine.

To our documentation, we generally keep things auto: PDFTron Systems Inc. | Documentation

Could you alternatively use position: static instead?

Thank you in advance.

Best Regards,
Kevin Kim
Web Development Support Engineer
PDFTron Systems, Inc.

Hi Kevin!

Thank you for your quick reply!

Unfortunately in the real application I have a fairly complex layout and I heavily rely on this div to have the “postion: relative” CSS property: there are several components that are absolutely positioned in order to be displayed in the correct place and automatically react to dynamic layout changes, such as opening and closing of sidebars and toolbars.

I also tried the “recalculateLayout” function, but it only helps for updating the horizontal desyncronization caused by the dynamic layout changes I previously mentioned, not the initial vertical one.

Thank you again

Best regards!

Thomas

Hi ThomasIommi,

I also tried a bunch of methods that could be related in our DocumentViewer class to refresh/update the view but unfortunately there wasn’t anything that affected the issue.

I am not an expert at the CSS layout properties, but there might be a way to trick WebViewer into raising the same height from the bottom by the same amount from the top (i.e. var(–header-height).

I noticed that in our demo, we also have a position: relative somewhere in the parent div:


so there should be something in the CSS that you can change the values of:

Demo link for reference:

Best Regards,
Kevin Kim
Web Development Support Engineer
PDFTron Systems, Inc.

Hi Kevin!

Thank you again for your patience :slight_smile:

In the PDFTron demo the viewer is wrapped into an iframe, so from its point of view it’s like the whole html page starts from there.

Screenshot from 2022-10-20 10-15-23

I successfully reproduced the same situation updating my project in GitHub.
When I wrap the viewer into an iframe it starts to work correctly.

Vice versa you can reproduce the issue I’m reporting also in the PDFTron viewer demo by changing the div with class “content” (also highlighted in the screenshot) to “position: relative” and then by triggering some function that automatically recalculates the layer position (i.e. zoom in).

However wrapping the viewer into an iframe it’s really complex and force me to implement a new layer of communication from the main page to the viewer iframe.
I also cannot use the Angular or NGRX framework at all in the iframe, sincethey are completely isolated from the rest of the page.

Best regards!

Thomas

Hi ThomasIommi,

One possible reason this may be happening is due to how the pdf’s coordinates are offset by the height of the header:
If I remove the height property from the header in your sample, the offset seems to be returned to normal.

There may be some conversion that may need to take place between the window and the pdf coordinates, you can find more about it here:

If you can create a document, you could also try re-rendering pages:

Best Regards,
Kevin Kim
Web Development Support Engineer
PDFTron Systems, Inc.

Hi Kevin!

Sorry for my late reply.

I’ve tried what you suggested, but still, even after removing the CSS height property from the header element I experience a shift in the hightlight position. It’s smaller, but still there. It’s easier to test it in the second page where the font size is also smaller.

I also tried the loadCanvas/loadCanvasAsync functions with no success.

However, after a lot of tests, I found out that some CSS propertis affect the “virtual area” where I can trigger annotations and some do not, so I came up with this workaround:

#virtualListContainer {
  top: -8rem; /* this is exactly the header height */
  margin-top: 8rem;
}

#selectionrect { 
  margin-top: -8rem;
}

or

:root {
  --header-height: 8rem;
}

#virtualListContainer {
  top: calc(0rem - var(--header-height)); /* using CSS variables also works */
  margin-top: var(--header-height);
}

#selectionrect {
  margin-top: calc(0rem - var(--header-height)); 
}

It seems that the annotation layer can correcly handle the margin-top property, but not the top property, while the canvas html element luckily handles both! For the canvas element those properties cancel each other out (at least on Chrome that is my target browser) and I can use them to recollocate the annotation layer in the correct position.

Hope it helps :slight_smile:

Best regards,
Thomas

Hi ThomasIommi,

Thank you kindly for your patience and your response,

We will make a note of this for future issues regarding annotation layer offsets.

Best Regards,
Kevin Kim
Web Development Support Engineer
PDFTron Systems, Inc.