Hi Guys, Stuart, congrats to the all blacks, grumble grumble ...
[...] > 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 :-) Yes, oo opened my test files ok, unfortunately I lost my hard disk on Monday so I no longer have an old oo to test with :( And I'm not fully back up yet. [...] > > 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. Well, the other filters have to generate ODF to be useful anyway, so I'm not sure that matters much. > > 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 ? My suggestion is more replacement groups and the ability to specify that only some of them should be applied to this block, so that blocks that need it can be specified to use a replacement group that other blocks don't. And that group can replace EOL with appropriate markup (yes this replacement group is backend dependent). > > 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 Well, I just suggest putting the line-break tag on the start of the next line so the whitespace is on the end of the previous line and invisible. (the way line-break.py was originally) > 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 :-/) I just had the thought, why not use include instead of include1? > > For example, {numbered} is done in ODF using styles, and currently > unsupported (in fact numbered sections is in the default stylesheets) > The {numbered} attribute has to select between two styles, it cannot be specified on the entity. > > - 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. Still not sure I understand this one Dag, maybe I'm a bit slow today. > > > - 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. > Stuart, can you look at the proposal for a2x extensions or some alternative so I can do more odf development to an official method. 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.
