akira/pdfjs-dist - pdfjs-dist - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Jonas Jenwald	fce2cfddcf	Check if `pageView.pdfPage` exists in `PDFViewer._ensurePdfPageLoaded`, to avoid potentially calling `PDFPageView.setPdfPage` multiple times for the same page Since calling `PDFPageView.setPdfPage` will in turn call `PDFPageView.reset`, which cancels all rendering and completely resets the page, it's thus possible that we currently cause some unnecessary re-rendering during the initial loading phase of the viewer. Depending on the order in which data arrives, it's possible (and in practice always seem to happen) that the `pdfPage` property of the second page has already been set during `PDFViewer.setDocument`, by the time that the request for the `pdfPage` is resolved in `PDFViewer._ensurePdfPageLoaded`. Also, note how the `setPdfPage` call in `PDFViewer.setDocument` is already guarded by this kind of check.	8 years ago
Jonas Jenwald	b0a4f6de8f	Use `createPromiseCapability` in `/web` files In various viewer files, there's a number of cases where we basically duplicate the functionality of `createPromiseCapability` manually. As far as I can tell, a couple of these cases have existed for a very long time, and notable even before the `createPromiseCapability` utility function existed. Also, since we can write ES6 code now, the patch also replaces a couple of `bind` usages with arrow functions in code that's touched in the patch.	8 years ago
Yury Delendik	8e681ce3e2	Change amd to cjs path in ES6 modules	8 years ago
Jonas Jenwald	b2c3f8f081	Convert a number of `import * as pdfjsLib from 'pdfjs-web/pdfjs';` cases to only specify the necessary imports Rather than always importing everything from the `web/pdfjs.js`, similar to all other imports we can just choose what we actually need.	8 years ago
Jonas Jenwald	3b35c15d42	Convert the files in the `/web` folder to ES6 modules Note that as discussed on IRC, this makes the viewer slightly slower to load only in `gulp server` mode, however the difference seem slight enough that I think it will be fine.	8 years ago
Rob Wu	ece44d36e8	Allow automatic print rotation via enablePrintAutoRotate	8 years ago
Rob Wu	775441b7c6	Refactor: configurable page rotation in print job Determine the page rotation at the same place as where the page size is determined. This allows us to implement custom print page rotation logic in one place, in the future.	8 years ago
Jonas Jenwald	4046d67fde	Enable the `no-else-return` ESLint rule Using `else` after `return` is not necessary, and can often lead to unnecessarily cluttered code. By using the `no-else-return` rule in ESLint we can avoid this pattern, see http://eslint.org/docs/rules/no-else-return.	8 years ago
Yury Delendik	f7d6f3a739	Adds SVG rendering capabilities to the PDFViewer.	9 years ago
Jonas Jenwald	efb9619e53	Add PageLabels to `PDFPageView` and `PDFThumbnailView`	9 years ago
Jonas Jenwald	f461fd64aa	Add support for PageLabels in the viewer This patch implements the page label functionality in a similar way as Adobe Reader. For documents with page labels, if a non-existent page label is entered we'll try to fallback to the page number instead. The patch also includes a preference (`disablePageLabels`), to make it easy to opt-out of using page labels if the user/implementor so wishes. The way that `get/set currentPageLabel` is implemented in `PDFViewer`, is as wrappers for the corresponding `get/set currentPageNumber` functions, since that seemed like the cleanest solution. The page labels are purposely only added to the page controls in the viewer UI, and not stored in e.g. the `ViewHistory`. Since doing so would mean adding unnecessary code complexity, without any real added value, and would also mean delaying the inital loading of PDF documents. Note that this patch will ignore page labels if they are identical to standard page numbering, since in this case displaying the page labels adds no value (but only UI noise). The reason for handling this case specially, is that in practice a surprising number of PDF files include "pointless" page labels.	9 years ago
Jonas Jenwald	2ce9da9b7a	Fix a couple of JSDoc `@typedef`s to use `@property` (instead of `@param`) to fix some missing documentation when running `gulp jsdoc`	9 years ago
Yury Delendik	0576c9c6c6	Replaces all preprocessor directives with PDFJSDev calls.	9 years ago
Jonas Jenwald	a824c6c4f6	Ensure that any pending rendering operations in `PDFViewer`/`PDFThumbnailViewer` are cancelled when the viewer is closed	9 years ago
Yury Delendik	24a7a58da7	Moves mozPrintCallback specific code to firefox_printservice.js	9 years ago
Tim van der Meij	2da2c45889	Interactive forms: remove global PDFJS usage	9 years ago
Jeremy Press	6faa84abdb	Continuing fairexpand #6663 1. Expanding divs to improve text selection. (Yury) 2. Adding enhanceTextSelection as an option. 3. Moving feature functionality from text_layer_builder.js to text_layer.js. 4. Added expandTextDivs method to only load expanded divs on first click, and only show on subsequent clicks	9 years ago
Jonas Jenwald	31cd23a6df	Remove an obsolete comment for `onAfterDraw` in pdf_viewer.js With the viewer code now being split into various components/files, having an obsolete comment in `PDFViewer` that references thumbnails despite there being no other mentions of them in the entire file seems strange. Note: This comment is simply a left-over from older versions of PDF.js, where the entire default viewer code was placed in just one file (and where we unconditionally created thumbnails, regardless whether they were visible or not).	9 years ago
Jonas Jenwald	076e25f1ca	Prevent destinations with bad left/top values from scrolling the wrong page into view (bug 874482) There are PDF generators which create destinations with e.g. too large top values, which cause the wrong page to be scrolled into view because the offset becomes negative. By ignoring negative offsets, we can prevent this issue, and get a similar behaviour as in Adobe Reader. However, since we're also using `PDFViewer_scrollPageIntoView` in more cases than just when links (in the document/outline) are clicked, the patch adds a way to allow the caller to opt-out of this behaviour. In e.g. the following situations, I think that we still want to be able to allow negative offsets: when restoring a position from the `ViewHistory`, when the `viewBookmark` button is used to obtain a link to the current position, or when maintaining the current position on zooming. Rather than adding another parameter to `PDFViewer_scrollPageIntoView`, I've changed the signature to take an parameter object instead. To maintain backwards compatibility, I've added fallback code enclosed in a `GENERIC` preprocessor tag. Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=874482.	9 years ago
Xiliang Chen	6cb77d6580	fix outline may jump to previous page issue	9 years ago
Jonas Jenwald	7706cfa9fe	Log an error when the value passed to `set currentPageNumber` is out of bounds (PR 7502 followup) With PR 7502 we no longer dispatch an event when the `val` is out of bounds, so to better communicate why nothing happens this patch logs an error in that case (similar to the logging of errors when trying to set an invalid scale). The way that the default viewer is currently implemented, means that e.g. keyboard short-cuts could trigger the new error. Hence this patch also adds the necessary validation code, both to `app.js` and `pdf_link_service.js` to prevent unnecessary errors.	9 years ago
Jonas Jenwald	50aeb00adf	Add validation of the `rotation` argument passed to `set pagesRotation` in `PDFViewer` Similar to the validation done when setting page/scale.	9 years ago
Jonas Jenwald	b7cb44af88	Remove the `previousPageNumber` parameter from the `pagechanging`/pagechange` events, and stop dispatching the events if the input is out of bounds This patch attempts to cleanup a couple of things: - Remove the `previousPageNumber` paramater. Prior to PR 7289, when the events were dispatched even when the active page didn't change, it made sense to be able to detect that in an event listener. However, now that's no longer the case, and furthermore other similar events (e.g. `scalechanging`/`scalechange`) don't include information about the previous state. - Don't dispatch the events when the value passed to `set currentPageNumber` is out of bounds. Given that the active page doesn't change in this case, again similar to PR 7289, I don't think that the events should actually be dispatched in this case. - Ensure that the value passed to `set currentPageNumber` is actually an integer, to avoid any issues (note how e.g. `set currentScale` has similar validation code). Given that these changes could possibly affect the PDF.js `mochitest` integration tests in mozilla-central, in particular https://dxr.mozilla.org/mozilla-central/source/browser/extensions/pdfjs/test/browser_pdfjs_navigation.js, I ran the tests locally with this patch applied to ensure that they still pass.	9 years ago
Jonas Jenwald	f297e4d17c	[api-minor] Add a parameter to `PDFPageProxy_getTextContent` that controls whether `PartialEvaluator_getTextContent` will attempt to combine same line text items From the discussion in issue 7445, it seems that there may be cases where an API consumer would want to get the text content as is, without combined text items.	9 years ago
Jonas Jenwald	9f34700e0d	Ensure that we don't reset the current page view if the user inputs an invalid page number (PR 7289 follow-up) After PR 7289, we'll now reset the current page view in cases where I don't think we should. To avoid this, this patch ensures that we'll not modify the position when the page number is out-of-bounds. STR: 1. Open http://mozilla.github.io/pdf.js/web/viewer.html#page=1&zoom=auto,-98,696 2. Enter an invalid number, e.g. `1000`, in the `pageNumber` input. ER: The current position in the document shouldn't change, since the page number wasn't valid. AR: The document resets to the top of the page `1`.	9 years ago
Jonas Jenwald	dd0fe10a52	Consolidate updating of various Toolbar state (e.g. page and scale) in one method in `PDFViewerApplication` With the changes in PR 7289, we no longer dispatch a 'pagechanging' event on load. Since most PDF documents open on the first page, this means that the `previous` and `firstPage` buttons are no longer correctly disabled. To avoid this, this patch moves the code that updates various UI toolbar state into one method, which is then called on document initialization and from the various existing event handling functions.	9 years ago
Jonas Jenwald	b354682dd6	[api-minor] Let `LinkAnnotation`/`PDFLinkService_getDestinationHash` return a stringified version of the destination array for explicit destinations Currently for explicit destinations, compared to named destinations, we manually try to build a hash that often times is a quite poor representation of the actual destination. (Currently this only, kind of, works for `\XYZ` destinations.) For PDF files using explicit destinations, this can make it difficult/impossible to obtain a link to a specific section of the document through the URL. Note that in practice most PDF files, especially newer ones, use named destinations and these are thus unnaffected by this patch. This patch also fixes an existing issue in `PDFLinkService_getDestinationHash`, where a named destination consisting of only a number would not be handled correctly. With the added, and already existing, type checks in place for destinations, I really don't think that this patch exposes any "sensitive" internal destination code not already accessible through normal hash parameters. Please note: Just trying to improve the algorithm that generates the hash is unfortunately not possible in general, since there are a number of cases where it will simply never work well. - First of all, note that `getDestinationHash` currently relies on the `_pagesRefCache`, hence it's possible that the hash returned is empty during e.g. ranged/streamed loading of a PDF file. - Second of all, the currently computed hash is actually dependent on the document rotation. With named destinations, the fetched internal destination array is rotational invariant (as it should be), but this will not hold in general for the hash. We can easily avoid this issue by using a stringified destination array. - Third of all, note that according to the PDF specification[1], `GoToR` destinations may actually contain explicit destination arrays. Since we cannot really construct a hash in `annotation.js`, we currently have no good way to support those. Even though this case seems very rare in practice (I've not actually seen such a PDF file), it's in the specification, and this patch allows us to support that for "free". --- [1] http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G11.1951685	9 years ago
Yury Delendik	9f68e3f1bc	Disable pagechange event if page is not changing.	9 years ago
Yury Delendik	4a2c76a34f	Adds pre and post UI control change events.	9 years ago
Yury Delendik	7fd3db9977	Adds EventBus.	9 years ago
Yury Delendik	4165cedc9f	Replace pdfjsLib with module that represents pdf.js.	9 years ago
Yury Delendik	006e8fb59d	Introduces UMD headers to the web/ folder.	9 years ago
Yury Delendik	1e3e14e6b2	Exposes all functional members via lib exports and use them in viewer.	9 years ago
Tim van der Meij	6a33dfd13a	Implement support for FileAttachment annotations	9 years ago
Jonas Jenwald	3079dd937f	Remove a superfluous "s" in `AnnotationsLayerBuilder` from files in web/ This patch makes the naming consistent with the `TextLayerBuilder`, and also the new `AnnotationLayer`, and should thus help reduce possible confusion when working with the code. Please note that the files were renamed using `git mv`, in order to preserve blame.	9 years ago
Jonas Jenwald	6dfe53b976	[api-minor] Add a parameter to `PDFPageProxy_getTextContent` that enables replacing of all whitespace with standard spaces in the textLayer (issue 6612) This patch goes a bit further than issue 6612 requires, and replaces all kinds of whitespace with standard spaces. When testing this locally, it actually seemed to slightly improve two existing test-cases (`tracemonkey-text` and `taro-text`). Fixes 6612.	10 years ago
Manas	a2ba1b8189	Uses editorconfig to maintain consistent coding styles Removes the following as they unnecessary /* -- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -- / / vim: set shiftwidth=2 tabstop=2 autoindent cindent expandtab: */	10 years ago
Tony Jin	570f144fc3	Fix minor capitalization issue in viewer	10 years ago
Jonas Jenwald	e629882f2a	Correctly handle /FitH destinations with `null` as the parameter According to http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf#G11.2095870, the vertical position shouldn't change if the parameter is `null`. Fixes 6615.	10 years ago
Xiliang Chen	a059f9fcbb	Fix exception when rotate page without a document	10 years ago
Jonas Jenwald	93d82e21d5	Move handling of the 'custom' scale value from pdf_viewer.js to viewer.js The special handling of the 'custom' scale value is only relevant for the `scaleSelect` dropdown in the standard viewer, hence I think that it should be placed in `viewer.js` instead.	10 years ago
Jonas Jenwald	d0c071a40d	Prevent re-rendering of pages because of rounding errors when computing the scale value Currently if the zoom level is reset multiple times in a row, i.e. by pressing <kbd>Ctrl</kbd>+<kbd>0</kbd>, the pages can be re-rendered each time even though their size shouldn't change. Whether this happens can depend on the size of the viewer, but documents with pages in landscape mode seem to be very susceptible to this. (An example is: https://wiki.mozilla.org/images/5/55/MobileOpportunity.pdf.) This can also effect documents with pages in portrait mode, when they are displayed in Presentation Mode. The reason for this unnecessary re-rendering is that due to limited numerical precision, the new scale value may change in only the last decimal place.	10 years ago
Jonas Jenwald	4364b37e55	Simplify the SimpleLinkService and use it to pass in a linkService instance in DefaultAnnotationsLayerFactory Considering that most methods of `SimpleLinkService` are complete stubs, or practically "useless" considering what they return, we can actually simplify it even more. Note: This depends on the previous patch, that did a small amount of refactoring of `PDFViewer_scrollPageIntoView`, since `PDFViewer.linkService.page` is no longer accessed. ---------- Currently the `pageviewer` components example doesn't work correctly (an error is printed in the console), since no `linkService` is present when the `AnnotationsLayerBuilder` is created. Note: Given that this uses the `SimpleLinkService`, clicking on e.g. internal links won't actually do anything. However, given that internal links (and similar features) are pretty much useless when only one page is loaded the `pageviewer` example, I don't think that really matters. Also, using the complete `PDFLinkService` would require a `PDFViewer` instance. That would significantly complicate the example, thus making it both less clear and less self contained.	10 years ago
Jonas Jenwald	ac3233bfa4	Use "private" properties in PDFViewer_scrollPageIntoView Currently in `PDFViewer_scrollPageIntoView`, we're accessing a number of properties in an indirect and overly complicated way. In particular, using `this.linkService.page` is a very roundabout way to access `this.currentPageNumber`. The reason for this appears to be entirely historical, since prior to PR 5361 the code was placed in `PDFPageView` (or `PageView` as it was called at the time).	10 years ago
Yury Delendik	1b847df2f3	Using pdfjs-dist as a library for b2g viewer.	10 years ago
Jonas Jenwald	d940078d95	Make sure that the document is rendered on zooming and rotation for `PDFViewer` instances using the `defaultRenderingQueue` In `viewer.js` we have code that ensures that the document is re-rendered on zooming and rotation. However, for `components` based viewers this might not work correctly, since there's currently no code which handles that. Note that there is a good chance that this "just works" in many `components` viewers already, thanks to the `watchScroll` function. The explanation is that zooming or rotation, most of the time, causes the viewer to change its (scrollable) size, thus triggering `PDFViewer_update` through `PDFViewer_scrollUpdate`. However, in general there's no guarantee that this will actually work (since zooming and rotation doesn't necessarily change the size of the viewer for all documents), and requiring every viewer `components` implementer to provide methods for this doesn't seem like a great idea.	10 years ago
Jonas Jenwald	ffeba9c630	Move the page switching code into `set currentPageNumber` in `PDFViewer` instead of placing it in the `pagechange` event handler The reason that this code can be moved is that the `if (this.loading && page === 1)` check, in the `pagechange` event handler in viewer.js, is never satisfied since `this.loading` is not defined in that scope. This could be considered a regression from PR 5295, since prior to that `this.loading` was using the `PDFViewerApplication` scope (or `PDFView` as it were). However, I don't think that we need to fix that since we've been shipping this code in no less than three Firefox releases (uplifted in https://bugzilla.mozilla.org/show_bug.cgi?id=1084158), without breaking the world. An explanation of why the `pagechange` code works, despite `this.loading === undefined`, is that `set currentPageNumber` (in `PDFViewer`) returns early whenever `this.pdfDocument` isn't set. This check is, for all intents and purposes, functionally equivalent to checking `PDFViewerApplication.loading`. Hence we can move the page switching code into `PDFViewer`, and also remove `PDFViewerApplication.loading` since it's not used any more. (The `this.loading` property was added in PR 686, which was before the current viewer even existed.) Note: The changes in this patch should also be beneficial to the viewer `components`, since requiring every implementer to provide their own `pagechange` event handler just to get `PDFViewer.currentPageNumber` to actually work seems like an unnecessary complication.	10 years ago
Yury Delendik	0ef6212b64	Refactors PDFLinkService. # Conflicts: # web/viewer.js	10 years ago
Jonas Jenwald	ba0eb7fdc6	Add the \|location\| to the \|updateviewarea\| UI event This patch addresses an issue I stumbled upon while working on rewriting the history implementation. Currently the `updateviewarea` UI event doesn't include the `location`, and in the event handler in viewer.js we instead reach into `PDFViewer` to retrieve it. Not only does this seem conceptually wrong, it also makes the `updateviewarea` event less useful in general since it's currently only possible to access the `location` if you have a reference to the `PDFViewer`. To me, this simply appears to be an oversight in the implementation, hence this patch which adds `location` to the `updateviewarea` event. It also changes `location` to be a "private" property of `PDFViewer`.	10 years ago
Jonas Jenwald	b1c4b85d4f	Change \|pages\| to be a "private" property of \|PDFViewer\| As suggested by yurydelendik: http://logs.glob.uno/?c=mozilla%23pdfjs&s=30+Sep+2014&e=30+Sep+2014&h=4150#c26119, this patch renames `pages` -> `_pages` to indicate that it's a "private" property. Accessing pages from outside `PDFViewer` should instead be done by using `getPageView`.	10 years ago

1 2