Attach (recommended) or Link to PDF file here:
Configuration:
Steps to reproduce the problem:
What is the expected behavior? (add screenshot)
What went wrong? (add screenshot)
Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):
Attach (recommended) or Link to PDF file here:
That part of the issue template is required, in order for any issue to be actionable/valid.
Steps to reproduce the problem:
1. pdf file use font STSong and MSung
2. ios app webview rendering pdf base64str long time, about 30 minutes or longer
Generally speaking, don't use Base64 since it's a very inefficient format (from a memory perspective) and some browsers may even truncate long Base64-strings.
Furthermore, this kind of STR isn't enough for an issue to be actionable; please see https://github.com/mozilla/pdf.js/blob/master/.github/CONTRIBUTING.md (emphasis mine):
If you are developing a custom solution, first check the examples at https://github.com/mozilla/pdf.js#learning and search existing issues. If this does not help, please prepare a short well-documented example that demonstrates the problem and make it accessible online on your website, JS Bin, GitHub, etc. before opening a new issue or contacting us in the Matrix room -- keep in mind that just code snippets won't help us troubleshoot the problem.
Even ignoring the lack of any actionable information here, this unfortunately doesn't seem like a valid PDF.js bug. This rather sounds entirely like a bug in the platform/browser itself, and thus isn't something that we can fix even with additional details provided.
Is it possible that safari cannot download the font bcmap (application/octet-stream), because safari only allows downloading images, and then it has been waiting for the response
Not sure, but in that case it would be a platform issue and not a PDF.js one that we can fix.
I have debugged network requests in Safari, and can normally initiate font requests and responses. As a result, they will always be stuck and show that Safari is currently consuming resources.
Both the code and the network request are running normally, which is the state Safari has been working on
Here's the test code:
// CMapReaderFactory
const request = new XMLHttpRequest();
request.responseType = 'arraybuffer';
request.open('GET', 'cmaps/UniGB-UCS2-H.bcmap', true);
request.onreadystatechange = () => {
if (request.statue === 200 || request.status === 0) {
let cMapData;
if (request.response) { // debuger join this
cMapData = new Unit8Array(request.response); // request.response is ArrayBuffer byteLength: 43366
} else if (request.responseText) {
cMapData = (0, _util.stringToBytes)(request.responseText);
}
}
}
I think after safari gets bcmap, it feels that the thread is blocked for a long time before it reacts. #7423
Fetch bcmap, because some bcmap arraybuffer is very big, safari v8 processing long sequences will block threads!
You can wait patiently for the rendering results and pay attention to the loading and use of fonts.
You can use the following code to view the font.
pdfjsLib.getDocument(param).promise.then(pdf => {
pdf.getPage(1).then(page => {
var canvas = document.getElementById('canvas');
var ctx = canvas.getContext('2d');
var viewport = page.getViewport({scale: 1});
canvas.width = viewport.width;
canvas.height = viewport.height;
canvas.style.width = viewport.width + 'px';
canvas.style.height = viewport.height + 'px';
var renderContext = {
viewport: viewport,
canvasContext: ctx
};
page.getTextContent().then(res => console.log(res)); // read item ues font
page.render(renderContext).promise.then(() => {
console.log('over');
});
})
});
Solution: modify the problematic font in the pdf file
Attach (recommended) or Link to PDF file here:
Configuration:
- Web browser and its version: ios app webview
- Operating system and its version:
- PDF.js version: 2.3.200
- Is a browser extension:
Steps to reproduce the problem:
- pdf file use font STSong and MSung
- ios app webview rendering pdf base64str long time, about 30 minutes or longer
What is the expected behavior? (add screenshot)
What went wrong? (add screenshot)
Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):
look, version is 2.3, please update to 2.5 and above.
e.g: 2.5.207, 2.6.347
**1. this.fontLoader.bind(font).catch(...).finally is not a function.
You can also use the following code to deal with the compatibility of pdf used promises
(function() {
// Get a handle on the global object
var local;
if (typeof global !== 'undefined') local = global;
else if (typeof window !== 'undefined' && window.document) local = window;
else local = self;
// It's replaced unconditionally to preserve the expected behavior
// in programs even if there's ever a native finally.
local.Promise.prototype['finally'] = function finallyPolyfill(callback) {
var constructor = this.constructor;
return this.then(function(value) {
return constructor.resolve(callback()).then(function() {
return value;
});
}, function(reason) {
return constructor.resolve(callback()).then(function() {
throw reason;
});
});
};
local.Promise.prototype['allSettled'] = function allSettledPolyfill(promises) {
return new Promise(function(resolve, reject) {
if (!Array.isArray(promises)) {
return reject(
new TypeError("arguments must be an array")
);
}
let resolveCounter = 0;
const promiseNum = promises.length;
const resolvedResults = new Array(promiseNum);
for (let i = 0; i < promiseNum; i++) {
Promise.resolve(promises[i]).then(
function(value) {
resolveCounter++;
resolvedResults[i] = value;
if (resolveCounter == promiseNum) {
return resolve(resolvedResults);
}
},
function(reason) {
resolveCounter++;
resolvedResults[i] = value;
if (resolveCounter == promiseNum) {
return resolve(resolvedResults);
}
}
);
}
});
}
}());