Rotation for snapToNearest?

Technical Support WebViewer
, , ,
1

WebViewer Version: 12.1.0

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? No
Does the issue only happen on certain browsers? No
Is your issue related to a front-end framework? No
Is your issue related to annotations? No

Please give a brief summary of your issue: snapToNearest works with viewer coordinates for pages with a rotation of 0, but not with a rotation of 90.

Please describe your issue and provide steps to reproduce it:

We are using a custom Display Mode. This is working well in all cases, except when trying to use snapToNearest with rotated pages.

Our implementation passes Viewer coordinates to snapToNearest, which works for pages with a rotation of 0, but not 90 (the snapping results are sensible with non-rotated pages, but with rotated pages the snapped locations don’t appear to register near any features).

Here is my current understanding:

  1. The viewer has three coordinate systems: PDF, Viewer and Window.

  2. Pdf is the native coordinate system of the Pdf page itself & is what the content is defined in.

  3. Viewer is the coordinate system local to the pageContainer div created in createPageSection, where 0,0 is always the top left of the rotated page.

  4. Window is the coordinate system of the contents of the scroll view.

  5. ‘page’ in windowToPage and pageToWindow of the display mode’s Custom Functions refers to Viewer page coordinates.

  6. getPDFCoordinates operates on viewer coordinates as well.

The documentation for snapToNearest ( Apryse WebViewer Class: DocumentViewer ) does not state which coordinate system the x and y coordinates are in, however I am observing two things that don’t make sense with regards to the above:

  1. If I pass viewer coordinates into snapToNearest for non-rotated pages, it works.

  2. If I pass different viewer coordinates to getPDFCoordinates it appears as though the origin of the PDF page is in the centre of the viewer coordinate system, not the bottom-left like this page suggests it should be.

What should we do to viewer coordinates to make them work with snapToNearest for all page rotations?

Do we need to rotate them ourselves explicitly for example, or is there an API that should be used?

1 Like
2

Hello Sebastian,

Thank you for contacting Apryse forums.

I’m looking into this issue and I’ll update here when I have more information.

Best Regards,

Darian

2 Likes
3

Hello Sebastion,

Could you try not reading the raw offsets off pageContainer? Instead, convert this using displayMode.windowToPage() (which already does the correct zoom+rotation inversion) to get real Viewer coordinates, then pass those to snapToNearest.

const displayMode = documentViewer.getDisplayModeManager().getDisplayMode();
const windowPt = tool.getMouseLocation(event); // window coordinates
const pagePt = displayMode.windowToPage(windowPt, pageNumber); // correct Viewer coordinates, any rotation
documentViewer.snapToNearest(pageNumber, pagePt.x, pagePt.y, snapMode);

Best Regards,
Darian

1 Like
4

Hi Darian,

I have tried to implement that. I wasn’t sure what to use for tool, so we have:

const docViewer = documentViewer.current;const pageNumber = 1;
const displayMode = docViewer.getDisplayModeManager().getDisplayMode();
const windowPt = docViewer.getToolModeMap().TextSelect.getMouseLocation(event);
const pagePt = displayMode.windowToPage(windowPt, pageNumber);
snappingTask.current = docViewer.snapToNearest(pageNumber, pagePt.x, pagePt.y, snapModes.current)

Unfortunately it still doesn’t work for rotated pages. A couple of observations:

  1. For non-rotated pages (where it works), pagePt is 0,0 at the top-left of the rendered content. My understanding is that this is wrong, because page coordinates should start at the bottom left for non-rotated pages.

  2. For rotated pages (where it doesn’t work), pagePt is still 0,0 at the top-left of the rendered content, suggesting windowToPage is not accounting for the rotations (or windowToPage means viewer page?).

  3. The window coordinates appear correct.

Could it be our custom functions? This is our windowToPage function that we pass to setCustomFunctions:

		windowToPage: function (windowPt, pageNumber) {
			const windowPosition = getDrawingPositionInWindow();

			const scaledPt = {
				x: windowPt.x - windowPosition.x,
				y: windowPt.y - windowPosition.y,
			};

			const zoom = docViewer.getZoomLevel();

			return {
				pageNumber,
				x: scaledPt.x / zoom,
				y: scaledPt.y / zoom,
			};
		},

As you see it does not account for rotations.

However, the rendering and navigation works otherwise for rotated and non-rotated pages, and it is not clear whether these are meant to handle rotations (e.g. getPageInfo provides information for pre-rotated pages…)/we have not seen any examples that do so.