cancel
Showing results for 
Search instead for 
Did you mean: 
Surveyor II

Can students view a PDF in their browser?

Jump to solution

All modern browsers can display PDF documents natively, without the need for an external viewer application.

Inserting a PDF document into a Canvas Page seems to circumvent that--viewers are allowed only to preview the PDF within the page (magnifying glass icon) or to download the PDF (either the pop-out icon or clicking on the text link).  (Personally, I don't find the "preview in the page" option to be very useful, perhaps because of the structure I like to include on my pages.)

Is there a way that I can give back to my students the ability to view PDF documents in their browser?

2 Solutions

Accepted Solutions
Adventurer III

Hello, mclean@geneseo.edu. The PDF displayed natively in the browser is actually done via an add-on that is supported by all major modern browsers (unless it came from Microsoft) and is installed as a component of the Adobe Reader software. Furthermore, the file displayed is actually a cached copy of the file already downloaded to the users' computer. If you download the PDF and open it directly from the browser Downloads area, in most cases it will open in the browser the same as if you were to access a PDF from another website (I've confirmed this is the case on three computers using Chrome and Firefox).

The only difference is that in Canvas the user is aware they are downloading the PDF whereas outside of Canvas they are not. Really, the end result is the same.

As for making the default functionality the same as what is normally experienced from other websites, I don't know of any way to do so. Disabling the inline viewer doesn't allow accessing the file to load with the default browser action. My guess is that this is caused by the functionality of the files management system, which uses the file ID to, essentially, pull the file via a proxy. The browser doesn't know what it's getting until it has it, and then it's too late because the default functionality for generic file downloading will have already executed.

View solution in original post

wilmer.prentius@slu.se‌,

Thank you for this information! I see the same headers as you:

content-disposition:

attachment; filename="Cornell_Notes.pdf"

content-type:

application/pdf

In other words, the browser is told that the content is a pdf, but the server is saying that it should be downloaded.

You mentioned that there may be a way to override this behavior locally. Do you have a suggestion that does not involve modification to the server? According to my research, there is no way to override the server from a web page.

View solution in original post

0 Kudos
17 Replies
Adventurer III

Hello, mclean@geneseo.edu. The PDF displayed natively in the browser is actually done via an add-on that is supported by all major modern browsers (unless it came from Microsoft) and is installed as a component of the Adobe Reader software. Furthermore, the file displayed is actually a cached copy of the file already downloaded to the users' computer. If you download the PDF and open it directly from the browser Downloads area, in most cases it will open in the browser the same as if you were to access a PDF from another website (I've confirmed this is the case on three computers using Chrome and Firefox).

The only difference is that in Canvas the user is aware they are downloading the PDF whereas outside of Canvas they are not. Really, the end result is the same.

As for making the default functionality the same as what is normally experienced from other websites, I don't know of any way to do so. Disabling the inline viewer doesn't allow accessing the file to load with the default browser action. My guess is that this is caused by the functionality of the files management system, which uses the file ID to, essentially, pull the file via a proxy. The browser doesn't know what it's getting until it has it, and then it's too late because the default functionality for generic file downloading will have already executed.

View solution in original post

It is not true that browsers require the Adobe add-on to display PDF.  See View PDF files in Firefox | Firefox Help and How to disable Chrome's PDF viewer - CNET  and Safari for Mac: View PDF files with Safari .  True, many users have installed Adobe Reader, which may have replaced the browser-native viewer with the Adobe product, very likely without the user being aware of it.  This is more likely to happen on a Windows machine, since Macs already have the system-provided Preview app, which largely makes Adobe superfluous.

When a PDF is viewed, the PDF file of course must be stored somewhere locally.  However, when using the browser-native viewer, that place is the browser cache, not the Downloads folder.  (Just confirmed in Firefox and Chrome on a Mac; Acrobat Reader installed, but not the default application nor inserted into browsers.)  Usually, the cache is not easy to access.  I fully believe that for you PDFs accessed from your hard drive open in your browser window, but I'm skeptical that is the experience for "most cases."  It certainly isn't mine.

But all this technical stuff is background to the user experience.  For many users, the difference is more cumbersome than simply being aware of a download.  In my specific case, after clicking on the link, I must interact with a download dialog (choose to save the file or or open directly in a application), then switch to an external application.  Am I correct that you are saying that for you, the experience is not "what is normally experienced from other websites"?  Why would we want a system that is both unfamiliar to the students and less streamlined?

I apologize that my response was incorrectly marked as the "Correct Answer". It was not my intention that it be so, or to provide you incorrect information. My response was based off of my experiences over two decades in IT and was not aware you were specifically concerned with Apple systems (nearly every issue I work on is Windows-based ^^').

Having said that, I'm afraid that my experience with Mac OS X is limited due to its lack of use in comparison to the combined use of Windows and other forms of Linux. I do, however, have a Mac, so I pulled up a test PDF (http://che.org.il/wp-content/uploads/2016/12/pdf-sample.pdf) in Chrome on it without any Adobe software installed and it downloaded the file. When I tried to open it, the system erred: There is no application set to open the document "pdf-sample.pdf". The same happened in Safari, too. This may, however, be affected by whatever restrictions our IT department put on the Mac to bring it within their standards. I can test Windows/Linux outside of those restrictions from my personal system, but I don't own anything Apple. ^^'

With regards to forcing this behavior, regardless of what system/browser configuration you have, as far as I'm aware there is no way to do so while storing the file in the Canvas system. As you commented a little further down, a third-party web server to store the file on is your best possibility. At our institute, we use one for files and major components used in courses that run frequently or are simply too large to reasonably have copied into every course shell made, though PDFs stored there are usually not because of their size.

Regarding your concern about the file system producing an experience uncommon to the general Internet experience, it's less a matter of user experience (which I agree is important) and more a question of functionality and security (which, in this case, I'd say is equally important, if not more so). The file system, as it is, makes it impossible for the average user to get any meaningful information about files without acquiring each one while maintaining a uniform access point that is applicable to all file types. Of course, a knowledgeable user could use the API to retrieve information that would allow for targeted file acquisition, but if the files are restricted properly, the system won't provide any information not intended to provided (i.e., the answer key to the final exam).

Simply put, the file system provided gives a uniform experience for all file types loaded into Canvas with additional security restrictions that are much more difficult to implement without the intermediate between the user and the file. It changes the expected experience compared to much of the public Internet, but provides security that has become an expected component in professional environments from schools to major corporations.

First of all, sorry for bringing up an old topic, but I can't find that there's been any updates regarding this issue.

I believe that the problem with the behavior is that the content type in the response header is specified as "text/html", why the browser isn't able to recognize that the requested file is a previewable PDF. This StackExchange thread describes the headers quite good, I think.

wilmer.prentius@slu.se‌,

I am coming to the same conclusion, and I would like to be able to definitively describe the problem to both Canvas and our IT support staff. Do you know how to show that the content type in the response header for the pdf download is "text/html"? From my tests it is clear that Canvas is overriding the browser user preferences with respect to pdf display. 

My understanding is that if the problem is the HTTP headers, there is no way to override this behavior other than a change in the server.

Melissa

Hi mah11@cornell.edu,

I see now that the problem probably isn't the "content-type", but rather the "content-disposition" header, that's specified to "attachment" instead of "inline".

If you're using Chrome, you can the headers by opening "Inspect" (Right click or Ctrl+Alt+I), going to the "Network"-tab and clicking the pdf of interest. In the list to the left, you should see the request and response (you may also filter on "Doc").

It's probably possible (but hacky) to override this behavior locally, but to change the behavior of Canvas, there'd need to be some update.

wilmer.prentius@slu.se‌,

Thank you for this information! I see the same headers as you:

content-disposition:

attachment; filename="Cornell_Notes.pdf"

content-type:

application/pdf

In other words, the browser is told that the content is a pdf, but the server is saying that it should be downloaded.

You mentioned that there may be a way to override this behavior locally. Do you have a suggestion that does not involve modification to the server? According to my research, there is no way to override the server from a web page.

View solution in original post

0 Kudos

What I meant was that it's probably possible to override your browser's behavior when getting an "attachment" header for a pdf-file (thus the mention of hacky). There's probably some chrome-extension that allows you to do this.

Surveyor II

As explained in my reply, the answer from Christopher Esbrandt is incorrect in several respects.  I am too new to this system to know who marked it as a "Correct Answer."  Is there a way to reverse that?