uploading figures or tables

[piotreba]

Hello,

During submission I disallow authors to submit figures or tables in the main manuscript file. I would like to use supplementary files for that, but as I see by default the header says that the supplementary files should be any file that cannot be presented in the text, like some large data sets and so on, what does it mean? Are these files only some special kind of files? I need high quality figures which cannot be placed inside MS Word or OpenOffice Writer file. These figure or table files will be eventually merged with the text so is it allowable to use supplementary files form for attaching regular figures or tables? I know this questions may sound silly, but I am not 100% sure of the consequences of such and no other solution.



Thanks.

[thebigaym]

I also separate the tables and figures from the submission file and upload them as supplementary files. We do publish a PDF galley, and so we reproduce the figure and table in low resolution in the PDF. We hope to start publishing MS Word and HTML galleys soon, so I'm interested in seeing what others recommend.

[jmacgreg]

Hi piotreba,

In addition to thebigaym's excellent advice -- You shouldn't run into any problems requesting that authors contribute their additional files as supplementary files. You will, however, want to configure whether they are publicly available as such -- see Journal Management -> Reading Tools -> Reading Tool Options for the option to have them available to readers from the Reading Tool itself. See also this thread for information on embedding supplementary files within an HTML galley, if that is something you might be interested in.

If you have any further questions, please let us know.

Cheers,
James

[aleskl]

Unfortunately the option using supplementary files for submitting original figures is not a good option for our journal.
1) We do need regular supplementary files for some papers (data sets, additional figures, etc.)
2) Uploading original figure files through Supplementary files interface is very confusing.

Is it possible to add another upload box into the Editing step, eg. Upload additional files, that would allow to upload any number of additional files into the manuscript directory?

Kind regards,
Ales

[aleskl]

Hello!

Are there any news about uploading original files for figures or tables? We need to have them separately uploaded, to use them in preparation of a printed version of the journal.

I'm thinking where this upload should be placed - when the review process is finished, the paper goes to the copyediting step. The upload of figure files should be in the Editing step, maybe in its own section between Copyediting and Layout? Would it be complicated to generate an upload file form, that would allow uploading of several files and showing a list of uploaded files (with an option to delete individual files in case of an error while uploading)?

cheers,
Ales

[piotreba]

The best thing would be when an author upload all figures and tables as a separate files and in the end the final one pdf with whole content is generated for review. There should be some mechanisms that check whether the figures have correct properties for example. The input files would stay in the system for further editorial steps.

In our journal it is a need to have figures in fine quality, so they must be upload as a separate files, but the system isn't to friendly to process multiple file submission during later editorial steps.

[jmacgreg]

Hi Ales, Piotreba,

Thanks for your comments! Probably the most-followed workflow is currently this:

1) authors upload all secondary files -- figures, tables, data sets, etc. -- as Supplementary Files during submission. Authors can upload as many supplementary files as they want.

2) Review happens, with supplementary files provided -- or not -- to reviewers for comment, and the submission eventually goes to Editing.

3) During Editing, Copy/Layout Editors manually download and manage the supplementary files, inserting them as necessary into the master document if that is part of the copyedit or (more likely) layout process.

Currently, however, the supplementary files aren't easily downloadable/modifiable by the copy/layout editors, and this should change. I've posted a bug report here: http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=7011. Please feel free to CC yourself to that report for future updates, and to also provide any other thoughts you might have.

Cheers,
James

[piotreba]

James

We do use the work-flow you mentioned. Figures or other supplementary files submitted to our journal are all reviewed and in fact allowing the author to choose not to show them to the reviewers has no sense.

To show how unfriendly the processing of multiple files is I just mention the step when the author need to provided revised version of the files for second review. I can only choose one revised file to be reviewed then. I need to manually change supplementary files if they were also corrected by the author. Supplementary files are treated now as they were not taken into account to be reviewed, also multiple times. Ok, I said I do it, but in fact section editors have to do it as they carry on submissions, they are not happy to process them this way. So generally, we require that the authors submit figures as a separate files to:
1. provide reviewers high quality figures, our journal publish botanical papers so the figures presenting biological structures must be of the greatest details, not only in the final published papers
2. be sure that if they work is accepted to be published the author is able to provide the files of required parameters

As I wrote in last post, for me the best solution would be that the final high quality pdf is generated from the multiple files submitted by the author. Some checking of the figures should be performed to assure they are of the required quality. Then the reviewer/copyeditor has only one file he/she can zoom in and out to investigate high quality figures and only one file cycle through all the editorial steps. All the input files stay as separate ones in the system waiting for final step when they are used to prepare final pdf to be published.

[aleskl]

The temporary solution for uploading source files to our journal is this:

We don't use the extensive copyediting procedure, since most of this is done in the review process. So I abused the author step of copyediting for uploading of source files, because this is the convenient point in the paper processing workflow that allows the upload of files by the author.

What I do is, after the review process is finished, I (in the role of the editor) start and complete the first phase of copyediting without actually doing anything and then initiate the author step of copyediting, but I skip email, and send the author a custom email, where I write instructions for uploading the original files - I advise the author to pack everything in one ZIP file and upload this in the Author part of copyediting process. The editor can then download this file and upload it to the Layout editing step, where it can be accessed by the Layout editor. Our authors use Word or LaTeX to prepare text, so we need the source files to build a print version, as well as figures in print resolution.

The workflow using supplementary files is not a good option for us, since the papers in our journal usually contain a lot of figures (http://www.ias-iss.org/ojs/IAS/) and the authors could get confused with all the options that are available for supplementary files. Plus, we occasionally need the actual supplementary material, so the workflow could get very confused.

I propose that an additional (optional) section would be added in the Editing step for uploading of original files - the interface would be made from an upload box, a file list, and a button to delete a file if it is uploaded by mistake. The files would ideally be uploaded to a subdirectory in the article directory and retain their original name, eg. Figure-1.tif, Figure-2.eps, etc. so that the Layout editor would know where to put the figures in the text.

cheers, Ales

[jmacgreg]

Hi Piotreba, Ales,

Thanks again to the both of you for sharing your comprehensive thoughts here. I think what you both suggest makes a lot of sense, especially as more and more journals (especially scientific journals) are born digital and use the full editorial workflow. My understanding is that options like this will be available first in OMP's galley production process, and subsequently in OJS' workflow. Unfortunately, with a large part of the development team currently working hard on getting OMP 1.0 out the door, we can't make any sort of estimates or commitments with respect to when these changes will find themselves in OJS. At the same time, however, we would be more than happy to help you folks, or others who are interested in the same functionality, develop the code. Do you folks ahve access to any developer resources at all? If so, please let us know, and we will be more than happy to provide pointers, etc. If that's not the case, we will still reference your comments here when working on the above bug report, but as said above, we can't necessarily suggest a timeframe to completion.

Cheers,
James

[aleskl]

James, thank you for replying!

What developer resources do you mean - is it the code repository? I'm sorry but I don't dare to develop a new piece of code - I know just as much to tweak the templates a bit. And time is so limited But I will try to do something here when I have some spare time, so I am interested in developer resources.

cheers, Ales

[jmacgreg]

Hi Ales,

By "Developer resources" I meant if you have a developer on hand to help work on this. As you've probably guessed, we're a small team ourselves, and while we'd love to add these features as fast as we can we also only have a limited amount of time. Rest assured though that we really do value these comments, and that they will inform our own development process.

In a more general sense, I can point you to our own developer documentation if you are interested. It's pretty much entirely stored on the wiki, although you may also be interested in the technical reference and in our API reference. I do understand though that time as you say is limited, and learning this stuff can take too much time. Your feedback and requests are just as valuable as the code itself, and we look forward to hearing more.

Cheers,
James