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

Error: Requesting object that isn't resolved yet on PDF even with disableFontFace #9675

Closed
RafaPolit opened this issue Apr 18, 2018 · 9 comments
Labels

Comments

@RafaPolit
Copy link
Contributor

Failing PDF:
15240917076692yt54e2iickoemgikbw486w29.pdf

Configuration:

  • Version: node v6.9.5

  • Operating system and its version: Ubuntu 16.04LTS

  • PDF.js version: 2.0.0

Steps to reproduce the problem:

  1. Run the demo code found in https://github.com/mozilla/pdf.js/blob/master/examples/node/pdf2png/pdf2png.js
  2. Console outputs:
# PDF document loaded.
(node:1211) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Requesting object that isn't resolved yet Verdana_path_C

What is the expected behavior?

A successful conversion

What went wrong?

# PDF document loaded.
(node:1211) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): Error: Requesting object that isn't resolved yet Verdana_path_C

This is happening even though the disableFontFace: true flag has been set, which seems wrong.

Thanks for any insight. Best regards,
Rafa.

@RafaPolit
Copy link
Contributor Author

RafaPolit commented Apr 20, 2018

I believe that the error can be caught (instead of an UnhandledPromiseRejection) extending the Promise.resolve in the _scheduleNext function in https://github.com/mozilla/pdf.js/blob/master/src/display/api.js#L2452 with a catch.

Why is the Verdana_path_C object not being resolved is less clear at this point.

_scheduleNext: function InternalRenderTask__scheduleNext() {
  if (this.useRequestAnimationFrame && typeof window !== 'undefined') {
    window.requestAnimationFrame(this._nextBound);
  } else {
    Promise.resolve(undefined).then(this._nextBound).catch(this.callback);
  }
}

Also, the original line:

Promise.resolve(undefined).then(this._nextBound)

is somewhat perplexing. What is the intent of creating a non-returned promise resolved with undefined to call on the function? Why is undefined explicitly passed when doing Promise.resolve().then... would achieve the same thing?

The only scenario where the Promise implementation would make sense is to return the promise or to actually catch any errors, to avoid a try-catch on the this._nextBound call. But without the catch, the line makes little sense to me.

@RafaPolit
Copy link
Contributor Author

Any news on this?

Thanks.

@timvandermeij
Copy link
Contributor

Not yet. We've been busy with other pull requests first, but I do agree that the error handling should at least be improved here. The cause of the underlying issue is not yet clear.

@Snuffleupagus
Copy link
Collaborator

Snuffleupagus commented Jun 4, 2018

The cause of the underlying issue is not yet clear.

This is simply (another) duplicate of issue #4244, and should probably be closed as such.

(Also, it seems to me that if a work-around is implemented, it really needs to apply generally and not only for part of the problem. Hence the proposed PR does not strike me as a good solution.)

@diego-lipinski-de-castro
Copy link

diego-lipinski-de-castro commented Jun 4, 2018

#4244 has been there for 4 years, AND THERE IS STILL NO SOLUTION PROVIDED

@RafaPolit
Copy link
Contributor Author

Could the error handling be dealt with, even if the underlying cause is yet undetermined? The underlying fix would be important to have a better overall experience, but the error handling is critical to have a working environment.

I think the PR I submitted could be merged without introducing any side effects or detrimental behaviors. Please take a look at it, as it is crucial for us at this point moving forward.

Thanks, best regards,
Rafa.

@Snuffleupagus
Copy link
Collaborator

even if the underlying cause is yet undetermined?

Please see #9675 (comment), and in particular issue #4244 that it refers to.

I think the PR I submitted could be merged without introducing any side effects or detrimental behaviors.

It would cause a difference in behaviour depending on which of the two code-paths are being used (canvas rendering vs operatorList fetching), which doesn't strike me as a particularly great situation.

@timvandermeij
Copy link
Contributor

timvandermeij commented Jun 16, 2018

The error handling is improved by #9689 and #9809, so the errors can be caught and rendering will try to continue. This is now a duplicate of #4244, so I'm closing this one.

@gustawdaniel
Copy link

But I have this error in my project.

I was using this file as example:

https://github.com/mozilla/pdf.js/blob/master/examples/node/pdf2png/pdf2png.js

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

No branches or pull requests

5 participants