Hi Dag, [...] >>> So long as lo/oo can open it and the result is right it doesn't >>> matter, whichever is easier to generate. >> >> Right, .fodt is a single xml file, especially for this kind of purposes. > > I have started writing an ODT backend for AsciiDoc, and it currently > produces my test-document (curriculum vitae) almost exactly as the output > from the docbook2odf/unoconv toolchain. > > Noteworthy items: > > - LibreOffice/OpenOffice is not able to open a flat ODF file (single > XML file), however encapsulating a single XML file inside a zip will > works although is reported to be corrupted (but nevertheless loads > fine). Producing the content.xml does not have that issue :-/
Annoying :( > > - I asked on the LibreOffice forum to get single XML file import support, > which is very much wanted for testing ODF in general. Hope this is > something for the future... Good idea. > > - If we would like to produced zip-encapsulated ODT files, AsciiDoc would > need such infrastructure to facilitate the backend. Not sure how that > would work, but currently the backend is non-functional with > LibreOffice/OpenOffice. Not much use if it doesn't work with them so we better fix it. :) I would suggest that a Python post processing script does the packing and copies any boilerplate files into the zip file. In fact I would suggest that it copy the style file from the template too. That would save post applying the template. Oh I see you mentioned that below :) Such a script can be run by, or even copied into, a2x so producing zipped ODF isn't any harder than any of the other supported formats. > > - Embedded (data-uri) images works also in ODT, I have it implemented. > If images are not embedded, they are referenced by URI and could be > part of the zip file too. Again the Python script can copy them, as a2x does for resources now. > > - I have currently added my own style-sheet to the backend, we may want > to make it look more generic (maybe similar to the HTML output). Do we > want to allow asciidoc to replace the stylesheet, or is this better > left to unoconv/libreoffice/openoffice ? Both have some use, I guess. See above. > > - The stylenames are trashed by LibreOffice, so opening the generated ODT > document and saving it, will replace the properly named styles by > LibreOffice's ugly ones. Which should not be a problem, since ODT is > considered an 'output' format, likely to produce PDF ;-) The visible > style names are preserved, so LibreOffice users won't notice it. I would class changing formats on saving as a serious bug in LO, have you reported it? In the meantime I guess being able to print it is enough for testing. > > Only the basics are implemented as of today: > > - metadata > - title and headings > - emphasis, strong, monospaced, superscript, subscript, quoted, > doublequoted, ... > - numbered, bullet and named lists > - page-breaks and line-breaks > - sidebars > - admonitions > - URLs > > Considering I only spent 3 hours on this with little knowledge of how this > works in AsciiDoc, I am convinced this is a better approach than > docbook2odf. Great, if you post it on github or somewhere public it can be tested and improved. Cheers Lex -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
