Drop support for UNOCONV

docs/faq/index.rst

@@ -151,20 +151,6 @@ Webserver
 OCR
 ---
 
-**Q: The included version of ``unoconv`` in my distribution is too old**
-      
-* Only the file 'unoconv' file from https://github.com/dagwieers/unoconv is needed.  
-  Put it in a user designated directory for binaries such as /usr/local/bin and 
-  setup Mayan's configuration option in your settings_local.py file like this::
-    
-    CONVERTER_UNOCONV_PATH = '/usr/local/bin/unoconv'
-    
-If you already have office or text documents uploaded into **Mayan EDMS**,
-after setting up and testing ``unoconv`` by hand, go to 'Tools',
-'Maintenance', 'Update office documents' page count', this will force a
-re-detection and re-processing of any document found to be of office format.   
-
-
 Deployments
 -----------
 

docs/releases/0.12.3.rst

@@ -2,7 +2,7 @@
 Mayan EDMS v0.12.3 release notes
 ================================
 
-*October 2012*
+*December 2012*
 
 This is the third maintenance release of the 0.12 series.
 
@@ -55,6 +55,8 @@ their clients with customized setups without having to access their clients'
 **Mayan EDMS** instances.  ``JSON``, ``YAML`` and a custom ``YAML`` format
 (http://djangosnippets.org/snippets/2461/) are supported by this new app.
 
+#TODO: Add repository sync
+
 Translation updates
 ~~~~~~~~~~~~~~~~~~~
 The translation for all the current languages were synchronized to the
@@ -77,6 +79,8 @@ is now more aptly named metadata members which adds or removes metadata types in
 single organizational unit.  An error that caused a duplicate menu link in the
 document type filename view was also fixed.
 
+#TODO: Add removal of UNOCONV
+
 Optimizations
 ~~~~~~~~~~~~~
 Inspired by the idea of getting **Mayan EDMS** running effectively on low power hardware such as

docs/topics/document_visualization.rst

@@ -8,7 +8,6 @@ The philosophy in place is to try to avoid having users download a documents and
 visualization tool too.  The conversion backend is a stack of functions,
 first the mimetype is evaluated, if it is an office document it is passed
 to LibreOffice_ working in headless mode (and managed by supervisor_)
-via unoconv_ (more information about ``unoconv`` can be found in the :doc:`FAQ section <../faq/index>`)
 for conversion to PDF_.  The PDF_ is stored in a temporary
 cache along side all the other files that were not office documents,
 from here they are inspected to determine the page count and the
@@ -39,5 +38,4 @@ which defaults to '/usr/bin/libreoffice'.
 
 .. _PDF: http://en.wikipedia.org/wiki/Portable_Document_Format
 .. _LibreOffice: http://www.libreoffice.org/
-.. _unoconv: https://github.com/dagwieers/unoconv/
 .. _supervisor: http://supervisord.org/introduction.html

docs/topics/settings.rst

@@ -192,26 +192,6 @@ fine tune it's functionality as explained in the `GraphicsMagick documentation`_
 
 .. _GraphicsMagick documentation: http://www.graphicsmagick.org/convert.html#conv-opti
 
-    
-.. setting:: CONVERTER_UNOCONV_PATH
-
-
-**CONVERTER_UNOCONV_PATH**
-    
-Default: ``/usr/bin/unoconv``
-    
-Path to the unoconv program used to call LibreOffice for office document conversion.
-   
-    
-.. setting:: CONVERTER_UNOCONV_USE_PIPE
-
-
-**CONVERTER_UNOCONV_USE_PIPE**  
-    
-Default: ``True``
-    
-Use alternate method of connection to LibreOffice using a pipe, it is slower but less prone to segmentation faults.    
-
 
 .. setting:: CONVERTER_LIBREOFFICE_PATH