ReaderControl provides the UI for many features, for example: searching, thumbnails, tool switching, annotation list and more. The
ReaderControl code is completely unminified and doesn't have any privileged access to the core WebViewer APIs.
When using the
PDFTron.WebViewer constructor to load a document the ReaderControl.html file is loaded inside an iframe. It loads ReaderControl.js (and a few other scripts) which construct the default WebViewer UI.
Since the code is unminified you have the option to change it as you like (though we recommend starting with config files).
However this also means that you have the option of creating your own viewer based on the core WebViewer APIs.
DocumentViewer expects elements to exist for each page of the form
X is the page index of the page. When updateView is called, DocumentViewer will render the visible pages and append them to corresponding pageContainer elements.
DocumentViewer handles the management of page rendering (caching pages, cancelling requests, etc) but if you want more control you can use an even lower level API to render pages.
The loadCanvasAsync function on Document allows you to pass in a page index and it will give you back a canvas with the page rendered on it. This sample uses the loadCanvasAsync technique to allow WebViewer to integrate with the deck.js library.
Don't feel constrained by the implementation of ReaderControl when integrating WebViewer into your own app. ReaderControl is an example of the kinds of things you can do with the WebViewer API but it isn't the limit.
If it makes sense in your situation, try customizing ReaderControl or just use it as a reference for your own viewer implementation. We'll be happy to help if you have any questions.