-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting disableAutoFetch resp. disableStream working... #7937
Comments
If PDF.js cannot detect HTTP range request support from server or client/browser, it will download entire PDF. I assume the problem with your server since specified browsers (Chrome v53, IE 11) has no defect with supporting range requests. You did not submit a public link to application to verify the assumption. Closing as answered. |
In you enable PDF.js debugging for demo viewer, you can check http://mozilla.github.io/pdf.js/web/viewer.html#disableAutoFetch=true&disableStream=true (notice that Chrome aggressively caches, disable cache so it will not pull already cached PDF file) |
Yury, Many thanks. I will check tomorrow. Unfortunately I can NOT easily provide a public link (and probably I am not even allowed to) as the application is running in an intranet.
Sorry, I did not get that. I am sure range requests are working: I am seeing the range requests on server side. It is really nice because the PDF starts to display BEFORE the downloading is finished. But the client requests all the ranges, from the first one to the last one. Should Thanks and cheers, christian |
It does, see demo link. If you app requests information about every page (e.g. size) and pdf compressed in certain way, you may end up pulling entire pdf. It's really hard to tell without seeing the example, hence we request OP to provide entire information and a way to reproduce the issue locally. |
Yury, By carefully observing the loading bar in your example, I am seeing that the loading is stopping after a couple of pages. This is exactly what I would like to achieve in my case as well. However, when I am asking for a page in the middle of the PDF or for one of the last pages, I am seeing as well, that the client is downloading all the previous pages/ranges. Is that right? What should theoretically be the added value of setting/changing the debugging options? I did not notice any change (in the console output at least) of my Firefox browser. I tried all three possibilities (either because I did not understand for which situation they were appropriate or because I did notice any change by applying them). I though, I should be categorized to the third case (Generic viewer). But then I got following picture: Kindest regards, christian |
http://mozilla.github.io/pdf.js/web/viewer.html also works same way as above one with options can you provide how to disable auto fetch for secured links https://mozilla.github.io/pdf.js/web/viewer.html#disableAutoFetch=true&disableStream=true it is not working for the above secured link |
Link to PDF file (or attach file here):
Configuration
viewer.js
, ...) with range requests.Description
I am working with huge PDFs (500MB in worst cases and around 200MB is quite usual). PDF is maybe NOT the most appropriate format but, for now, this is OK and this is another discussion.
Up to following issue, it seems possible to render a single page. I played around with
disableAutoFetch
resp.disableStream
. However, I was not able to get it working.To reduce the complexity (I am using the viewer), I played around with following, much more simple example as well. No success here neither. Before being able to jump to previous/next page, the whole PDF is downloaded to client side.
What I tried out
var url = '/pdf/get/{{id}}#disableAutoFetch=true&disableStream=true';
PDFJS.disableAutoFetch= true;PDFJS.disableStream=true;
as suggested here.Questions
disableAutoFetch
resp.disableStream
?I've read following article as well.
Thanks for your time. Wish you a good day.
Best regards,
christian
The text was updated successfully, but these errors were encountered: