matthias/mayan-edms
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge branch 'hotfix/v0.12.2' into development

Browse Source 
Conflicts:
	apps/common/__init__.py
	apps/documents/forms.py
	apps/feedback/__init__.py
	apps/history/__init__.py
	apps/main/__init__.py
	apps/scheduler/api.py
	apps/sources/models.py
	docs/releases/index.rst
	requirements/production.txt
	settings.py
	urls.py
This commit is contained in:
Roberto Rosario
2012-06-30 04:00:01 -04:00
parent 90c411f554 04de24ea51
commit 080d68c169
438 changed files with 12762 additions and 4473 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/topics/document_visualization.rst
View File

@@ -21,7 +21,6 @@ previews are then created on demand for the different sizes requested
(thumbnail, page preview, full preview) and rotated interactively
in the details view.
Office document conversion however won't always work as expected because
LibreOffice_ do not provide proper API's, so subprocess calling,
temporary files and other black magic needs to be invoked to get it
@@ -30,6 +29,13 @@ or frames, and text extraction and OCR is done per page not per document,
thats why even text documents need to be rendered by LibreOffice_
before they can be previewed and text can be extracted.
Version 0.12.1 introduced a new method of converting office documents, this
new method doesn't require the use of the command line utility ``UNOCONV``.
If this new method proves to continue working better than previous solutions the use
of ``UNOCONV`` may be deprecated in the future. The new conversion method
adds just one new configuration option: :setting:`CONVERTER_LIBREOFFICE_PATH`
which defaults to '/usr/bin/libreoffice'.
.. _PDF: http://en.wikipedia.org/wiki/Portable_Document_Format
.. _LibreOffice: http://www.libreoffice.org/

11
docs/topics/ocr.rst
View File

@@ -10,9 +10,12 @@ processing by settings this options to 0, with other machines or cloud
instances then connected to the same database doing the OCR processing.
The document is checked to see if there are text parsers available, is
no parser is available for that file type then the document is passed
to tesseract page by page and the results stored per page, this is to
to Tesseract_ page by page and the results stored per page, this is to
keep the page image in sync with the transcribed text. However when
viewing the document in the details tab all the pages text are
concatenated and shown to the user. Setting the :setting:`OCR_AUTOMATIC_OCR`
option to ``True`` would cause all newly uploaded documents to be
queued automatically for OCR.
concatenated and shown to the user. All newly uploaded documents will be
queued automatically for OCR, if this is not desired setting the :setting:`OCR_AUTOMATIC_OCR`
option to ``False`` would stop this behavior.
.. _Tesseract: http://code.google.com/p/tesseract-ocr/

4
docs/topics/settings.rst
View File

@@ -454,9 +454,9 @@ Username of the automatically created superuser
**COMMON_AUTO_ADMIN_PASSWORD**
Default: ``admin``
Default: Random generated password
Default password of the automatically created superuser
The password of the automatically created superuser
.. setting:: COMMON_LOGIN_METHOD

8
docs/topics/signatures.rst
View File

@@ -22,3 +22,11 @@ functionality in the ``Setup menu``
From this menu, key servers can be queried
and the results imported. Public keys no longer needed can also be deleted
from this menu.
Only `GNU Privacy Guard`_ signatures are support at the moment. In case
your installation of GnuPG is non-standard, you can use the :setting:`SIGNATURES_GPG_HOME`
configuration option to let **Mayan EDMS** find your GPG instance's home directory, used to
store keyrings and other GPG configuration files.
.. _`GNU Privacy Guard`: www.gnupg.org/