Pdf.js: IOS can't render certain PDFs

I checked the pdf listed above in the web viewer

First I check if it works with other pdfs with this pdf:

In Safari:

In Google Chrome:

Then, I attempt to open the specified document in Safari:

Attempt to open the specified document in Google Chrome

I also found that if I try to open the working pdf with the web viewer after having tried to open hanyan123's pdf, the working pdf no longer rendered.

In Safari:

In Google Chrome:

We've also run into this problem with another document on iOS: https://tcpdf.org/files/examples/example_033.pdf (1-page PDF)

After investigating we did get some additional info on this error:

• It is also reproducible in desktop Safari (v. 11.0.3 (12604.5.6.1.1), macOS 10.12.6) using the hosted viewer at https://mozilla.github.io/pdf.js/web/viewer.html.
• The documents DO load (both the one linked above and the one linked by @hanyan123) but it takes a very long time (approx. 5-10 minutes).

I have observed something similar, although in my case, I've never seen the document display even after waiting. I described my observations on StackOverflow - I'll repeat my question here, along with someone's cogent response:

I have a two page pdf document that does not render on either Safari or Chrome on iOS, using pdf.js; there are two pages, but they both are blank. If I "print" the document with CutePDF to another pdf, it renders! But if I optimize using Acrobat PRO, it does not render. I read somewhere that if I render as Postscript with Acrobat PRO, and then resave as pdf, that linearizes; still no love. I show all four flavors here - the thumbnail shows the pdf metadata, along with the file size. Only the CutePDF version renders, even though it is not the smallest. Apart from simply reprinting every pdf I have on my website with CutePDF - can someone tell me what pdf.js is unhappy about?

N.B.: All four flavors render under Windows. It's only iOS that has the problem, with three of the four.

Here's the response:

All the non-working versions have the bitmap drawn as a single large XObject wrapped in a pattern. The working version has the bitmap cut into many smaller images drawn directly in the page content. You may want to look for pdf.js issues related to those factors.

CutePDF doesn't provide the option to control the bitmap that way - it just does it. What is it about a "single large XObject wrapped in a pattern" that pdf.js doesn't like - and, how can I control, e.g., Acrobat PRO to render as CutePDF does (if that's the workaround)?

I have observed something similar, although in my case, I've never seen the document display even after waiting. I described my observations on StackOverflow - I'll repeat my question here, along with someone's cogent response:

I have a two page pdf document that does not render on either Safari or Chrome on iOS, using pdf.js; there are two pages, but they both are blank. If I "print" the document with CutePDF to another pdf, it renders! But if I optimize using Acrobat PRO, it does not render. I read somewhere that if I render as Postscript with Acrobat PRO, and then resave as pdf, that linearizes; still no love. I show all four flavors here - the thumbnail shows the pdf metadata, along with the file size. Only the CutePDF version renders, even though it is not the smallest. Apart from simply reprinting every pdf I have on my website with CutePDF - can someone tell me what pdf.js is unhappy about?
N.B.: All four flavors render under Windows. It's only iOS that has the problem, with three of the four.

Here's the response:

All the non-working versions have the bitmap drawn as a single large XObject wrapped in a pattern. The working version has the bitmap cut into many smaller images drawn directly in the page content. You may want to look for pdf.js issues related to those factors.

CutePDF doesn't provide the option to control the bitmap that way - it just does it. What is it about a "single large XObject wrapped in a pattern" that pdf.js doesn't like - and, how can I control, e.g., Acrobat PRO to render as CutePDF does (if that's the workaround)?

Any update on this issue? I have also encountered it.