Skip to content

Loading…

Implement progressive loading of PDFs #2719

Merged
merged 5 commits into from
@mduan

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

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

@mduan

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

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

@mduan

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

@mduan

/botio-windows preview

@pdfjsbot

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

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 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

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

@mduan

@waddlesplash: sweet, thanks :)

@Snuffleupagus
Mozilla member

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

@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
Mozilla member

@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 yurydelendik commented on an outdated diff
src/api.js
@@ -532,6 +533,16 @@ var WorkerTransport = (function WorkerTransportClosure() {
function WorkerTransport_setupMessageHandler(messageHandler) {
this.messageHandler = messageHandler;
+ if (this.source.chunkedChromeLoading) {
+ window.addEventListener('message', function window_message(evt) {
+ this.messageHandler.send('SendDataRange', evt.data);
+ }.bind(this));
+ }
+
+ messageHandler.on('RequestDataRange', function transportDataRange(args) {
+ FirefoxCom.request('requestDataRange', args);

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.

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

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

@waddlesplash

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

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

@waddlesplash

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

@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

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
bit commented

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
Mozilla member

Another related issue #1375?

@mduan

@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

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

@bit
bit commented

@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

@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.

@mduan

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

@mduan mduan referenced this pull request
Commit has since been removed from the repository and is no longer available.
@mduan mduan referenced this pull request
Commit has since been removed from the repository and is no longer available.
@bit
bit commented

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

@waddlesplash

@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

@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
@mduan

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

@waddlesplash

Works now, thanks.

@mduan mduan referenced this pull request
Commit has since been removed from the repository and is no longer available.
@mduan mduan added a commit to mduan/pdf.js that referenced this pull request
@mduan mduan Changes to viewer to support progressive loading
Separates out some of the viewer changes from #2719.
dcc73dc
@mduan

Squashed and rebased on top of #2719 and master.

@mduan

/botio test

@pdfjsbot

From: Bot.io (Linux)


Received

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

Live output at: http://107.21.233.14:8877/9a56ce7ddbe4981/output.txt

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/2f6fabe67c9431d/output.txt

@pdfjsbot

From: Bot.io (Linux)


Success

Full output at http://107.21.233.14:8877/9a56ce7ddbe4981/output.txt

Total script time: 20.10 mins

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

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/2f6fabe67c9431d/output.txt

Total script time: 22.24 mins

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

/botio-windows preview

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/bb1c78b15164d9c/output.txt

@Snuffleupagus
Mozilla member

@mduan I've been using the latest extension for a couple of hours now, and in my limited testing it seems to work really well!
Edit: I've actually discovered a couple of small issues.

  • There seems to be no way to cancel a loading file, other than closing the tab or navigating back in the history.
  • When a file isn't in the database in about:config, the zoom level seems to default to 100% instead of automatic.

I like the look of the new progress bar, but I have one minor nit. When the progress bar is visible, it overlays the scroll bar. See attached image:
progress_bar

@mduan

@Snuffleupagus: Thanks for the feedback!

There seems to be no way to cancel a loading file, other than closing the tab or navigating back in the history.

I'll try to fix this if it's easy, otherwise I might leave to a subsequent PR since it doesn't seem to be a common use case.

When a file isn't in the database in about:config, the zoom level seems to default to 100% instead of automatic.

Are you sure this is specific to my PR? I get the same behaviour with master (The zoom level starts as automatic and changes to 100% once the document loads). So maybe something else broke this.

EDIT: Actually, it does look like I broke this. I'll fix it.

When the progress bar is visible, it overlays the scroll bar.

Will definitely fix this.

@ducarroz

I have tested this PR to see if it would solve some of my issues when trying to load a large PDF file. The file is 334MB for 190 pages with full page graphics on almost every page.

Chrome (canary, dev) crashes right away as soon pdf.js viewer tries to load the file. I noticed that when I try to load it using the helloworld example (which displays only the first page), the document is correctly loaded using range request of 64K each (as I was expecting). However, pdf.js continues to load the document chunk per chunk even after the first page has been fully rendered, this until the whole document is loaded in memory.

Would it be possible to fetch only the needed parts?

Would it be possible to keep in memory only a specific amount of data (maybe 50MB max), event if that mean to re-download a part that has been already fetched earlier. The reason is that V8 seems to have some issue with large amount of data.

Does pdf.js passes the whole document data across the webworker? if this is the case, would it result in another copy of the document data in memory?

BTW, with that PR, pdf.js does not work anymore when webworkers are turned off when you set globalScope.PDFJS.disableWorker = true:

Uncaught ReferenceError: NetworkManager is not defined worker.js:170
@mahmoudfelfel

The same here as @ducarroz , i want to use pdf.js to view large PDF files and at the same time to save user's bandwidth and memory ( specially for smart devices ) , i think fetch-as-you-go will be exactly the solution .

@mduan

@ducarroz:

The file is 334MB for 190 pages with full page graphics on almost every page

Is it possible for you to share the file? I'd be interested in taking a look at it

Would it be possible to fetch only the needed parts?

This is pretty easy to do. I think the default behaviour will still be fetching the full file, but adding a flag to fetch only the needed parts sounds reasonable. I'd probably be doing this in another PR though, after this lands.

Would it be possible to keep in memory only a specific amount of data (maybe 50MB max)

This also sounds useful. However, it worth noting that most of the memory usage is not from the PDF's file, especially but from our internal representation of the file as we process it.

Does pdf.js passes the whole document data across the webworker?

No, it sends across only the portions that are needed. So if you are viewing page 2, it only sends across data for page 2 (and possibly the adjacent pages). It sends the data using an internal representation of the file that can be converted to draw commands on canvas.

BTW, with that PR, pdf.js does not work anymore when webworkers are turned off when you set globalScope.PDFJS.disableWorker = true

I've noticed this infrequently with html caching disabled. Does it happen every time you load the page?

@ducarroz
@ducarroz

I have managed to generate a test file to expose the problem:
http://ducarroz.org/sample.pdf

@mduan

@ducarroz

BTW, with that PR, pdf.js does not work anymore when webworkers are turned off when you set globalScope.PDFJS.disableWorker = true

Did you disable the worker with #disableWorker=true or did you do it some other way? And you said this was on Chrome right?

@ducarroz

I disable the worker by setting globalScope.PDFJS.disableWorker = true at the top of examples/helloworld/hello.js

@mduan

@ducarroz: The ReferenceError should be fixed now.

@Snuffleupagus
Mozilla member

There seems to be no way to cancel a loading file [...]

I'll try to fix this if it's easy, otherwise I might leave to a subsequent PR since it doesn't seem to be a common use case.

I completely agree with your statement that this isn't a common use case, so don't hold back this PR on account of it.

Also, I discovered another minor visual issue with the loading bar. On smaller screen sizes, it will overlay the top of the sidebar container (since the sidebar floats on top of the document).
I'm really impressed with the work you've done in this PR and I would never be able do this kind of thing myself! I hope that you don't mind that I took the liberty to try and tweak the CSS of the loading bar. The following code would fix the above issue on smaller screen sizes, and as a bonus simplifies the code for hiding the loading bar: Snuffleupagus@8774539. Feel free to use any of this if you see fit!

I really don't mean to step on your toes, so please excuse me if this suggestion is out of line!

@mduan

Thanks @Snuffleupagus! I've pulled in your changes. I reduced the y offset for the sidebar by 1px since I noticed there was a white gap between it and the toolbar.

@mduan

/botio-windows preview

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/5b974ed3b95f0b6/output.txt

@pdfjsbot

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/5b974ed3b95f0b6/output.txt

Total script time: 0.12 mins

@mduan

/botio-windows preview

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/25bb621f45ec24f/output.txt

@yurydelendik

Save/download of the file is not preserving the Content-Disposition name (e.g. at http://www.microrevolt.org/knitPro/index.php)

@yurydelendik

Is it possible the stretch loading indicator to the web page width even when outline/pages panel is open?

@mduan

/botio-windows preview

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/577983a82ad8d8a/output.txt

@pdfjsbot

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/577983a82ad8d8a/output.txt

Total script time: 0.15 mins

@mduan

@yurydelendik:

Save/download of the file is not preserving the Content-Disposition name (e.g. at http://www.microrevolt.org/knitPro/index.php)

Fixed.

Is it possible the stretch loading indicator to the web page width even when outline/pages panel is open?

I'm not sure it'd look better that way. Maybe I can experiment w/ it in another PR.

@mduan

/botio-windows preview

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/08c6189c0ba8ccf/output.txt

@brendandahl brendandahl commented on the diff
extensions/firefox/components/PdfStreamConverter.js
@@ -625,8 +752,18 @@ PdfStreamConverter.prototype = {
var domWindow = getDOMWindow(channel);
// Double check the url is still the correct one.
if (domWindow.document.documentURIObject.equals(aRequest.URI)) {
- var actions = new ChromeActions(domWindow, dataListener,
- contentDispositionFilename);
+ var actions;
+ if (acceptRanges) {
+ // We are going to be issuing range requests, so cancel the
+ // original request
+ aRequest.resume();

Do we have to resume before cancelling?

@mduan
mduan added a note

I'm pretty sure if there was an issue without this line, so I think this is necessary. I'll test without it and let you know what the issue is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@brendandahl brendandahl commented on an outdated diff
src/evaluator.js
@@ -177,6 +176,10 @@ var PartialEvaluator = (function PartialEvaluatorClosure() {
translated = this.translateFont(font, xref, resources,
dependency);
} catch (e) {
+ if (e instanceof MissingDataException) {
+ font.loadedName = undefined;

Just set to null.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@brendandahl brendandahl commented on an outdated diff
src/pdf_manager.js
((19 lines not shown))
+
+'use strict';
+
+// TODO(mack): Make use of PDFJS.Util.inherit() when it becomes available
+var BasePdfManager = (function BasePdfManagerClosure() {
+ function BasePdfManager() {
+ throw new Error('Cannot initialize BaseManagerManager');
+ }
+
+ BasePdfManager.prototype = {
+ onLoadedStream: function BasePdfManager_onLoadedStream() {
+ throw new NotImplementedException();
+ },
+
+ ensureModel: function BasePdfManager_ensureModel(prop) {
+ var args = [].slice.call(arguments);

Use Array.prototype here and in all the other places you use []

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@brendandahl brendandahl commented on an outdated diff
src/pdf_manager.js
((97 lines not shown))
+
+ LocalPdfManager.prototype.requestLoadedStream =
+ function LocalPdfManager_requestLoadedStream() {
+ };
+
+ LocalPdfManager.prototype.onLoadedStream =
+ function LocalPdfManager_getLoadedStream() {
+ return this.loadedStream;
+ };
+
+ return LocalPdfManager;
+})();
+
+var NetworkPdfManager = (function NetworkPdfManagerClosure() {
+
+ var CHUNK_SIZE = 64000;

Its still unclear what we should use here, but let's at least use a power of two(65536) since computers a good with dealing them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@brendandahl brendandahl commented on an outdated diff
test/test_manifest.json
@@ -1,4 +1,11 @@
[
+ { "id": "filled-background-range",
+ "file": "pdfs/filled-background.pdf",
+ "md5": "2e3120255d9c3e79b96d2543b12d2589",
+ "rounds": 1,
+ "rangeRequest": true,

As discussed in IRC we should default to rangeRequest on by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@brendandahl brendandahl commented on an outdated diff
extensions/firefox/components/PdfStreamConverter.js
@@ -306,37 +306,7 @@ ChromeActions.prototype = {
return getStringPref('general.useragent.locale', 'en-US');
},
getLoadingType: function() {

Is getLoadingType needed anymore?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@brendandahl brendandahl commented on the diff
extensions/firefox/components/PdfStreamConverter.js
((33 lines not shown))
+ const XMLHttpRequest = Components.Constructor(
+ '@mozilla.org/xmlextras/xmlhttprequest;1');
+ return new XMLHttpRequest();
+ };
+
+ this.networkManager = new NetworkManager(this.pdfUrl, {
+ httpHeaders: httpHeaderVisitor.headers,
+ getXhr: getXhr
+ });
+
+ var self = this;
+ // If we are in range request mode, this means we manually issued xhr
+ // requests, which we need to abort when we leave the page
+ domWindow.addEventListener('unload', function unload(e) {
+ self.networkManager.abortAllRequests();
+ domWindow.removeEventListener(e.type, unload);

This won't remove the event listener because unload points to the function not the instance that was added. e.g. https://github.com/mozilla/pdf.js/blob/master/extensions/firefox/components/PdfStreamConverter.js#L497

@mduan
mduan added a note

I just tested. I believe this works.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@brendandahl brendandahl commented on the diff
extensions/firefox/components/PdfStreamConverter.js
((13 lines not shown))
},
// nsIRequestObserver::onStartRequest
onStartRequest: function(aRequest, aContext) {
// Setup the request so we can use it below.
+ var acceptRanges = false;
+ try {
+ aRequest.QueryInterface(Ci.nsIHttpChannel);
+ if (aRequest.getResponseHeader('Accept-Ranges') === 'bytes') {
+ var hash = aRequest.URI.ref;
+ acceptRanges = hash.indexOf('disableRange=true') < 0;

Let's only allow disabling this if pdfBugEnabled. We generally try not to let the url affect behaviour. If someone really wants to disable range request then they shouldn't have it in the http headers.

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

/botio test

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/4430a28f26e7da9/output.txt

@pdfjsbot

From: Bot.io (Linux)


Received

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

Live output at: http://107.21.233.14:8877/3f36e0b319b6319/output.txt

@pdfjsbot

From: Bot.io (Linux)


Failed

Full output at http://107.21.233.14:8877/3f36e0b319b6319/output.txt

Total script time: 21.77 mins

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

Image differences available at: http://107.21.233.14:8877/3f36e0b319b6319/reftest-analyzer.xhtml#web=eq.log

@pdfjsbot

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/4430a28f26e7da9/output.txt

Total script time: 24.20 mins

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

Image differences available at: http://107.22.172.223:8877/4430a28f26e7da9/reftest-analyzer.xhtml#web=eq.log

@mduan

/botio test

@pdfjsbot

From: Bot.io (Linux)


Received

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

Live output at: http://107.21.233.14:8877/569bc9e08c2c565/output.txt

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/b7bc464be416f12/output.txt

@pdfjsbot

From: Bot.io (Linux)


Failed

Full output at http://107.21.233.14:8877/569bc9e08c2c565/output.txt

Total script time: 22.31 mins

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

Image differences available at: http://107.21.233.14:8877/569bc9e08c2c565/reftest-analyzer.xhtml#web=eq.log

@pdfjsbot

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/b7bc464be416f12/output.txt

Total script time: 24.81 mins

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

Image differences available at: http://107.22.172.223:8877/b7bc464be416f12/reftest-analyzer.xhtml#web=eq.log

@mduan

/botio test

@pdfjsbot

From: Bot.io (Linux)


Received

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

Live output at: http://107.21.233.14:8877/19e0d70397f8ce6/output.txt

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/d42aa330bc283f3/output.txt

@mduan

/botio test

@pdfjsbot

From: Bot.io (Linux)


Received

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

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

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/73391f486196539/output.txt

@pdfjsbot

From: Bot.io (Linux)


Failed

Full output at http://107.21.233.14:8877/19e0d70397f8ce6/output.txt

Total script time: 21.59 mins

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

Image differences available at: http://107.21.233.14:8877/19e0d70397f8ce6/reftest-analyzer.xhtml#web=eq.log

@pdfjsbot

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/d42aa330bc283f3/output.txt

Total script time: 25.02 mins

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

Image differences available at: http://107.22.172.223:8877/d42aa330bc283f3/reftest-analyzer.xhtml#web=eq.log

@pdfjsbot

From: Bot.io (Linux)


Success

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

Total script time: 20.16 mins

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

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/73391f486196539/output.txt

Total script time: 23.08 mins

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

/botio-windows test

@pdfjsbot

From: Bot.io (Windows)


Received

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

Live output at: http://107.22.172.223:8877/ea71b29e85a2fb8/output.txt

@pdfjsbot

From: Bot.io (Windows)


Failed

Full output at http://107.22.172.223:8877/ea71b29e85a2fb8/output.txt

Total script time: 14.07 mins

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

Image differences available at: http://107.22.172.223:8877/ea71b29e85a2fb8/reftest-analyzer.xhtml#web=eq.log

@mduan

/botio test

@pdfjsbot

From: Bot.io (Windows)


Received

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

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

@pdfjsbot

From: Bot.io (Linux)


Received

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

Live output at: http://107.21.233.14:8877/99904ba395f15e9/output.txt

@pdfjsbot

From: Bot.io (Linux)


Success

Full output at http://107.21.233.14:8877/99904ba395f15e9/output.txt

Total script time: 21.50 mins

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

From: Bot.io (Windows)


Success

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

Total script time: 25.18 mins

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

/botio test

@pdfjsbot

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

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

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

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

/botio test

@pdfjsbot

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

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

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

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 brendandahl merged commit 49ff029 into mozilla:master
@timvandermeij

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

@Snuffleupagus Snuffleupagus pushed a commit to Snuffleupagus/pdf.js that referenced this pull request
Jonas Fix document loading with zoom set to 'page-fit', regression from #2719 f6e1c9e
@aamironline

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 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
Something went wrong with that request. Please try again.