How can I create books through py-uno?

[_savage]

When it comes to Python and UNO, then it’s hard to find any information. There was a good introduction here which got me started, but it’s far from what I’d like to get done.

I’ve looked at the API documentation of LibreOffice here but I have a hard time connecting this to the use from Python. Are the Java or C++ references useful or relatable?

What I want to do is

1. Create a more complex document, and configure it with left/right pages; per-page margins; define the fonts for headings, text, paragraphs, etc.
2. Next, push text into the document and annotate it as heading, normal paragraphs, then some text goes into paragraphs with their own styling, and so forth.
3. I’d like to be able to add footnotes.
4. I’d like to be able to generate a TOC once the text is all done.
5. I’d like to add images on occasion into the text flow.

Any help is appreciated! It’s enough if you can just point me at a site which has appropriate documentation, but if you can answer the questions directly—the better

Thanks!

[ChrisVella]

It is not clear what your question is about. Libeoffice can do all of the above. If you’re after scripting to create a document prepared for book publishing, maybe this is not the best site to get help. Why not try http://libreofficeforum.org/ ?

[hunteke]

The response to the first half of your question is: unfortunately, great documentation oriented toward the Python-UNO interface does not currently exist. A Python-LibO interface (in the form of UNO) certainly exists, as you have found, but it is neither robust, nor well-documented. Further, there does not seem to be anyone on the LibO dev list who is actively focused on this particular area. There are scant few functional tests of the Python-UNO interface (that ensure that changes do not unintentionally change user-facing APIs), and there does not appear to be any active development on this front.

However, the Python-UNO interface is basically a veneer over the C++ APIs, as are the other language-level interfaces. Thus, if you can track down another language-level API for UNO, or have the ability read the C++ documentation and/or code, you may have some success translating for your use cases.

Clearly, this is not ideal, and the best workaround I’ve come up with is targeted introspection of the API through use of a drop-in REPL shell. IPython works wonders for this purpose. Consider something like this (or more complete examples ):

ctxt = pyuno.getComponentContext()
smgr = ctxt.ServiceManager
desktop = smgr.createInstanceWithContext('com.sun.star.frame.Desktop', ctxt)
url = 'private:factory/swriter'
doc = desktop.loadComponentFromURL( url, '_blank', 0, () )

from IPython import embed as II
II()  # <--- this creates a shell right "here", as if you had typed
      # the above commands.  For example, try typing 'doc.[tab][tab]'
      # to see what IPython can find as possible accessible attributes
      # on the doc object.

My choice of “II” is clearly arbitrary, stemming from some measure of lazy. I often put the import statement at the top of a script, and then know that I can type “II()” anywhere I’d like to poke around. 3 letters and typos saved …

Having use of a REPL with the exact context of the program is really helpful. In my opinion, the IPython interface is “better” because it offers many additional “goodies” which many of the Python debugging packages don’t.

Finally, a plug: if you can create functional tests of issues you note with LibO, please do so and submit them. In general, I’d argue that LibO suffers from a weak set of unit and functional tests, and would benefit from folks such as yourself: drive-by coders who happen to notice errant behavior.

[sup]

The embedding does not work for me. I asked a different question about IPython, if you would shed any light on that, it would be appreciated: How do I invoke IPython from a macro?

[oweng]

There is a collection of Python-related links here that may also assist.