Pdf article view fails in 2.4.6

We have noticed in the new version, pdf articles can not be viewed graphically even if we have the adobe pdf plugin installed in the browser. This was not an issue in earlier versions.
I have tested on Firefox and Chrome.
(Reading Tools is eanbled)

Also I have noticed the function called isHTMLGalley always returns true. Is it supposed to be like that? I changed that to false just to test, and still pdf article was not displayed in the page. It is a blank frame.

Thanks
Ghazal

Hi @salehig,

Have you tried the PDF.js plugin? That’s newly introduced and replaces the previous method we had of embedding PDFs; that older approach was no longer working on all browsers. I’d suggest trying that plugin.

If your journal is public, can you share a URL with me?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

I tried pdf.js too. However I just noticed there is an error in the page complaining about security which surely prevented all of embedded viewer, pdf.js, google viewer to work properly:

“Mixed Content: The page at ‘https://dev-demo1.library.qut.edu.au/article/view/173/215’ was loaded over HTTPS, but requested an insecure script ‘http://www.google.com/jsapi’. This request has been blocked; the content must be served over HTTPS.”

I noticed it had been mentioned in the old forum before also:
http://pkp.sfu.ca/support/forum/viewtopic.php?f=8&t=12860

However no solution was proposed at the end.

Also in the installation notes of pdf.js had been mentioned it is developed for ojs v3.0.0 plus. Is it fine to install in on 2.4.6?

And again as I mentioned it works properly in some older versions (2.3.7)

I changed all the references to http://www.google.com/jsapi to https. That error is gone. However when enabling pdf.js below error occurs:

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help, check http://xhr.spec.whatwg.org/.
pdf.worker.js:1690 The provided value ‘moz-chunked-arraybuffer’ is not a valid enum value of type XMLHttpRequestResponseType.
pdf.worker.js:250 Error: stream must have data
pdf.worker.js:252 at error (https://dev-demo1.library.qut.edu.au/plugins/generic/pdfJsViewer/pdf.js/build/pdf.worker.js:252:15)
at assert (https://dev-demo1.library.qut.edu.au/plugins/generic/pdfJsViewer/pdf.js/build/pdf.worker.js:267:5)
at Object.init (https://dev-demo1.library.qut.edu.au/plugins/generic/pdfJsViewer/pdf.js/build/pdf.worker.js:2859:5)
at Object.PDFDocument (https://dev-demo1.library.qut.edu.au/plugins/generic/pdfJsViewer/pdf.js/build/pdf.worker.js:2850:12)
at new LocalPdfManager (https://dev-demo1.library.qut.edu.au/plugins/generic/pdfJsViewer/pdf.js/build/pdf.worker.js:2458:24)
at Object.onDone (https://dev-demo1.library.qut.edu.au/plugins/generic/pdfJsViewer/pdf.js/build/pdf.worker.js:33610:26)
at Object.NetworkManager_onStateChange [as onStateChange] (https://dev-demo1.library.qut.edu.au/plugins/generic/pdfJsViewer/pdf.js/build/pdf.worker.js:1800:24)

Our site is not public view yet. Only work in the internal network at the moment. Sorry about that.

Best Regards
Ghazal

Hi @salehig,

The master branch is for OJS 3.0 (the beta is about to be released), but there’s a branch for OJS 2.4.x and also a release .tar.gz file you can download.

Note that you can use protocol-relative URLs; just start them with the // part of the URL (leaving out the http: or https:).

Regards,
Alec Smecher
Public Knowledge Project Team

@asmecher,

I installed the 2.4.X version of the plugin. Didn’t help.

Errors on the page:

synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience. For more help, check http://xhr.spec.whatwg.org/.

The provided value ‘moz-chunked-arraybuffer’ is not a valid enum value of type XMLHttpRequestResponseType.

Error: stream must have data

Hi @salehig,

Does the “download PDF” link work?

Regards,
Alec Smecher
Public Knowledge Project Team

Hi,

No it doesn’t.

Cheers
Ghazal

Hi @salehig,

That’s the first thing to debug, then. I suspect your files_dir in config.inc.php is wrong, or perhaps you’ve got a file permissions problem there.

Regards,
Alec Smecher
Public Knowledge Project Team

I found out there was a similar issue with OMP in the past:

https://pkp.sfu.ca/support/forum/viewtopic.php?f=40&t=12055

Can it be the same problem?

I’ve tracked this down to the PDF embedding javascript dying silently when PDFs are sent by OMP with a content-disposition header describing it as an attachment (this is useful for file downloads). I’ve made a change to the PDF embedding plugin and surrounding code to exclude the header when the PDF is being embedded.

Hi @salehig,

If that were the problem, then the “download PDF” link would work but the embedded view would not. I think you’re encountering something different.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi

I tired to do more investigation, but I haven’t find a clue yet.
We have some other dev sites in 2.3.7. I noticed that in one of them from a specific journal issue onward no pdf version is shown, but before that all of them are being shown. (with having pdf.js and google viewer disabled). No error is logged.

I was wondering can it be related to something that is missing in the editing process of them, or something which related to publishing.

I’d really appreciate if you give me some hints to look into.

P.S. files directory and its permissions in fine (writable by all)

Best Regards
Ghazal

Hi @salehig,

I would suggest adding some error_log calls to pkp/lib/classes/file/FileManager.inc.php in the downloadFile function. This will tell you where OJS is trying to access the file on the server, and might give some hints on where specifically to start tinkering.

Note that 777 file permissions are never safe to use and shouldn’t be necessary.

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks Alec. I’ll try that.

Regards
Ghazal