Currently, I am working as casual programmer in university. One main task that I have been dealing since the first day I started my contract till now is implementing OO UNO automation in our system called ICE. ICE is developed under python 2.4 and uses pyuno bridge to develop UNO component in python so we can automate open office writer document.
ICE is mainly used by Electronic Printing Department to generate course study book and introductory books. Modules for each books are created separately in different document writer application like NeoOffice, MS words or OpenOffice writer. After each modules created, user uses ICE to generate the complete study book and introductory book and this is where uno automation performs it’s task. These tasks include build the book (with template selected by user e.g. study book template), convert all non OpenOffice writer documents to OpenOffice documents, inserting the converted documents to the book, update all bookmarks, generate table of content for the book and render the completed book to PDF and HTML format.
Issue that I faced (will be added based on what I faced when I work):
- ICE is developed under Python 2.4 and so does all the module that support ICE, but stable version of pyuno provided by OpenOffice.org still uses Python 2.3. Python 2.3 is installed together with OpenOffice can located in the installation directory (In linux: /opt/openoffice.orgx.x/program/python and in window: C:\Program Files\OpenOffice.org x.x\program\python.bat). ICE uses Python Twisted that run locally in user’s machine (now in the process of migrating to server version), so when running pyuno for the automation, python 2.3 is executed from ICE through command line. When executing pyuno, all the information of the book in data stream format (not file format) are passed to command line and another process of python will handle the automation separately. The problem exists when book document is too big like more than 600 pages study book which have a big data stream. Command lines cant handle more than 5k data. One of the solution that I have done is save the bit stream data into temporary file and pass the file name to the automation module. Although now automation can handle building big book, that solution is not a preferred solution. Now I am working on sending the the big data stream to output stream instead of saving it to the file.
- MathType Object issue. Automation .uno:UpdateAll can not handle MathType object properly when the process of inserting the document into the book are automatically performed non-visibly by user. .uno:UpdateAll will either cause Open Office to shut down by stating “too many windows opened” or just sit there without doing anything. So, before the document (in odt) being inserted into the book file, I hacked into the the open office content.xml of the document and remove all the MathType objects and then insert the document to the book file. After all the documents being inserted into the book file, I hacked the book content.xml file again and put back all the MathType objects. Surprisingly, after hacking the MathType object, .uno:UpdateAll never complain at all even the insertion of the document are done non-visibly. .uno:UpdateAll is used to build table of content of the book. Instead of throwing error and causing Open Office crashed, .uno:UpdateAll never build a correct table of content without being indexed twice (at least) automatically. This problem is not consistent as sometimes even with a book without MathType objects being build, the indexing for the table of content still wrong. For temporary solution (again), user need to open the book after being built and re-index the table of content by themselves then the table of content will be correct since the re-indexing is done with the book visibly opened by user.
1 ping
Latex Resources » Working in UNO automation of OpenOffice says:
November 17, 2007 at 12:45 am (UTC -4)
[...] unknown: [...]