Dato PDF link does not render on mobile device

🆘 Support
1

Hi,

I have a PDF link that does not work on mobile devices [https://www.datocms-assets.com/104850/1723706611-sol-1h24-appendix-4d-financial-report.pdf].

What happens right now when you go to that link on a mobile device, is that, it renders the PDF in a split second and then redirects, and then shows a 404.

I was wondering if this has to do with the PDF itself or how DatoCMS delivers the PDF (some sort of anomaly) in the API.

Warmest, Carl.

2

Hey @solutions (Carl),

Thank you for the report! Unfortunately, at first glance, I can’t seem to replicate this on my own phone (Pixel running Android). Could it be a matter of your phone’s default settings for PDF files (handlers, etc.)?

Some thoughts:

  • What kind of phone(s) are experiencing issues? Knowing their platform, OS version, browser, etc. would help.
  • Which app is configured to open PDFs on those phones?
  • Can anyone else in your organization access that PDF from their own phones?
  • Can you yourself access it through an Incognito/InPrivate window?
  • Can you access that same PDF if it’s sent to your phone some other way (via file share, email, etc.?)
  • Can the phones having problems with that link access any OTHER PDFs in your project, or any PDFs in general?
  • Does it matter if you copy & paste the URL directly vs clicking on it from your frontend? If it’s only happening on your frontend, could you please share that page with us?

I can’t think of anything at the network level that would normally cause a PDF to successfully download and render and then redirect elsewhere… normally if it’s a HTTP redirect or similar, that would happen before the PDF ever downloads.

I wonder if this might be a configuration thing (or maybe even malware…? hopefully not…?) on that phone itself. If you can provide a bit more information, please, we can take another look?

3

Hi @roger,

Cheers for the reply.

I am using an iPhone 13, and am attempting to open it on Safari and Chrome. I tried both incognito and non-incognito. This isn’t limited my own device.

Other PDF’s render fine on the website such as this [https://www.datocms-assets.com/104850/1700545642-soul_patts_2023_sustainability_report.pdf]. It just seems to be the link in the initial thread that has this anomaly.

On your end, can you test against both PDF’s (upload them) and see if it might have something to do with the PDF itself.

Warmest, Carl.

4

Thank you, @solutions! I’ll try to replicate on similar devices.

Can I also, ask, please, if you’re opening these PDFs by clicking through them from a website? Can you share that website URL with me, please?

Or are you just accessing the links directly somehow (like copying and pasting them into the URL bar)?

5

Also, do either of these load for you on that same phone?

Test #1: The same URL with a query string attached

Test #2: The same PDF copied to another project

6

Hi @roger,

These still don’t work.

We’ve managed to figure it out, and the problem stems from the PDF itself. It had to with the content in said PDF (namely the gradients).

I think this is something to consider when there are certain PDF’s that may cause this issue.

Thanks again,

Carl.

7

Hey @solutions,

Thanks for the update! I was just about to write you back too. It appears to be a bug in iOS PDF handling, as far as I can tell. I hooked up an iOS device to a debugger and everything from the network level seemed fine, so it doesn’t seem to be an issue with DatoCMS or our CDNs (Cloudflare, in this case).

Conversely, that file by itself also crashes the PDF viewer even when it’s on the iOS device itself and opened locally, bypassing DatoCMS altogether.

It also crashes when I put it on another file host for testing.

It does open fine on 3rd-party PDF viewers (like the Google Drive PDF viewer) when the rendering pathway is bypassed.

It also loads fine on an iOS simulator on a Mac (which isn’t 100% the same as a real iOS device). This all suggests to me, as you’re noticing, that it’s probably the PDF itself :frowning:

I don’t think that’s something we can detect and fix on our end, since we only handle the network traffic and not the content within the PDFs. We wouldn’t be able to scan it and make sure it works. This may be an issue between Adobe and Apple to resolve…

FYI, I was able to get a working version by running your PDF through the macOS Preview app and then exporting it as PDF/A (which embeds all graphics, etc.), as in: https://www.datocms-assets.com/138875/1724043405-pdf-a.pdf

It does result in a larger file size, though. I think in Acrobat or InDesign you can process the PDF into an earlier or lighter sub-version of PDF (like the “Print Optimized version”). That may or may not help?

I don’t believe there is anything more we can do on this front. Do you? If you have any ideas, I can pass them along, but as far as I can tell, this is an Adobe/Apple PDF rendering issue, not a CMS/CDN glitch. Does that seem like a fair assessment to you?

8

Hi @roger

Fair enough in regards to that.

I think we can mark this as resolved. Thanks again.

Warmest, Carl.

1 Like
9

Great, thank you! I did share this with our team just so they are aware of it – it’s an interesting edge case for sure.

I hope reprocessing it in InDesign/Acrobat will fix it for you, in the interim. It may be worth a bug report to Safari and/or Chrome too, if you’d like (I’m not sure if they same the same renderer on iOS… my understanding is that Chrome on iOS is still just Webkit, i.e. a reskinned Safari).