pdf viewer does not work
i only can download it
i need to view pdf
please help
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.
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.
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.
Finally solved this (took a while )
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.
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