And then we discovered a reproducible UnicodeEncodeError. It came
when printing out a Tx25 document:

Errorwhileevaluatingtheexpression"table(self.Result(ar))"definedinthe"from"partofastatement.UnicodeEncodeError:'ascii'codeccan't encode character u'\xe4' in position 10: ordinal not in range(128)File"<string>",line1,in<module>File"/.../lino/lino/modlib/appypod/appy_renderer.py",line234,ininsert_tablereturnself.insert_table_(*args,**kw)File"/.../lino/lino/modlib/appypod/appy_renderer.py",line471,ininsert_table_returntoxml(table)File"/.../lino/lino/utils/html2odf.py",line105,intoxmlnode.toXml(0,buf)File".../env/lib/python2.7/site-packages/odf/element.py",line518,intoXmlelement.toXml(level+1,f)File".../env/lib/python2.7/site-packages/odf/element.py",line518,intoXmlelement.toXml(level+1,f)File".../env/lib/python2.7/site-packages/odf/element.py",line518,intoXmlelement.toXml(level+1,f)File".../env/lib/python2.7/site-packages/odf/element.py",line518,intoXmlelement.toXml(level+1,f)File".../env/lib/python2.7/site-packages/odf/element.py",line518,intoXmlelement.toXml(level+1,f)File".../env/lib/python2.7/site-packages/odf/element.py",line262,intoXmlf.write(_escape(unicode(self.data)))<type'exceptions.UnicodeEncodeError'>:'ascii'codeccan't encode character u'\xe4' in position 10: ordinal not in range(128)

Changed the detail_layout of a Tx25 because it not has a field “Printed”.
TODO: also change the layouts of the other requests.

(invisble and last, but not least:) the printing of a Tx25 is now also
being tested.

This was not the solution, but it helped me to find the explanation:
lino.utils.html2odf did not collaborate with the latest odfpy
version. Now it uses StringIO instead of cStringIO because the
latter cannot not handle unicode strings. The module itself also has a
test case to reproduce the problem differently.