Skip to content
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

PDFDataRangeTransport appears to require 65536-byte chunks #6517

Closed
adammw opened this issue Oct 11, 2015 · 2 comments
Closed

PDFDataRangeTransport appears to require 65536-byte chunks #6517

adammw opened this issue Oct 11, 2015 · 2 comments

Comments

@adammw
Copy link

adammw commented Oct 11, 2015

I'm attempting to provide a custom transport which internally uses the fetch() api to grab the data from the PDF and therefore returns variable-sized chunks when reading. This doesn't seem to be documented anywhere, I just hitting this assertion, and I don't quite see how I can get this from PDFDataRangeTransport as it's used internally within the worker (or at least as far as I can tell). I can see a lot of issues from @bh213 about chunking/streaming PDFs, but that was back in 2014 so I'm not sure what the state of pdf.js is at the moment. Since PDF.js already has code to handle putting chunks together, it'd really help if the consumer of the API didn't have to do this, and PDF.js could just handle variable-sized chunks.

@timvandermeij
Copy link
Contributor

I'm not sure if this will help you, but recently #6568 landed, allowing custom solutions to provide a range chunk size of their wish. Now that that is an API setting, it should make life easier for custom solutions, however since you want to have variable-sized chunks I'm not sure if it we be of much use for you.

@Snuffleupagus
Copy link
Collaborator

Snuffleupagus commented Feb 19, 2019

I'm attempting to provide a custom transport which internally uses the fetch() api to grab the data from the PDF and therefore returns variable-sized chunks when reading.

Note that the Fetch API has been officially supported for a couple of years now.
Furthermore, given #6517 (comment) and the age of the issue, should this be closed now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants