That has been discussed at several places, some ideas to solve the problem can be found here (for WIN):
<http://forum.openoffice.org/en/forum/viewtopic.php?f=15&t=33742>

Currently there might be not many requests for this feature, but I can imagine applications where such a feature would be useful.

Example from my personal experience: Technical documentation for Building Automation in bigger objects (hospitals, administrative buildings...). This kind of systems never become ready, always smaller changes will be done, user finds out how to solve his problems, ... .  For these applications I contribute the technical documentation as a system of ODF documents on a net drive. They are all protected with "Open file read-only" to protect the documents from accidental changes. But if the user wants to leave a note, correct a mistake or whatever, he is allowed to do so without any urdles, only trusted persons have access to those net drives. So it might have some advantage simply to install their LibO with an option "always open in read only mode", they really normally only need a document viewer, only from time to time they edit documents.

There might be other applications where a PC (tablet, smartphone) normally only is used as a viewer, with feature to do edits if necessary.

So I think this is a legitimate feature request.

Original conversation on Ask site:
http://ask.libreoffice.org/en/question/14477/put-libreoffice-as-unedited-document-viewer-only/

The date on the original submission of this request and the comments at that time indicate that someone would give due consideration to the request. I can only guess from the absence of any action that no one, in fact, has really taken up this cause at LibreOffice.

Having spent several weeks trying to find a good solution to the requirement for a user to be able to easily navigate -- in both directions -- between the body text of a document and its associated endnotes, I think I can correctly state that, within the various toolkits supporting PDF, there is no good solution available.  If is frankly mind-boggling to go through more than a decade of postings and versions of Adobe software to see that they have completely failed to address this fundamental behavior in the reading of on-line text.

When the belatedly decided that documents were becoming interactive, they fell into the most fundamental Dykstra trap of 'far too early optimization' by concluding that they knew, better than any user or developer, that the only legitimate functionality concerning navigation would be as adjuncts either to data entry into forms or tracking the development cycle of authoring and publishing a document internally.  Annotations, consequently, are very, very ill-suited to providing the sort of user navigation experience that a reader of a document expects.

OK, I don't need to go on with a description of the inadequacy of the Adobe Reader [or any of its counterparts created by 3rd parties], the key point is that there is one tool which does provide a very decent, very robust ability for the reader to be re-directed in both directions to and from an endnote whilst reading the document.  It is the functionality of your swriter and that is why it is so terribly important that you give us an alternative to the workflow that just uses LibreOffice to product PDF documents to be read via their reader.  We need to be able to send .odt files to our readers and let them know how easy it is to open, read, and browse back and forth in an .odt document.  Please, please look at the very manageable engineering effort that would be required to deliver a version of the swriter configured as an sreader with almost all controls removed from the screen so that a reader, not a programmer, not a document editor, not a layout specialist, can read the beautiful content that your fine swriter product allows us to produce.

This bug is still present in LO 5.2.7.

** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug