Feature Request: Readers should be able to view content in browser

[jayyx2]

I am investigating this for our case and am glad to discuss it further.

Problem

• Users may not have a program available to open all of the supported file types

Proposed Solution

• Change submission list to have Download and View links + buttons

Potential approaches

• Add another condition to download.php to allow for viewing
• Add new functionality to existing upload process to store text as HTML (preserve as much formatting as we can) and then view button calls the html using popup.js

Other uses?

• Keep a word count and enforce a word count limit on certain genres

[devinemke]

@jayyx2 Hmm, not sure about this one.

What exactly a browser does with various file types is (for the most part) up to that browser and how it is configured.

For example: in the latest version of Firefox for macOS (with no changes to the file handling settings, all default) when a submission of a PDF file is clicked in SM, the file opens immediately in a new tab, ready to be viewed.

This behavior differs with other browsers (and their default settings). A quick test of the same PDF in Chrome downloads the file, and then offers a clickable button to open (on the lower left) and is then opened by Chrome (again in a new tab).

In Safari, the file is similarly downloaded, and then you can click to open (upper right, in the download history) and the PDF is opened in whatever app is configured in the OS to handle PDFs (Preview by default, presumably Acrobat if it is installed).

Furthermore, it appears that many modern browsers offer something like Always open file of this type once you have downloaded the first, making this more streamlined going forward.

If you are downloading a less common file type, one for which neither your browser nor your OS know what to do with (no default associated app) then the file will be downloaded, and then when clicked the OS will prompt to ask which app to use, and possibly suggest an external (not yet installed) app.

SM's download() function (located within inc_common.php) uses these HTTP headers:

header('Content-Description: File Transfer');
header('Content-Type: ' . $type);
header('Content-Disposition: attachment; filename="' . $file . '"');
header('Content-Transfer-Encoding: binary');
header('Expires: 0');
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
header('Pragma: public');

... where $type and $file are passed function arguments to tell the browser what kind of file to expect.

Your suggestions to convert the file to HTML, and get a word count, are a bit more complex, and might be best solved by using an external library, something that I have typically shied away from, with the lone exception being PHPMailer (which SM uses for all outgoing email notifications).

Open to ideas. Thanks. -DE

[jayyx2]

Without using an external library of some sort, options are limited unless you want to spend many hours working your way from XML Parser onward. For a customized solution, I was thinking of attempting to intercept the download function to force an if statement looking for view or download button being hit. If view was hit, it would need to take the file and pass it to something else, such as https://github.com/PHPOffice/PHPWord or https://github.com/zelon88/HRConvert2 for conversion. Once converted, take it as a variable and 'echo the text' using popup.js or a new modal.