Failing PDF:
15240917076692yt54e2iickoemgikbw486w29.pdf
Configuration:
Steps to reproduce the problem:
# 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.
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.
Any news on this?
Thanks.
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.
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.)
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.
even if the underlying cause is yet undetermined?
Please see https://github.com/mozilla/pdf.js/issues/9675#issuecomment-394350263, 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.
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.
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
Most helpful comment
4244 has been there for 4 years, AND THERE IS STILL NO SOLUTION PROVIDED