Commit Graph

11 Commits

Author SHA1 Message Date
Jonas Jenwald
ef8e5fd77c Convert PDFDocumentLoadingTask, in src/display/api.js, to an ES6 class
Also deprecates the `then` method, in favour of the `promise` getter.
2018-11-18 19:07:57 +01:00
Jonas Jenwald
e2e9657ed0 Remove the attachDOMEventsToEventBus functionality, since EventBus instances are able to re-dispatch events to the DOM (PR 10019, bug 1492849 follow-up)
This also removes the old 'pagechange'/'scalechange'/'documentload' events.
2018-10-31 23:32:39 +01:00
Jonas Jenwald
2ed3591b22 Make PDFFindController less confusing to use, by allowing searching to start when setDocument is called
*This patch is based on something that I noticed while working on PR 10126.*

The recent re-factoring of `PDFFindController` brought many improvements, among those the fact that access to `BaseViewer` is no longer required. However, with these changes there's one thing which now strikes me as not particularly user-friendly[1]: The fact that in order for searching to actually work, `PDFFindController.setDocument` must be called *and* a 'pagesinit' event must be dispatched (from somewhere).

For all other viewer components, calling the `setDocument` method[2] is enough in order for the component to actually be usable.
The `PDFFindController` thus stands out quite a bit, and it also becomes difficult to work with in any sort of custom implementation. For example: Imagine someone trying to use `PDFFindController` separately from the viewer[3], which *should* now be relatively simple given the re-factoring, and thus having to (somehow) figure out that they'll also need to manually dispatch a 'pagesinit' event for searching to work.

Note that the above even affects the unit-tests, where an out-of-place 'pagesinit' event is being used.
To attempt to address these problems, I'm thus suggesting that *only* `setDocument` should be used to indicate that searching may start. For the default viewer and/or the viewer components, `BaseViewer.setDocument` will now call `PDFFindController.setDocument` when the document is ready, thus requiring no outside configuration anymore[4]. For custom implementation, and the unit-tests, it's now as simple as just calling `PDFFindController.setDocument` to allow searching to start.

---
[1] I should have caught this during review of PR 10099, but unfortunately it's sometimes not until you actually work with the code in question that things like these become clear.

[2] Assuming, obviously, that the viewer component in question actually implements such a method :-)

[3] There's even a very recent issue, filed by someone trying to do just that.

[4] Short of providing a `PDFFindController` instance when creating a `BaseViewer` instance, of course.
2018-10-04 10:28:50 +02:00
Tim van der Meij
f79fb88864
Remove the find controller setter in web/base_viewer.js
With `PDFFindController` instances no longer (directly) depending on
`BaseViewer` instances, we can pass a single `findController` when
initializing a viewer, similar to other components.
2018-09-30 16:59:58 +02:00
Tim van der Meij
e0c811f2ed
Use the link service for getting and setting page information
This removes the dependency on a `PDFViewer` instance from the find
controller, which makes it more similar to other components and makes it
easier to unit test with a mock link service.

Finally, we remove the search capabilities from the SVG example since it
doesn't work there because there is no separate text layer.
2018-09-30 16:59:46 +02:00
Tim van der Meij
e293c12afc
Implement the setDocument method for the find controller
Now it follows the same pattern as e.g., the document properties
component, which allows us to have one instance of the find controller
and set a new document to search upon switching documents.

Moreover, this allows us to get rid of the dependency on `pdfViewer` in
order to fetch the text content for a page. This is working towards
getting rid of the `pdfViewer` dependency upon initializing the
component entirely in future commits.

Finally, we make the `reset` method private since it's not supposed to
be used from the outside anymore now that `setDocument` takes care of
this, similar to other components.
2018-09-30 16:57:40 +02:00
Brendan Dahl
01bff1a81d Rename the globals to shorter names.
pdfjsDistBuildPdf=pdfjsLib
pdfjsDistWebPdfViewer=pdfjsViewer
pdfjsDistBuildPdfWorker=pdfjsWorker
2018-03-16 11:08:56 -07:00
Jonas Jenwald
b8606abbc1 [api-major] Completely remove the global PDFJS object 2018-03-01 18:13:27 +01:00
Jonas Jenwald
3c2fbdffe6 Move the cMapUrl and cMapPacked options from the global PDFJS object and into getDocument instead 2018-03-01 18:11:16 +01:00
Jonas Jenwald
c3c1fc511d Move the workerSrc option from the global PDFJS object and into GlobalWorkerOptions instead 2018-02-16 13:22:35 +01:00
pixel
484ec3d09c Added component example for single page viewer
Checking for PDFJS.PDFSinglePageViewer instead

Added component example for single page viewer
2017-10-05 23:46:02 +05:30