On Wed, 26 Oct 2011, Stuart Rackham wrote:
Hi Dag
I've install your ODF backend and have successfully generated .fodt files,
but OO Writer (OpenOffice.org 3.2 Ubuntu) doesn't seem to be able to read
them, I get a 'General Error: Input/output error' dialog.
Yes, OpenOffice does not support Flat ODF files. Maybe the README should
be more clear about it. But when using Lex's a2x modifications, you can
create reale packaged/zipped ODT files, which even OpenOffice should be
able to open. LibreOffice supports Flat ODF files starting from 3.3 !
So there's hope :-)
So I replaced OO with LibreOffice 3.3.2 and it now opens the .fodt files. I
processed the distribution doc/article.txt file but the output displays as
blank and lowriter emits this error:
$ asciidoc -b odt doc/article.txt
$ lowriter doc/article.fodt &
Warning: at xsl:stylesheet on line 2 of
file:///usr/lib/libreoffice/basis3.3/share/xslt/odfflatxml/odfflatxmlimport.xsl:
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Error on line 385 column 3
SXXP0003: Error reported by XML parser: The element type "text:p" must be
terminated by
the matching end-tag "</text:p>".
That is strange. It would be nice to understand what would generate a
<text:p> without a matching </text:p>. I remember fixing one of these in
the admonition-support when icons where not enabled, maybe you pulled
before that fix was added 4 days ago ?
https://github.com/dagwieers/asciidoc-odf/commit/80b588d45327fb425e16f324d2b27be0c9cec2a2
Using "xmllint --format" and looking at the file makes it very easy to
debug. FODT helps a lot in that regard !
I tried a simple single paragraph document, it displayed fine.
I actually added the asciidoc.txt as a test example, because it's
currently the most complex test we have. My own test-document is there to
highlight some known problems (rendering/styling) we still need to fix.
It works here when doing:
# asciidoc -b odt -a icons -a iconsdir=/usr/share/asciidoc/images/icons
examples/asciidoc.txt
or
# asciidoc -b odt examples/asciidoc.txt
I am using LibreOffice 3.4.3 for testing, and it works fine here:
[dag@moria asciidoc-odf]$ /opt/libreoffice3.4/program/swriter
examples/asciidoc.fodt
[dag@moria asciidoc-odf]$
That said, we have some difficulties with the current asciidoc tool and
how ODF works that I would like to discuss with you (now that you're
back), some of these have been discussed between Lex and me and are
available from:
https://github.com/dagwieers/asciidoc-odf/issues
I realise that AsciiDoc was not designed with some of the specific
requirements the ODF format needs, but I hope we can somehow foresee the
changes needed in asciidoc for the benefit of ODF and maybe other future
back-ends without impacting existing backends.
The ones that are tagged 'AsciiDoc' are the ones that I wanted to bring up
here. I would appreciate your insights on each:
- Preserve line-breaks and whitespaces in listing blocks
https://github.com/dagwieers/asciidoc-odf/issues/2
The ODF specification automatically discards consecutive whitespaces
(incl. newlines) and expects <text:s/> and <text:line-break/> instead.
Currently we have implemented our needs using a line_break.py filter,
and modified the code-filter.py, but the problem is that it makes it
hard or impossible to use other filters, unless they get a similar fix
for ODF.
If AsciiDoc would be (made) aware of this requirement, we could tell
the backend.conf that this format requires whitespace-translations for
literal blocks. Maybe a block-attribute or something is needed ?
Another problem with ODF and whitespaces is that any newline introduced
in paragraphs is considered a whitespace too. Which means that if you
add a line-break, and the line-break also adds a newline, the next line
starts with a whitespace. Because of this my current converted ODF
files contain a lot of spurious whitespaces that are hard to get rid
of. Here AsciiDoc could also be careful not to add any newlines.
Unfortunately when using 'conditional attributes' that are line-based,
newlines are omnipresent in paragraph text :-(
- Allow to use macros inside stylesheets
https://github.com/dagwieers/asciidoc-odf/issues/15
The problem here is that a few of the attributes in ODF need exposure
inside the stylesheet. If not we need to create a different set of
stylesheets based on the attribute, which becomes quite complex very
quickly (every additional attribute leads to 2^x combinations :-/)
For example, {numbered} is done in ODF using styles, and currently
unsupported (in fact numbered sections is in the default stylesheets)
- Better admonitions
https://github.com/dagwieers/asciidoc-odf/issues/12
Currently admonitions are bitmaps (ODF can do SVG natively) and seem to
have some whitespace added to help with positioning. This makes it
harder to place well in ODF (where we have less means of placing it
differently with the current implementation).
- Creating ODF variables from attribute entries
https://github.com/dagwieers/asciidoc-odf/issues/11
Since header/footer-text is part of the styles, influencing the
header/footers requires some mechanism to modify styles (issue #15)
Being able to add attributes automatically as ODF variables, they would
be available inside ODF fr other uses.
- Page breaks (soft-page-break element) fails to work
https://github.com/dagwieers/asciidoc-odf/issues/10
Work-around here is to add an empty paragraph with a page-break-after
attribute set. Problem is that adding an empty paragraph exposes an
empty paragraph in the text. Which is suboptimal, being able to
influence the existing paragraph when a page-break is added would be
very useful for ODF.
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.
