Have you ever wondered if it was possible to use functions xhtml or text within ODS templates ? Good news: the answer is: yes! But... There is a "but", but a very, very small one. Lowercased.

You may already have tested it, like I did here.

As a Appy enthousiast, you were convinced this would work, but you got this instead.

Within an ODT file, a comment is always inserted within a paragraph. If, for example, you add a comment into a table cell, behind the scenes, LibreOffice creates this structure:

Table > Row > Cell > Paragraph > Comment

Using POD statement

do text
from xhtml|text(...)

works: the table cell is still present, and its inner paragraph is replaced with the result produced by function xhtml or text, that potentially includes a series of paragraphs, titles or other sub-elements, producing a legal chunk of ODF code. So, in that case, everything works fine.

Within an ODS file, things are different. In the hereabove example, where a comment is defined on a cell, LibreOffice creates this structure:

Table > Row > Cell > Comment

Even if some text was encoded in the cell, the structure would have been:

Table > Row > Cell > Comment
                     Paragraph

On such a data structure, using POD statement

do text
from xhtml|text(...)

does not work, because the comment is not located within a paragraph. The error message says, consequently and logically, that the only available elements onto which a POD statement can be applied are: row or cell.

You may say: Eureka! The solution is do write a "do cell" statement instead of a "do text". Bad idea. A POD statement replaces entirely the target element by the result produced by the from clause. Using a "do cell" statement would produce a data structure into which element "cell" is definitely missing.

Are we stuck? No. I present you the "plus" operator. Distant cousin of the "minus" operator, applying it to the from clause means: "please, retrieve content produced by the from clause, but instead of completely replacing the target element, keep it, throw away its content and replace it with the result produced by the from clause".

Consequently, the correct way to use function text in an ODS template is this one.

A possible result would be:

Here is an example of using function xhtml.

Assume task.infoTask() returns a chunk of XHTML code. The resulting ODS file could be this one.

Avoid br tags when using function xhtml in an ODS template

LibreOffice dislikes carriage returns within ODS cells (although he tolerates it in ODT cells). Traditionnally, Appy, via its xhtml function, converts any <br/> tag into its corresponding ODF tag, being <text:line-break/>. Within an ODS cell, this tag will be ignored. When a normal human (=not you and me) uses LibreOffice to inject a carriage return in a cell, using <ctrl>+<enter>, behind the scenes, LibreOffice creates an additional paragraph. The result is similar to <p>First line</p><p>Second line</p> and does not correspond to <p>First line<br/>Second line</p>. Please keep that in mind when proposing chunks of XHTML to inject into ODS cells. Anyway, using paragraphs (p or div tags) is generally a better practice than using br tags.

What about importing images into an ODS template ?

Importing an image into an ODS template is possible, using the document function via a from+ clause, like in the following example.

The correct internal ODS tag structure for visualizing an image in a cell is:

Table > Row > Cell > Image

As discussed hereabove, the "+" variant allows to produce such tag hierarchy. The problem, with the document function, is that, by default, it wraps the dumped image in an additional paragraph. While this is convenient in ODT templates, it produces a tag hierarchy being illegal in an ODS document.

Table > Row > Cell > Paragraph > Image

Using parameter attribute wrapInPara=False allows to produce the correct result.

Note that an image imported like this will be anchored to the cell. Appy does not currently allow to import an image to the page in an ODS template.