Do NOT save the temporary <canvas> element as `this.canvas`.
`PDFViewer.pages[i].canvas` appears to be used to generate the thumbnail
icons. Well, that's no justification for preventing GC of those
temporary <canvas> elements used during mozPrintCallback.
With a document consisting of 79 pages, this resulted in a 600-700MB
leaked memory.
This shim does the following:
1. Intercept window.print()
2. For a window.print() call (if allowed, ie. no previous print job):
1. Dispatch the beforeprint event.
2. Render a printg progress dialog.
3. For each canvas, call mozPrintCallback if existent (one at a time, async).
4. During each mozPrintCallback callback, update the progress dialog.
5. When all <canvas>es have been rendered, invoke the real window.print().
6. Dispatch the afterprint event.
The shim is not included in Firefox through the preprocessor.
Keyboard shortcuts (Ctrl/Cmd + P) are intercepted and default behavior
(i.e. printing) is prevented, and the steps for window.print() are run.
window.attachEvent is used, in order to cancel printing in IE10 and
earlier (courtesy of Stack Overflow - http://stackoverflow.com/a/15302847).
Unfortunately, this doesn't work in IE11 - if Ctrl + P is used, the
print dialog will be shown twice: Once because of Ctrl + P, and again
when all pages have finished rendering.
This logic of this polyfill is not specific to PDF.js, so it can also
be used in other projects.
There's one additional modification in PDF.js's viewer.js: The printed
<canvas> element is wrapped in a <div>. This is needed, because Chrome
would otherwise print one canvas on two pages.
[PDFHistory] Prevent the history from skipping entries in certain edge cases, when specifying an initialBookmark in the hash parameters on document load
Before this commit there were two main issues:
- In small windows, the zoom controls visually floated above the page number
(e.g. 733px).
- In small windows, the (transparent) zoom container covered the go-to-page
input box, which prevented one from using the input field to quickly navigate
to a different page.
If focused element is a textarea, viewer should not process keyboard shortcuts (as it does with input and select elements) because while writing on a textarea, if you press k,p,l, or n, the viewer scrolls next/prev page and the letter is not added to the textarea (eg. in my case I had a viewer displaying a product specs in PDF and a "request a quote" form at it's right, the form had a textarea field and users complains that they couldn't write in it, after checking it, I've realized it was this particular issue and fixd it with the change I'm commiting.
The ArrayBuffer holding the data might be over-sized in case the
data length was not known during the transfer, e.g. when using a
Content-Encoding other than `identity` or when using a
Transfer-Encoding.
Only the view into the buffer has the correct length then, hence
always use the view directly when creating the blob URI for the
download, instead of the over-sized underlying buffer.
Closes GH-3627
Closes GH-3634
When <base href> is present, history.replaceState and
history.pushState behave inconsistent with relative URLs.
http://code.google.com/p/chromium/issues/detail?id=274024
Contrary to what one expect, passing '' as the URL parameter to
replaceState/pushState does not associate the currently active
URL with the history entry, but a path relative to <base href>.
To fix the issue, explicitly associate the current active URL
with the history's state.
pdfHandler-local.js references the isPdfDownloadable function from
pdfHandler.js, but the function didn't expect that the responseHeaders
property was absent. Added a check to prevent a runtime error when a
local file is displayed in a frame, and show local PDF files again.
Local files are rendered on the chrome-extension:-protocol. The previous
method of getting the PDF URL was incorrect, this has been fixed as well.
Move inline event handlers to viewer.js to comply with a
Content-Security-Policy where directive "unsafe-inline" is not set.
Change textarea.rows = <number of newlines> to
textarea.style.height = textarea.scrollHeight.
(The former is extremely unreliable; consider long lines...)
Two major issues:
1. Border/shadow around every page. Removed by adding "border:none".
2. Added "overflow:visible" (overrides "overflow:auto") in #viewContainer.
This solves two problems:
- It prevents scrollbars from appearing.
- Every "page" is automatically resized to fit on a printed page,
just like the Firefox.
To see what's wrong, here's a picture of how PDF.js rendered the pdf in
Chrome (using "Print to PDF" feature of Chrome):
https://robwu.nl/pdfjs/pdfjs-print-with-chromium-28.pdf
Successfully tested with Chrome 28 and Firefox 22.
Solves #3445
Declares the URL variable globally. If the feature is not
supported, the variable will still be declared, but have the
"undefined" value.
Supported by:
- Firefox 4
Firefox 21 in Web worker
- Chrome 8 (prefixed as webkitURL), 23+ unprefixed
Chrome 10 (prefixed as webkitURL) in Web Worker, 23+ unprefixed
- Opera 15
Opera 15 in Web Worker
- Internet Explorer 10
Internet Explorer 11 in Web Worker
- Safari 6 (prefixed as webkitURL)
Safari 6 (prefixed as webkitURL) in Web Worker
This feature relies on URL.createObjectURL, which is supported by
- Firefox 4
- Chrome 8
- Opera 15
- Internet Explorer 10
If the feature is missing, it falls back to downloading from the server.
The environment-specific code are put in ifdef's. Two methods are
defined:
- noData
This function is used as a fallback in case of failure, it triggers
a download directly from the server.
- triggerSaveAs(String url, optional String blob)
This function attempts to show a Save As dialog for a given URL.
It attempts to use the a.download attribute, if available, and
falls back to window.open(<url>, '_parent') if unavailable.
See also http://caniuse.com/download
The Chrome extension activates PDF.js by inserting the script tags
in a document whose URL and location origin is identical to the PDF
file.
Because of this, the path './images/' was resolved relatively to the
location of the PDF file instead of the extension.
To fix this, the IMAGE_DIR constant is moved outside the local scope,
to allow extensions/chrome/insertviewer.js to override the value.
Originally, the IMAGE_DIR variable was a global variable, but commit
f8f4b3f45d moved the global variable
to the local scope, causing the extension to malfunction.
Impact: low, the only consequence is that some rarely used images
were not visible.
Trivial test:
At the center of page 2, the annotation icon
(images/annotation-comment.svg) should be visible:
http://linorg.usp.br/CTAN/macros/latex/contrib/pdfcomment/doc/pdfcomment.pdf
