PDF Viewer: Scroll-to-position

💬 Feature Requests
1

I am building an app with an interface that has, on one side, an editable table of data and, on the right side, a PDF containing the source document which the data was extracted from.

I would like the ability to control the "viewport" of the PDF viewer so that as the user interacts with different rows in the table, they see the corresponding portion of the PDF to confirm that the data was extracted correctly -- or edit it if it is incorrect.

At this time, there does not seem to be a way to tell the PDF component in Retool to scroll to a specific location or region within a document using some or all combinations of variables such as:

  • Page
  • Vertical scroll position
  • Horizontal scroll position
  • Zoom level
  • (X,Y) coordinates for a specific region

If anyone is aware of a way to implement this functionality today, I'd love to connect!

3 Likes
2

Hello @ijs0,

Great feature request, I love the idea. It will make the PDF component much more useful.

I can make a feature request for this and keep you updated on any news I hear from the engineering team!

It will be interesting thinking about how to map the viewport to the editable table of data on the side that you have :thinking:

3

Ah, that's "easy" -- since this is an interface for confirming the accuracy of already-extracted data, we already know where to look in document for each bit of information and that would be stored in a DB.

Interactions like mousing over a table row or clicking on a text field in the row to edit a value would update the viewport to the region we identified as the source location. ... Or some variation of this, like we navigate to the source page and display a highlighted annotation around the region,

2 Likes
4

We could create a similar experience by just displaying a list of those "source regions" as images and putting and populating the right form UI next to it, but:

  1. This can appear quite messy.
  2. The user doesn't have access to the source doc and the context they may need to correctly confirm the info.
5

Ah yes I see, using multiple images for "source regions/areas" was going to be my next bet for a short term solution while we wait on the engineering team to go through this feature request, but as you described that could get messy/complicated.

Once the PDF component has an interface it should not be to tricky as all to build a UI for the users that will travel with them through the document.

Will keep you posted on developments from our eng team!

2 Likes