Calculating offsets with zoomToMouse

WebViewer Version: 11.9.1

Please give a brief summary of your issue:

Using the scroll wheel, I want to zoom in with the cursor remaining over the exact element in the document. For example, say I have an architectural plan and the cursor is over a particular wall corner. When I scroll the mousewheel, I want it to zoom the document, but for the same corner to remain under the mouse.

I have attached the “wheel” event handler to the scroll view - documentViewer.getScrollViewElement() - and am using zoomToMouse. There are no toolbars or sidebars within the scroll element, so presumably the offsets should be 0.

I am calling

documentViewer.zoomToMouse(newZoomLevel, 0, 0, event);

However, this doesn’t work.

The documentation for zoomToMouse says “Adjusts the viewer’s zoom factor and positions the point on the document under the mouse at the same position after zooming in.”

Clearly that isn’t happening.

So, what am I doing wrong?

Hello, I’m AiRon, an automated tech support bot :robot:
While you wait for one of our customer support representatives, I can help you with your question.


It seems like you’re trying to implement a zoom feature where the document remains centered on the mouse cursor when you use the scroll wheel. The zoomToMouse function is designed for this purpose, but it requires precise handling of events and parameters to work correctly.

Some things you can try:

  • Ensure that you’re correctly calculating the new zoom level. The zoomToMouse function requires a zoom level, so make sure it’s being updated appropriately based on the scroll event.

  • Double-check that the event parameter passed into zoomToMouse is the actual wheel event you’re capturing. This event should contain the mouse coordinates needed for the zoom operation.

  • Consider any transformations or scaling that might affect the coordinates. Even if there are no visible toolbars or offsets, there might be CSS or other transformations affecting the layout.

  • Verify that the documentViewer and its methods are properly initialized and that no other scripts are interfering with the zoom functionality.




Here are some resources that might help you:



Hopefully, this helps you solve your problem while you wait for a human to get back to you.

Hello @spamfilter ,

Thank you for posting on our forum.

If you have not already, please see our guide regarding calculating coordinates, as the offset values are referring to toolbars/headers in the viewers, not the scroll element. You can find the guide here: https://docs.apryse.com/web/guides/coordinates#viewer-page-coordinates

The coordinates may also need conversion from window to PDF using this method here: Apryse WebViewer Class: DisplayMode

To diagnose further we require the following information.

  1. Are you able to reproduce this issue on our latest release (Version 11.10)?
  2. Screenshots/demo video reproducing the issue, highlighting expected vs. actual behavior
  3. JavaScript console output showing all warnings and errors.
  4. Can you reproduce the issue using our samples (especially on our site)?
  5. Does the issue only occur in certain browsers and/or devices? If so what are the details?

Best Regards,
Jacob Romano Carlsen
Web Development Support Engineer
Apryse Software Inc.

Yes, still happens in 11.10.0

The zoomToMouse API doc says “Adjusts the viewer’s zoom factor and positions the point on the document under the mouse at the same position after zooming in.” - that suggests I do not need to worry about any PDF/page coordinates as the method is supposed to handle that.

I have been referencing the previous discussion on this topic here: Can I zoom based on mousewheel only events, and not ctrl + mousewheel event? - #6 by Andrew_Yip

I am attaching the wheel event handler to documentViewer.getScrollViewElement()

To get the offsets, I get the bounding rect for the scroll element and then the zoomToMouse call becomes…

const svr = documentViewer.getScrollViewElement().getBoundingClientRect();
documentViewer.zoomToMouse(newZoomLevel, svr.left, svr.top, event);

However, it’s close, but it doesn’t work. Here’s a video:

You can see that the first two turns of the wheel result in jumps, as do the last two in the reverse direction.

This happens in latest Firefox & Safari on latest OSX Sequoia.

The .DocumentContainer has overflow:hidden applied.