Problem with PDF Article Download and Reading Tools

[dcwyant]

We have one article that has gone rogue and opens in an independent window.

Two articles in our first issue are behaving well. The abstract opens in a window with the reading tools pane on the right side (although you have to scroll to the right to find the tools -- How do we modify the pane size?). When a reader clicks on the PDF link at the bottom of the abstract, the PDF opens within the page frame with reading tools on the right. (Intermediate page says "Portable Document File will download automatically. If not, click here to begin manual download.")

The third article's abstract opens in the frame with reading tools on right. However, when reader clicks on link for PDF file, the PDF opens in a new window --no reading tools. The intermediate page for this article says "Article Download" rather than "Portable Document File..."

All PDFs were created on the same computer and final drafts were uploaded as Layout Galleys. I've tried creating and uploading a new PDF for the third article, but the problem persists.

This switcheroo has me mystified. We've disabled all the reading tools, but that did not affect the different opening styles. We're ready to launch as soon as this bug is worked out.
Diane

[jmacgreg]

Hi Diane,

Try checking the galley/galley type on the submission's Editing page, in the Layout section. If the galley format reads as anything else besides "PDF" exactly (eg. "PDF ()") you may be dealing with an incorrectly uploaded/completed galley file, and will have to delete and reupload the galley. If it's not that, please let me know and I can investigate further.

Cheers,
James

[dcwyant]

Thanks James. I'm posting an update for others that might encounter this problem. Although the OJS system recognized the file as a PDF and labeled it as such, the PDF was not loading correctly because (I think) of "hidden customized XML data." I went back to the Word document and ran the Document Inspector protocol to remove hidden data. Hidden Customized XML repeatedly showed up and it took several rounds of the Document Inspector to finally remove it (that was a first, once usually does the job). Using the scrubbed Word document, I created a new PDF, which uploaded correctly and displayed within the page frame.
Anyone needing more information on using the Document Inspector to remove hidden data can find the instructions on the last page of our journal's directions for Ensuring a Blind Review http://ssw.unc.edu/jif/jsswr-docs/BlindReview.pdf

[jmacgreg]

Hi Diane,

Thanks for sharing that with us. I haven't heard of that kind of problem before; I'm sure that the steps you have laid out will be of help to others.

Cheers,
James

[mgscano]

Hi all,
just to add my usual 2c .. I'm running into the same visualization problem, but I have screened another cause: the PDF galleys do are correctly identified as PDFs, but the server states its file type as "binary/octet-stream" instead of "application/PDF".

I'm trying to understand how to work around this, as I'm not 100% certain it is an Apache problem. If I have news I'll update this page as quick as I can.

bye,

[asmecher]

Hi Marco,

Have you checked the article_files table to see whether or not the MIME type is correctly identified there?

Regards,
Alec Smecher
Public Knowledge Project Team

[mgscano]

Hi Alec,
that's turning out to be the problem, indeed.

When I look into the database, many files have uneven and inconsistent file type identification, and this is not only with PDFs. Also ms Word documents are sometimes identified as application/octet-stream or sometimes even as application/force-download (this sounds quite new ...).

I'm trying to understand what goes wrong with the production site, because as usual, in my local development VMs everything works smoothly.

Will update this thread as I make some progress, stay tuned.

bye