thanks for sharing, we always look forward to this kind of feedback.
1. Upload files other than pdfs (e.g. Word or Html docs):
I'm puzzled about this one. The system already allows to upload the most common file-types. I must add that it relies on the file extension to understand what type of file is being uploaded and wether to accept it or not. This means that Mac users may need to manually add the file extension to their files before uploading them. For example: to upload a word (2003) file, one should make sure that the filename ends with ".doc", the ".docx" extension should be used for Word 2007 files, the ".htm" or ".html" extensions are both valid for HTML documents and so on.
If you'll stumble on a legitimate file type that you would like to upload but is refused by the system, please let us know, we'll try to start supporting it at the next update.
In case EPPI-Reviewer 4 is actually rejecting all your non-pdf files for other reasons, please let us know as well: we haven't had any complains about this so we'll have to investigate what doesn't work in your particular case.
2.a Keep the formatting of pdfs, which otherwise becomes a jumble of table contents, journal details, page numbers etc.
2.b Delete irrelevand text (e.g. page numbers etc) or add notes;
It is not possible to "extract" the text and keep all formatting, but yes, we are aware that the current solution is far from perfect. Our plan is to extend the native support of PDF files (only PDFs!) so that it will be possible to add codes to text directly inside the PDF document (instead of using the "text" tab). It is now possible to create PDFs from any printable document and in any platform (being Windows, Mac or Linux), and currently 98% of the uploaded documents are PDFs, so we don't plan to extend this feature to other formats: it does not seem a good use of our time. I don't know when this feature will be ready: we have written and/or validated all the necessary building blocks, but it is not something we can add gradually, one little piece at a time; we need to be able to write it all and test it throughly, so it requires more time and effort than other features.
As for editing the "extracted" text: we have discussed this option a lot and decided we prefer not to allow this. The extracted text is supposed to be a static "copy" of the uploaded document, if we allow users to edit it, we will have to solve two problems: first, we will need to handle text changes of already coded text, this can be more complex than it seems. Second, we will need to provide undo functionalities, or at least a "revert to original" function; one thing is sure, people will make mistakes and then ask us to pull them out of trouble. Combine these two requirements and you'll see why we have decided not to allow editing: for example, what are we supposed to do when restoring an already coded text?
Add Notes: there are two distinct ways to add annotations, one (preferred) is to add some text to the code itself through the "info" button, this comes with the limitation that the "info" text will apply to the "Item-Code" association, and not to the "FullText-Code" match. The other option is to annotate the PDF file itself: this type of annotation can be added to any part of your PDF documents but it will not appear on reports or the "text" tab, and is not associated with codes.
3. Merge codes when one recognises that a previous distinction was not a good idea;
I can see why this might be very useful in some special cases. We'll think about it, if we'll find a way to add this functionality without having to change the rest of the system, then it's likely that we will add it. Again, I can't promise neither if nor when, sorry!
4. Get an overview of what text has and has not been coded throughout the document to make sure nothing's been missed.
This is definetely on our plans, we have very ambitious ideas about this and that's probably why it's taking so long for us to have it ready. I expect this type of feature to appear after we will have finished the "native PDF coding": it makes sense for us to write something that will apply to PDFs directly - this is how we expect most people will code the full-texts in the future.
I'm sorry I can't give you more positive answers, please do continue to share your suggestions, though. We try to make sure that EPPI-Reviewer keeps evolving, and the drive from our users is the most important for us.