# 20120414¶

lino.utils.xmlgen.odf is probably useless: I discovered ODFPy, a library by Søren Roug for manipulating OpenDocument documents (.odt, .ods, .odp, …): read existing files, modify, create new files from scratch (read more on PyPI).

Renamed my old lino.utils.html2odt module to lino.utils.html2odt_old (it has never been used but and I should rather throw it away, but just in case…)

Created a new lino.utils.html2odt package, a wrapper around odfpy.contrib.html2odt. The idea was to use the existing value2html StoreField

It is mainly a simple copy of these files because I didn’t see any other possiblity to make them easily available. Afterwards I realized that Søren’s html2odt is probably rather a proof of concept and not yet meant for “serious use”.

The most pragmatic solution seems currently to add another method to value2odt StoreField

And yes, a proof of concept works: Lino now generates a .odt file when you click on the [pdf] button. That’s rather a step back, you’ll say, but the revolutionary new thing is that the columns have now correct widths.

Formatting is also less beautiful than before, but that’s just a question of getting used to the ODF way to format.

More important is the question: is this the right way to go? Although this method would work for the [pdf] button of a table view, it is not a solution for rendering tables inside of an appy.pod template.

Can ODFPy replace appy.pod completely? Is it possible to do what appy.pod can do using OO User Fields and Conditional Texts? Probably not. Or at least not easily. For example we still would need a headless OpenOffice running at the server for doing the conversion to .pdf or .rtf. The appy.pod templating system is not perfect, but it works, it is reasonably fast and stable, and my customer is used to it.

In fact we need to integrate both projects:

do text from currently simply expects a chunk of XML to be inserted at that place of the template. But it seems that we need more. In order to specify widths of table columns, we also need to be able add styles to the document: at least one automatic style for each column that has a width specified. This cannot be done using a simple XML chunk. The appy.pod.parts.OdtTable is useless as long as it cannot do more than returning an XML chunk.

My suggestion for appy.pod is to extend the do text from clause so that the user function may return something else than a string. For example a dict with different keys “content”, “styles”, “automaticstyles”… or an odf.opendocument.OpenDocumentText instance, and in that case appy.pod would (1) inspect the styles and automaticstyles of this instance and add them to the styles and automatic styles of the template, (2) consider the whole text part of the document instance as the XML chunk to be inserted.