On Wed, 28 Sep 2011, Lex Trotman wrote:
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 :(
Fixed! For the single XML ODF file you need to explicitely set the
mimetype of the document. Now that my backend does this, the file opens
without a problem (and testing goes a lot quicker like this).
This only works with a recent LibreOffice version (3.3 or 3.4). With this
working there's no reason we cannot make this a group-effort. I'll try to
put it on Github tomorrow after I have cleaned it up a bit.
- 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 :)
The downside of such styles, is that you have to hand-edit them. While the
nice benefit of ODF support is that hand-editing is no longer needed ;-)
But even with hand-editing, it beats XSLT any day.
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.
Yes, although the content for a single XML ODT (.fodt) file and a proper
ODT are slightly different. If we want two backends for this, we need to
make sure one inherits most of meat from the other.
- 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.
Great. I have no experience with a2x :-/
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.
Will do later after cleaning up the styles.
Kind regards,
--
-- dag wieers, [email protected], http://dag.wieers.com/
-- dagit linux solutions, [email protected], http://dagit.net/
[Any errors in spelling, tact or fact are transmission errors]
--
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.
