Implement progressive loading of PDFs #2719

Merged
merged 5 commits into from Apr 18, 2013

Conversation

Projects
None yet
@mduan
Contributor

mduan commented Feb 13, 2013

This implements progressive loading of the PDF using an implementation similar to that described in #1108.

Note: This is still a work in progress, so it's incomplete and a bit messy. It is NOT ready to be merged.

Some of the things that still have to be done are:

  • Integrate w/ extension
  • For addon: fallback to fetching entire PDF if range requests are not supported
  • For viewer: fallback to fetching entire PDF if range requests are not supported
  • When there are no PDF chunks that are actively being requested, continue fetching PDF chunks sequentially
  • Fetching the current page first when the user changes pages
  • Optimization of parsing XRef tables/streams
  • Optimization of fetching of page tree
  • Possibly more optimizations specifically for linearized PDFs
  • Code cleanup
  • Unit tests, regression tests, etc...
@waddlesplash

This comment has been minimized.

Show comment
Hide comment
@waddlesplash

waddlesplash Feb 14, 2013

Contributor

Does this supersede PR #1923 (HTTP range request support)?

Contributor

waddlesplash commented Feb 14, 2013

Does this supersede PR #1923 (HTTP range request support)?

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Feb 14, 2013

Contributor

That's the goal. We cannot go forward w/ #1923 because it makes synchronous xhr requests, which will not work with the extension. This implementation uses asynchronous xhr requests.

Contributor

mduan commented Feb 14, 2013

That's the goal. We cannot go forward w/ #1923 because it makes synchronous xhr requests, which will not work with the extension. This implementation uses asynchronous xhr requests.

@waddlesplash

This comment has been minimized.

Show comment
Hide comment
@waddlesplash

waddlesplash Feb 20, 2013

Contributor

How does this support search? If someone opens the find bar, does it notify them & then download the rest of the PDF?

Contributor

waddlesplash commented Feb 20, 2013

How does this support search? If someone opens the find bar, does it notify them & then download the rest of the PDF?

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Feb 20, 2013

Contributor

@waddlesplash I suppose it would search the portions of the pdf that have been loaded so far.

Contributor

mduan commented Feb 20, 2013

@waddlesplash I suppose it would search the portions of the pdf that have been loaded so far.

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Feb 26, 2013

Contributor

/botio-windows preview

Contributor

mduan commented Feb 26, 2013

/botio-windows preview

@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Feb 26, 2013

Collaborator

From: Bot.io (Windows)


Received

Command cmd_preview from @mduan received. Current queue size: 0

Live output at: http://107.22.172.223:8877/0d6791a73c05149/output.txt

Collaborator

pdfjsbot commented Feb 26, 2013

From: Bot.io (Windows)


Received

Command cmd_preview from @mduan received. Current queue size: 0

Live output at: http://107.22.172.223:8877/0d6791a73c05149/output.txt

@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Feb 26, 2013

Collaborator

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/0d6791a73c05149/output.txt

Total script time: 0.14 mins

Collaborator

pdfjsbot commented Feb 26, 2013

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/0d6791a73c05149/output.txt

Total script time: 0.14 mins

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 2, 2013

Contributor

This PR is fairly stable now, but is still in need of some real-world testing.

I've uploaded a packaged XPI of this PR at: http://dl.dropbox.com/u/5961585/pdf.js.xpi.

If anyone has some time, it'd be appreciated if you could try it out and let me know if you encounter any issues or have any feedback.

Contributor

mduan commented Mar 2, 2013

This PR is fairly stable now, but is still in need of some real-world testing.

I've uploaded a packaged XPI of this PR at: http://dl.dropbox.com/u/5961585/pdf.js.xpi.

If anyone has some time, it'd be appreciated if you could try it out and let me know if you encounter any issues or have any feedback.

@waddlesplash

This comment has been minimized.

Show comment
Hide comment
@waddlesplash

waddlesplash Mar 2, 2013

Contributor

Just installed. Will use it normally and I"ll tell you what happens :)

Contributor

waddlesplash commented Mar 2, 2013

Just installed. Will use it normally and I"ll tell you what happens :)

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 2, 2013

Contributor

@waddlesplash: sweet, thanks :)

Contributor

mduan commented Mar 2, 2013

@waddlesplash: sweet, thanks :)

@Snuffleupagus

This comment has been minimized.

Show comment
Hide comment
@Snuffleupagus

Snuffleupagus Mar 2, 2013

Contributor

I just tried it, and it doesn't work for me. I tried both your XPI file and checking out your repo and building the extension myself, but I just get the following error:
[11:03:54.460] TypeError: request.setUserData is not a function @ resource://pdf.js/web/viewer.js:175

Edit: My configuration: Windows 7 Professional SP1 (64-bit), Nightly 22 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130301 Firefox/22.0 ID:20130301030909 CSet: 993d7aff3109)

Contributor

Snuffleupagus commented Mar 2, 2013

I just tried it, and it doesn't work for me. I tried both your XPI file and checking out your repo and building the extension myself, but I just get the following error:
[11:03:54.460] TypeError: request.setUserData is not a function @ resource://pdf.js/web/viewer.js:175

Edit: My configuration: Windows 7 Professional SP1 (64-bit), Nightly 22 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130301 Firefox/22.0 ID:20130301030909 CSet: 993d7aff3109)

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 3, 2013

Contributor

@Snuffleupagus I get the same issue on Nightly, but it works for me on Aurora and earlier. Could you try with an earlier version of FF while I try to figure out the issue wtih Nightly?

Contributor

mduan commented Mar 3, 2013

@Snuffleupagus I get the same issue on Nightly, but it works for me on Aurora and earlier. Could you try with an earlier version of FF while I try to figure out the issue wtih Nightly?

@Snuffleupagus

This comment has been minimized.

Show comment
Hide comment
@Snuffleupagus

Snuffleupagus Mar 3, 2013

Contributor

@mduan It works in Aurora 21 for me too, and I must say that I'm very impressed by the performance improvement!
For smaller files it seems to subjectively be on par with the standard version of pdf.js. But for larger files, there is a very noticeable difference, in some instances it seems to load the first pages in half the time compared to the standard pdf.js version.

Contributor

Snuffleupagus commented Mar 3, 2013

@mduan It works in Aurora 21 for me too, and I must say that I'm very impressed by the performance improvement!
For smaller files it seems to subjectively be on par with the standard version of pdf.js. But for larger files, there is a very noticeable difference, in some instances it seems to load the first pages in half the time compared to the standard pdf.js version.

@yurydelendik

View changes

src/api.js
+ }
+
+ messageHandler.on('RequestDataRange', function transportDataRange(args) {
+ FirefoxCom.request('requestDataRange', args);

This comment has been minimized.

@yurydelendik

yurydelendik Mar 4, 2013

Contributor

Could you move FirefoxCom and window.addEventListener('message') out of api.js? Provide service/facade for this functionality, e.g. PdfDataTransportService with requestDataRange and onDataRange members. That will be useful if we decide implement one for web viewer.

@yurydelendik

yurydelendik Mar 4, 2013

Contributor

Could you move FirefoxCom and window.addEventListener('message') out of api.js? Provide service/facade for this functionality, e.g. PdfDataTransportService with requestDataRange and onDataRange members. That will be useful if we decide implement one for web viewer.

@yurydelendik

This comment has been minimized.

Show comment
Hide comment
@yurydelendik

yurydelendik Mar 4, 2013

Contributor

setUserData is fixed by 07491f5, I think can cherry-pick this commit

Contributor

yurydelendik commented Mar 4, 2013

setUserData is fixed by 07491f5, I think can cherry-pick this commit

@waddlesplash

This comment has been minimized.

Show comment
Hide comment
@waddlesplash

waddlesplash Mar 4, 2013

Contributor

Just encountered a wierd bug. When opening a PDF from a file:/// URL (which I've done on plenty of other PDFs with no problems), I got the "displayed incorrectly" message (which I had previously gotten on that PDF, see #2637) but this time, only the first and second pages (p2 is the one with the problem) were rendered. I could click the next/prev page buttons, use the scrollbar, etc. - just blank pages. Not even the spinning progress thingy was there.

After about ~5s, the spinning progress GIF appeared and all pages and text selection were rendered normally. The only evidence that it ever happened was that the page previews in the sidebar of the pages I had scrolled past remained blank (white, not black with dashed outline). The other pages in the preview that I had not scrolled past appeared OK.

Contributor

waddlesplash commented Mar 4, 2013

Just encountered a wierd bug. When opening a PDF from a file:/// URL (which I've done on plenty of other PDFs with no problems), I got the "displayed incorrectly" message (which I had previously gotten on that PDF, see #2637) but this time, only the first and second pages (p2 is the one with the problem) were rendered. I could click the next/prev page buttons, use the scrollbar, etc. - just blank pages. Not even the spinning progress thingy was there.

After about ~5s, the spinning progress GIF appeared and all pages and text selection were rendered normally. The only evidence that it ever happened was that the page previews in the sidebar of the pages I had scrolled past remained blank (white, not black with dashed outline). The other pages in the preview that I had not scrolled past appeared OK.

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 4, 2013

Contributor

@waddlesplash: Do you have a link to the PDF? I don't see it in the issue you referenced.

Contributor

mduan commented Mar 4, 2013

@waddlesplash: Do you have a link to the PDF? I don't see it in the issue you referenced.

@waddlesplash

This comment has been minimized.

Show comment
Hide comment
@waddlesplash

waddlesplash Mar 4, 2013

Contributor

Here's a similar one with the same problem as mentioned in #2637: http://www.rosettastone.com/us_assets/documentation/RSV2_UG_Level_1_2_English_%28US%29.pdf

It has a different problem as well: on all pages except page 1, there are just two graphics objects (a "+" and a line). No spinning icon indicating loading.

Contributor

waddlesplash commented Mar 4, 2013

Here's a similar one with the same problem as mentioned in #2637: http://www.rosettastone.com/us_assets/documentation/RSV2_UG_Level_1_2_English_%28US%29.pdf

It has a different problem as well: on all pages except page 1, there are just two graphics objects (a "+" and a line). No spinning icon indicating loading.

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 4, 2013

Contributor

@waddlesplash: I've fixed the problem with the "+" & line showing. In regards to there being a blank page with no spinning icon while it's rendering, the same thing happens without my progressive loading changes.

Contributor

mduan commented Mar 4, 2013

@waddlesplash: I've fixed the problem with the "+" & line showing. In regards to there being a blank page with no spinning icon while it's rendering, the same thing happens without my progressive loading changes.

@waddlesplash

This comment has been minimized.

Show comment
Hide comment
@waddlesplash

waddlesplash Mar 5, 2013

Contributor

Hm. Then that PDF has different behavior than the other PDF I have on my hard drive, because it works fine with the stable version of pdf.js.

Contributor

waddlesplash commented Mar 5, 2013

Hm. Then that PDF has different behavior than the other PDF I have on my hard drive, because it works fine with the stable version of pdf.js.

@bit

This comment has been minimized.

Show comment
Hide comment
@bit

bit Mar 5, 2013

Contributor

while Firefox makes range requests, Chrome makes one request for the full pdf and while that downloads the progress does not update. once the full pdf has been loaded another pending request for Range:bytes=0-0 is made and comes from the cache.

Contributor

bit commented Mar 5, 2013

while Firefox makes range requests, Chrome makes one request for the full pdf and while that downloads the progress does not update. once the full pdf has been loaded another pending request for Range:bytes=0-0 is made and comes from the cache.

@Snuffleupagus

This comment has been minimized.

Show comment
Hide comment
@Snuffleupagus

Snuffleupagus Mar 5, 2013

Contributor

Another related issue #1375?

Contributor

Snuffleupagus commented Mar 5, 2013

Another related issue #1375?

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 5, 2013

Contributor

@bit: The behaviour I saw from Chrome's PDF viewer is that it first requests the full PDF but cancels that request if it finds the server supports range requests. It then enough of the PDF to determine if it is linearized.

If the PDF is linearized, it will fetch the PDF in sequential chunks. Otherwise, it will issue a full request to fetch the PDF.

Linearized PDF: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf
Non-linearized PDF: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

Contributor

mduan commented Mar 5, 2013

@bit: The behaviour I saw from Chrome's PDF viewer is that it first requests the full PDF but cancels that request if it finds the server supports range requests. It then enough of the PDF to determine if it is linearized.

If the PDF is linearized, it will fetch the PDF in sequential chunks. Otherwise, it will issue a full request to fetch the PDF.

Linearized PDF: http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf
Non-linearized PDF: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 5, 2013

Contributor

@Snuffleupagus: This PR will currently continue to download the rest of the PDF in sequential chunks while it's rendering.

Contributor

mduan commented Mar 5, 2013

@Snuffleupagus: This PR will currently continue to download the rest of the PDF in sequential chunks while it's rendering.

@bit

This comment has been minimized.

Show comment
Hide comment
@bit

bit Mar 6, 2013

Contributor

@mduan , sorry my last comment might not have been clear, I was talking about pdf.js in Firefox and pdf.js in Chrome. Both with your patch. Was testing with pdf.js and a larger pdf on the same server, server supports range request. But for some reason pdf.js does not use range requests in Chrome while Firefox works as expected.

Contributor

bit commented Mar 6, 2013

@mduan , sorry my last comment might not have been clear, I was talking about pdf.js in Firefox and pdf.js in Chrome. Both with your patch. Was testing with pdf.js and a larger pdf on the same server, server supports range request. But for some reason pdf.js does not use range requests in Chrome while Firefox works as expected.

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 6, 2013

Contributor

@bit: Is the server public? If so could you share a link?

The way that range requests work right now is that a request is made for the full pdf and once the headers for the full request are returned, we issue a range request. If the range request completes successfully, we cancel the full request and start issuing range requests unless the full request is already complete.

What I think might be happening is that the server is not returning the headers separately from the body. So when headers are received, the full request is already complete and so range requests are not issued.

Contributor

mduan commented Mar 6, 2013

@bit: Is the server public? If so could you share a link?

The way that range requests work right now is that a request is made for the full pdf and once the headers for the full request are returned, we issue a range request. If the range request completes successfully, we cancel the full request and start issuing range requests unless the full request is already complete.

What I think might be happening is that the server is not returning the headers separately from the body. So when headers are received, the full request is already complete and so range requests are not issued.

@bit

This comment has been minimized.

Show comment
Hide comment
@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 8, 2013

Contributor

@bit: Can you try with the latest changes? I think I may have fixed the issue.

Contributor

mduan commented Mar 8, 2013

@bit: Can you try with the latest changes? I think I may have fixed the issue.

@bit

This comment has been minimized.

Show comment
Hide comment
@bit

bit Mar 9, 2013

Contributor

@mduan pulled your latest version and can confirm that it fixes the issue I had in Chrome. Thanks!

Contributor

bit commented Mar 9, 2013

@mduan pulled your latest version and can confirm that it fixes the issue I had in Chrome. Thanks!

@waddlesplash

This comment has been minimized.

Show comment
Hide comment
@waddlesplash

waddlesplash Mar 11, 2013

Contributor

@mduan this is really hard to use with that loading-local-file bug. I just discovered some more to that bug that has to do with text selection. Range requests are beyond my ability, but could you forgo range requests when loading from file:// urls? HDDs are fast enough now :)

Contributor

waddlesplash commented Mar 11, 2013

@mduan this is really hard to use with that loading-local-file bug. I just discovered some more to that bug that has to do with text selection. Range requests are beyond my ability, but could you forgo range requests when loading from file:// urls? HDDs are fast enough now :)

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 11, 2013

Contributor

@waddlesplash: Could you try with the latest changes? For local files, it's not using range requests (range requests only make sense for the HTTP protocol). For local files, It should be behaving the same as before.

Contributor

mduan commented Mar 11, 2013

@waddlesplash: Could you try with the latest changes? For local files, it's not using range requests (range requests only make sense for the HTTP protocol). For local files, It should be behaving the same as before.

@waddlesplash

This comment has been minimized.

Show comment
Hide comment
@waddlesplash

waddlesplash Mar 11, 2013

Contributor

I used the link in the description. Or is that outdated?

Contributor

waddlesplash commented Mar 11, 2013

I used the link in the description. Or is that outdated?

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 11, 2013

Contributor

@waddlesplash Yeah, that link was out of date. I've updated the xpi at the link. Can you try again?

Contributor

mduan commented Mar 11, 2013

@waddlesplash Yeah, that link was out of date. I've updated the xpi at the link. Can you try again?

@waddlesplash

This comment has been minimized.

Show comment
Hide comment
@waddlesplash

waddlesplash Mar 11, 2013

Contributor

Works now, thanks.

Contributor

waddlesplash commented Mar 11, 2013

Works now, thanks.

mduan added a commit to mduan/pdf.js that referenced this pull request Mar 25, 2013

Changes to viewer to support progressive loading
Separates out some of the viewer changes from #2719.
@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Mar 25, 2013

Contributor

Squashed and rebased on top of #2719 and master.

Contributor

mduan commented Mar 25, 2013

Squashed and rebased on top of #2719 and master.

@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Apr 18, 2013

Contributor

/botio test

Contributor

mduan commented Apr 18, 2013

/botio test

@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Apr 18, 2013

Collaborator

From: Bot.io (Windows)


Received

Command cmd_test from @mduan received. Current queue size: 0

Live output at: http://107.22.172.223:8877/7fa68b4886cbd98/output.txt

Collaborator

pdfjsbot commented Apr 18, 2013

From: Bot.io (Windows)


Received

Command cmd_test from @mduan received. Current queue size: 0

Live output at: http://107.22.172.223:8877/7fa68b4886cbd98/output.txt

@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Apr 18, 2013

Collaborator

From: Bot.io (Linux)


Received

Command cmd_test from @mduan received. Current queue size: 0

Live output at: http://107.21.233.14:8877/a00f05cfa3d2790/output.txt

Collaborator

pdfjsbot commented Apr 18, 2013

From: Bot.io (Linux)


Received

Command cmd_test from @mduan received. Current queue size: 0

Live output at: http://107.21.233.14:8877/a00f05cfa3d2790/output.txt

@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Apr 18, 2013

Collaborator

From: Bot.io (Linux)


Success

Full output at http://107.21.233.14:8877/a00f05cfa3d2790/output.txt

Total script time: 21.72 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed
Collaborator

pdfjsbot commented Apr 18, 2013

From: Bot.io (Linux)


Success

Full output at http://107.21.233.14:8877/a00f05cfa3d2790/output.txt

Total script time: 21.72 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed
@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Apr 18, 2013

Collaborator

From: Bot.io (Windows)


Success

Full output at http://107.22.172.223:8877/7fa68b4886cbd98/output.txt

Total script time: 25.10 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed
Collaborator

pdfjsbot commented Apr 18, 2013

From: Bot.io (Windows)


Success

Full output at http://107.22.172.223:8877/7fa68b4886cbd98/output.txt

Total script time: 25.10 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed
@mduan

This comment has been minimized.

Show comment
Hide comment
@mduan

mduan Apr 18, 2013

Contributor

/botio test

Contributor

mduan commented Apr 18, 2013

/botio test

@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Apr 18, 2013

Collaborator

From: Bot.io (Windows)


Received

Command cmd_test from @mduan received. Current queue size: 0

Live output at: http://107.22.172.223:8877/0a8868c275ad385/output.txt

Collaborator

pdfjsbot commented Apr 18, 2013

From: Bot.io (Windows)


Received

Command cmd_test from @mduan received. Current queue size: 0

Live output at: http://107.22.172.223:8877/0a8868c275ad385/output.txt

@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Apr 18, 2013

Collaborator

From: Bot.io (Linux)


Received

Command cmd_test from @mduan received. Current queue size: 0

Live output at: http://107.21.233.14:8877/3489dea265c46fe/output.txt

Collaborator

pdfjsbot commented Apr 18, 2013

From: Bot.io (Linux)


Received

Command cmd_test from @mduan received. Current queue size: 0

Live output at: http://107.21.233.14:8877/3489dea265c46fe/output.txt

@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Apr 18, 2013

Collaborator

From: Bot.io (Linux)


Success

Full output at http://107.21.233.14:8877/3489dea265c46fe/output.txt

Total script time: 22.63 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed
Collaborator

pdfjsbot commented Apr 18, 2013

From: Bot.io (Linux)


Success

Full output at http://107.21.233.14:8877/3489dea265c46fe/output.txt

Total script time: 22.63 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed
@pdfjsbot

This comment has been minimized.

Show comment
Hide comment
@pdfjsbot

pdfjsbot Apr 18, 2013

Collaborator

From: Bot.io (Windows)


Success

Full output at http://107.22.172.223:8877/0a8868c275ad385/output.txt

Total script time: 25.08 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed
Collaborator

pdfjsbot commented Apr 18, 2013

From: Bot.io (Windows)


Success

Full output at http://107.22.172.223:8877/0a8868c275ad385/output.txt

Total script time: 25.08 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed

brendandahl added a commit that referenced this pull request Apr 18, 2013

Merge pull request #2719 from mduan/chunked
Implement progressive loading of PDFs

@brendandahl brendandahl merged commit 49ff029 into mozilla:master Apr 18, 2013

@timvandermeij

This comment has been minimized.

Show comment
Hide comment
@timvandermeij

timvandermeij Apr 18, 2013

Contributor

I just wanted to say that I am very impressed by this great patch, @mduan! This looks like a fantastic feature to me.

Contributor

timvandermeij commented Apr 18, 2013

I just wanted to say that I am very impressed by this great patch, @mduan! This looks like a fantastic feature to me.

@loftux loftux referenced this pull request in share-extras/media-viewers Apr 19, 2013

Open

Add Pdf.js support for progressive loading of pdf. #1

@Snuffleupagus Snuffleupagus referenced this pull request Apr 27, 2013

Closed

Cannot open PDF #3168

@aamironline

This comment has been minimized.

Show comment
Hide comment
@aamironline

aamironline Apr 26, 2015

What's the status of this ticket? It looks like all the sub tasks have been finished (check boxes are checked) still ticket says it is NOT complete!

What's the status of this ticket? It looks like all the sub tasks have been finished (check boxes are checked) still ticket says it is NOT complete!

@timvandermeij

This comment has been minimized.

Show comment
Hide comment
@timvandermeij

timvandermeij Apr 26, 2015

Contributor

This PR has the status 'merged', so it is indeed done. This has already been implemented for a very long time in PDF.js. Every other issue related to this has been closed, so I see no problems here.

Contributor

timvandermeij commented Apr 26, 2015

This PR has the status 'merged', so it is indeed done. This has already been implemented for a very long time in PDF.js. Every other issue related to this has been closed, so I see no problems here.

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