Pdf.js: ios rendering pdf long time, about 30 minutes or longer, pdf use font STSong and MSung, Can anyone help me?

Created on 5 Nov 2020  ·  8Comments  ·  Source: mozilla/pdf.js

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:

  1. pdf file use font STSong and MSung
  2. 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):

All 8 comments

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:

  1. pdf file use font STSong and MSung
  2. 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

Error when the code is running, e.g.

**1. this.fontLoader.bind(font).catch(...).finally is not a function.

  1. Promise.allSettled is not a function**
    update you project node_modules/zone.js pkg

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);
                        }
                    }
                );
            }
        });
    }
}());
Was this page helpful?
0 / 5 - 0 ratings

Related issues

liuzhen2008 picture liuzhen2008  ·  4Comments

smit-modi picture smit-modi  ·  3Comments

sujit-baniya picture sujit-baniya  ·  3Comments

patelsumit5192 picture patelsumit5192  ·  3Comments

BrennanDuffey picture BrennanDuffey  ·  3Comments