Users Can't Open PDFs

[AmandaGal]

On the following page, we're getting complaints from users who are unable to download the documents (pdf files). I thought it was the server, so I posted an alternate link and we're still getting complaints.

<snip>

I've suggested downloading the files and open them outside of the browser, but our user base is not very computer literate and I think most of them are downloading inside the browser (which I know can lead to all sorts of Adobe Reader issues).

Any suggestions on how to fix the problem?

[edited by: incrediBILL at 2:59 am (utc) on Dec 10, 2011]
[edit reason] removed link, no site reviews [/edit]

[penders]

Like you, I would guess this was user error and they are perhaps opening, rather than saving the document?

Do you know which browsers they are using that are causing these problems?

You could perhaps force the browser to download the file (when they simply click the link), but you will need to send the appropriate response headers server-side using PHP?

[Hoople]

I just checked the top document. The 'PDF version' is 1.5 (6.x). On my Windows7 PC I have Adobe Reader version 9. Over time the PDF version changed making older reader versions unable to read newer PDF version files. The PDF version doesn't track with the reader version further complicating the understanding of PDF usage.

It could be the users having difficulty have older PDF readers. They would get a message about the file being corrupt IIRC.

The easiest workaround would be to update your link to adobe to http://get.adobe.com/reader/otherversions/ [get.adobe.com] so they get just the reader and not the force-fed McAfee (where your link leads). It could be part of their frustration and stopping them from upgrading.

I would change your first two sentences to:

You will need a current version of the Adobe Reader to view these files. If you need to get it or upgrade your current version you can download it for free from Adobe Systems.

Not knowing your file uploading method leaves one guess --- FTP as 'text' may make them unreadable. FTP as 'binary' could fix it. Gather the file specifics (which link) and error message if this goes beyond the reader version update.

Oh, and welcome to WebmasterWorld AmandaGal!

[penders]

...so they get just the reader and not the force-fed McAfee (where your link leads)

It seems that this link also prompts with the additional McAfee checkbox, once you've actually picked an Adobe Reader version to download.

----

Are the users actually downloading the file, but failing to open it? Or failing to even download it? I was assuming the later?

Another thought... if their browser is configured to download automatically to a certain folder and not prompt (as I believe Chrome and Safari are set up by default?), then they may not realise they have downloaded the file, or where it might be located?! I have found this to be surprisingly common among the less tech-savvy.

[lucy24]

You can fine-tune some things but in the end it will often down to "The problem is on your side". Not a happy resolution.

The good news: "Not very computer literate" means they are probably using whatever browser came with the computer, so you don't get the extra problems that come with having multiple browsers installed.

Concrete example: Safari has a built-in PDF reader which works nicely. But if you have plug-ins installed for other browsers, Safari will try to use them, resulting in an unreadable PDF. Unfortunately Safari doesn't let you disable individual plug-ins; it's all or nothing :(

[tangor]

@AmandaGal, welcome to Webmasterworld! Have to ask the obvious question, you've tested the downloads from the site? Can't go by what your local dev machine displays... too much is already in cache to give good results.

Second question: Why PDF? (I use them, but I also offer an HTML version as well)

Your PDF's are really LARGE (not in words, but in non-optimzied Graphics and use of Embedded Fonts) and even over a fairly quick broadband the files hesitate or load slow... might be folks are too impatient and click the back button (Turtle 2011, example)

[lucy24]

!
Where are you getting the pdfs? If you're using the Mac's built-in PDF generator, there is a HUGE difference in filesize between different browsers' output. It isn't a webkit issue; in the test* I ran, Chrome's PDF came out six times bigger than Safari's. Others are in between.


* This is fortuitous. I was recently yakking about a related issue with my father, and made a packet of PDFs from the same HTML file to experiment.

[penders]

If you're using the Mac's built-in PDF generator, there is a HUGE difference in filesize between different browsers' output.

How do you mean? (I'm not too familiar with Macs.) Filesize in what the end user sees when viewing the PDF in the browser? Or filesize when actually creating the PDF (in browser?)? Having looked at a few of the PDFs, they seem to have been generated mostly with InDesign CS3/CS4.

[lucy24]

I mean filesize in kilobytes. Like this (reading the numbers off my HD):

Original html file: 156K plus a few K of external stylesheet.

PDF:
created by Safari 389K
created by Opera 946K
Firefox and Camino, both 1.1MB
Chrome 2.2MB (!)

They all look the same except that only Safari and Opera show the background colors of table cells-- but this may have been my fault for forgetting to change a default.

I also have versions made by TextEdit, either directly or via Safari, but these got horribly mixed-up in the horizontal alignment. (It's a series of grammatical tables.) Conversely, both Opera and the Mozillas got confused and ate part of the Index, which is in three columns. I may be able to fix this by using more redundancy in the CSS.

The visual size is based on display in the browser that created the PDF. So Opera's version comes out a little smaller (in display size and hence pagecount) because it won't let me set a 15pt font size so it's at 14.

It is probably not surprising that Safari does the best job, since it's the most intimately connected with the OS.

Mac-generated PDFs are fully searchable-- at least in Roman type-- but they do not preserve internal links (# fragments), only complete links in http://

[SteveWh]

Although it doesn't address the actual problem, one workaround would be to pack the .pdf into a .zip, which all browsers should save and not try to open.

Unfortunately, there might be some users who don't know what to do with a .zip file or who will consider the extra step a nuisance.

[AmandaGal]

Thanks for the advice. I'm going to try to get the person who designs the PDFs to optimize them a bit more, and see if that helps. I'll also change up the wording on the page a little. I think people's brains would explode if I offered a zip file. I was suspecting more user error than problems with the page, which sucks. I wish there was something I could easily fix.

[4serendipity]

lucy24, I also have noticed how bloated pdfs from chrome are. I haven't spent the time to dig into things and figure out where all of the added bloat is coming from, but those made with Acrobat Pro or PDFcreator are much, much smaller.