Pdf not display

pdf viewer does not work

i only can download it

i need to view pdf

please help

Hi @rambod75,

Which of our applications are you using, and what version? (Please include this in your posts.)

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher

I’m using latest version OJS 3.0.2

Hi @rambod75,

Is your website available somewhere for me to test?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher

thanks for helping me

https://www.scigatejournals.com/publications/index.php/ijap/article/view/210/148

Hi @rambod75,

Have you checked your PHP error log?

Regards,
Alec Smecher
Public Knowledge Project Team

hi @asmecher

i’m using direct admin and it has no php error log, however i put debug mode on but no errors display

what should i do?

This probably indicates a PHP fatal error, which will not be reported with debug, but will be caught in your webserver’s error log. Are you sure there is “no php error log”? That seems highly unlikely.

Hi @asmecher and @rambod75

It looks as if different browsers behave differently!
My site Contributions to Entomology (completely new, thanks OJS!) uses OJS 3.0.2.
With Firefox (52.2.0), the PDF of an article is displayed in the reading tool, but not with Internet Explorer (11.0.9600) and Google Chrome (60.0.3112.101). The link to download the PDF works however.

Regards egroll

Hi @egroll,

It looks like the PDF request is returning with a 416 error. I’m not familiar with this HTTP status code, so you’ll need to do some research and maybe coordinate with your web host to see if they can determine the source of the problem.

I noticed that you have some CORS errors on your site. It looks like the links to FontAwesome fonts are still tied to a development domain (http://ojs.ub.uni-frankfurt.de/beitraege_entomologie/lib/pkp/fonts/fontawesome/fontawesome-webfont.woff2?v=4.3). You might want to clear the CSS cache on your site to generate the CSS fresh at the new domain, so that those URLs point to the live site.

I don’t think this is related to the PDF issue. But I really don’t know what causes a 416 so couldn’t say for sure.

I researched this issue in Contributions to Entomology, cleared the cache (thanks for the remark) and found that in the display.tpl of the pdfJsPlugin, the PDFJS.getDocument() routine throws this error.

As far as I understood the main work is done in the #pdfCanvasContainer-div. This streams the file through the viewer.html, where also all the necessary elements for the viewport are located. However, all these necessary inputs are not found when PDFJS.getDocument tries to get the PDF, because they are not in the display.tpl (and hence they cannot be found via getElementById()). When getDocument() tries to load, for example, document.getElementById(‘viewer’) or document.getElementById(‘viewerContainer’) the loaded values are “null”.

I am no expert on JS and hence have difficulties in finding a solution for this issue.

Interestingly, when simply commenting out the lines 52 - 75 in the display.tpl on my local Linux machine, the PDF is shown properly and the error is gone. Unfortunately, on the server this does not work. :confused:

Any suggestions @NateWr?

Okay! Spend some more time on this issue.

The 416 error is there, because the Browser (Chrome or IE) expect that the server supports range requests (which it seems to not do and the server does not explicitely communicate this). Due to this miscommunication the browser makes a range request (asks for only a part of the whole document), but the server cannot grant this. This seems to be a known bug at least in Chrome, but even with Chrome 62 the error (on a Windows machine) still occurs.

Just in case someone should stumble over this issue in the future.

1 Like

Finally solved this (took a while :expressionless: )

Create an .htaccess file in the OJS-directory (if not already present). Then add (simply copy/paste in the first line):

Header set Accept-Ranges none

Additionally, the Apache headers module needs to be enabled typing to the Linux command prompt:

a2enmod headers

Then restart (or only reload?) the server. Now the PDF should be loaded in Chrome. :slightly_smiling_face:

Hi @GrazingScientist,

Would you be willing to try an alternate solution? This will be a little more future-proof and less finicky, and should be a one-line addition.

Edit lib/pkp/classes/file/FileManager.inc.php and find the downloadFile function:

function downloadFile($filePath, $mediaType = null, $inline = false, $fileName = null) {

Find the header lines in it (around line 250 in the file):

header("Content-Type: $mediaType");
header('Content-Length: ' . filesize($filePath));
header('Content-Disposition: ' . ($inline ? 'inline' : 'attachment') . "; filename=\"$fileName\"");
header('Cache-Control: private'); // Workarounds for IE weirdness
header('Pragma: public');

Add the following new line to this set:

header('Accept-Ranges: none');

Please let me know if this resolves the issue, or if you’re not able to try it out, and I’ll make sure it gets included in future releases.

Regards,
Alec Smecher
Public Knowledge Project Team