Simplest way to set the exact position/offset of a page within the scroll view?

Technical Support WebViewer
1

WebViewer Version: 11.7

Do you have an issue with a specific file(s)? No
Can you reproduce using one of our samples or online demos? No
Are you using the WebViewer server? Yes
Does the issue only happen on certain browsers? No
Is your issue related to a front-end framework? Maybe
Is your issue related to annotations? No

Please give a brief summary of your issue:
(Think of this as an email subject)

I would like to control the exact position of a page within the scroll view - what is the most straightforward way to do this?

Please describe your issue and provide steps to reproduce it:
(The more descriptive your answer, the faster we are able to help you)

Hi, we are building a custom UI and would like to set the position and zoom level of a PDF page exactly within the viewer/relative to the scroll view.

Imagine, for example, implementing a custom Pan tool, or for saving and restoring specific views of a document. We are only interested in doing this for page 1.

What would be the best way to do this?

I see the zoomTo method, which works for zooming but does not seem to position the page. For example, when the page is much smaller than the scroll view, it won’t move away from the top left no matter what I provide for the x & y arguments.

I also see jumpToAnnotation, but cannot see how to use this to precisely control the position of the page.

There is the actual Pan Tool of course, but I can’t see how to control it programmatically.

At the moment it seems the best approach is to create a custom Display Mode, and then I can control the page and sections directly (perhaps adding an offset to the getPageOffset function?). Is this really the best way? If I do this, do I need to do anything else to avoid breaking the rendering?

Sj

1 Like
Calculating offsets with zoomToMouse
2

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.


To control the exact position and zoom level of a PDF page in Apryse’s WebViewer, particularly for implementing custom features like a Pan tool or saving specific views, you can use a combination of methods. The key is to manipulate the scroll position and zoom level of the document viewer to achieve your desired view.

Some things you can try:

  • Use the instance.docViewer.getScrollViewElement() method to access the scrollable element of the document viewer. You can then set the scroll position using JavaScript.

  • Utilize the instance.setZoomLevel() method to set the zoom level of the viewer.

  • For precise positioning, calculate the scroll position based on the current zoom level and the desired page coordinates.

  • If you want to save and restore views, store the current scroll position and zoom level, then apply them when needed.



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.

1 Like
3

I have found if I set the transform of the viewer (element returned from getViewerElement()) then this appears close to what we want. It is behaving slightly strangely at some edges but that might be how I have the styles set up!

If I am able to sort my CSS out, is it acceptable to move this element via Js? Should it be done, for example, inside a specific callback, or, do I need to tell the renderer that it has moved?

1 Like
4

If I am able to sort my CSS out, is it acceptable to move this element via Js?

It seems the answer is no because when I set the position this way and zoom in, it is clear only some parts of the PDF are re-rendered at high resolution, and others use the scaled up raster…

1 Like
5

Hello @sfriston,

Thank you for posting on our forum.

We are currently investigating your query and we will reach out to you when we have an update.

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

2 Likes
6

Hello @sfriston,

Thank you for your patience.

You are correct; you can modify the position off the viewer element within the scroll view, but this would not affect how our rendering functions, which would be based off of the original position of the viewer element.

We would definitely recommend creating a custom DisplayMode for this type of workflow to help orient where the “expected view” of the pages are. In the forum post linked, you may have noticed the setCustomFunctions() API. This API will allow you to override some of the helper functions for determining the current visible pages, the current offset of the viewer, etc. You can find the API doc for this here: https://sdk.apryse.com/api/web/Core.DisplayMode.html#setCustomFunctions

It may also be worthwhile to set the range of pages that are pre-rendered with setPreRenderLevel(). You can find the API doc here: https://sdk.apryse.com/api/web/Core.html#.setPreRenderLevel
If you are curious as to how our rendering functions, see our guide here: https://docs.apryse.com/web/guides/events/loading-events#document-and-annotation-rendering.

Let us know if you have any further questions or need further clarification.

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

1 Like
7

Hi @jromanocarlsen,

Thanks for your reply, I have created a Custom Display Mode as suggested.

This is working & is almost perfect, but there is one problem remaining: when we zoom, e.g. with zoomTo, the document flickers, instead of scaling smoothly.

(By flicker, I mean the viewer flashes white for a frame or two, as if everything inside it has been deleted.)

It is due to the custom display mode, because if I do not call setDisplayMode and instead just set up a wheel event listener and call zoomTo or zoomToMouse, leaving everything else unchanged, zooming is smooth.

I am fairly sure what is happening, is that with our custom display mode, the page elements are deleted, then the browser renders the DOM with nothing in it for a frame or two, before createPageSections is called to build replacements at the new zoom level. With the default mode, the existing elements/content is scaled up as a placeholder until the new ones are ready.

Looking at the standard UI source, it seems this just calls DocumentViewer.zoomTo/zoomToMouse directly. Additionally, if I create a Mutation Observer, I can see the default display mode makes more style updates before swapping the elements are swapped.

I’d conclude then that scaling the existing content temporarily is a behaviour of the DisplayMode and not DocumentViewer?

Another thing I have noticed is that by the time createPageSections is called, the existing elements have already been deleted, through I cannot tell from where.

I presume then, the right approach is to manually copy the page elements somewhere before they can be deleted, scale them up temporarily, and then delete them in createPageSections when the new ones are ready(*). Is this on the right track?

*This assumes the canvases are ready by this point…

1 Like
8

Hello @sfriston,

Thank you for the update.

Would you be able to provide a minimal runnable sample of your implementation so far and we can investigate further?

  • A minimal runnable sample is bare-bones version application with all excess code removed other than the absolute minimum required to reproduce the issue consistently. For references, you can find our sample projects here: https://dev.apryse.com/

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

1 Like
9

Hi @jromanocarlsen,

We have managed to get the desired behaviour using the above approach. Before we call zoom, the page section is added to a new element that draws over the viewer element, and scaled & positioned to where the new render will be. Then we call zoom, and in pageComplete, delete our placeholder, leaving the new one visible to the user.

I don’t believe this is what the inbuilt Display Mode does, because the Mutation Observer doesn’t show the change of parent.

However, it performs well for us, and to the user is indistinguishable, so we are happy!

If you don’t think we need to do this, I can still try to create a MWE when this feature is complete.

Kind regards,

Sj

2 Likes
10

Hello @sfriston,

Thank you for the update, happy to hear you found a solution that worked for you! We appreciate providing the details of your solution.

If you have any other questions regarding this issue, feel free to reach out.

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

1 Like