Preserve line-breaks and whitespaces in listing blocks

[dagwieers]

Since ODF (XML) discards newlines and consecutive whitespaces, listing blocks and other elements that need to preserve newlines and consecutive whitespaced need them substituted with ODF line-breaks (text:line-break/) and UTF whitespaces.

[dagwieers]

This is one of the more important issues. Currently listingblock or literalblock are useless, and unfortunately both are mandatory for technical documentation. Without a solution in asciidoc for this, we are doomed :-)

PS The solution needs to be part of asciidoc IMO, and not something bolt on afterwards in a2x. The asciidoc script should have the infrastructure to allow backends to replace newlines by a string-sequence for certain types of blocks. (cfr. <pre>).

[elextr]

I think we can add a filter to [blockdef-listing] and have that add the line breaks.

[elextr]

The example line_break.py filter added (it wraps each line in a listing block in paragraphs as an example).

So if you can define exactly what the filter needs to do I can modify line_break.py to do it without needing to modify asciidoc.

[dagwieers]

On Mon, 17 Oct 2011, elextr wrote:

The example line_break.py filter added (it wraps each line in a listing block in paragraphs as an example).

So if you can define exactly what the filter needs to do I can modify line_break.py to do it without needing to modify asciidoc.

It can stay as one paragraph, but we have to add the line-breaks manually. So replacing the newlines with line-breaks is what we probably need.

If at some point there is syntax-highlighting, I am not sure if there order of the filters becomes important ?

A line-break in ODF looks like: text:line-break/

-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

[elextr]

Ok, but what about keeping leading whitespace?

[dagwieers]

On Mon, 17 Oct 2011, elextr wrote:

Ok, but what about keeping leading whitespace?

Right, those would be replaced with text:s/, and probably you want the more condensed formatting to collate two or more white space characters in accordance to "6.1.2 White Space Character", "6.1.3 text:s" and "19.763 text:c".

-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

[elextr]

Added to line-break.py, only works for block listings, but literals, inlines and other unstyled entities should be just a matter of copying the blockdef.

Entities with styles that activate other filters either need the other filters to do the same (integrated into code-filter as example) or need to pass the output of the filters through line-break.py

[dagwieers]

Somehow my feeling is that this should be integrated in asciidoc. Surely ODT is not the only XML specification that ignores newlines and consecutive spaces. And this is typically something you may want to introduce after running the content through filters. AsciiDoc knows which blocks requires to preserve newlines and consecutive spaces, so if the backend configuration whould eg. have attributes for this:

[attributes]
preserve_whitespaces=<text:s text:c="\1"/>
preserve_linebreaks=<text:line-break/>

It could do the right thing automatically. I noticed there is a [replacements2] section wrt. line-breaks, but that's about forced line-breaks, rather than listing blocks. I think we should discuss the details on the AsciiDoc mailinglist with Stuart.

[dagwieers]

Closing this issue because a working implementation exists.

I still would prefer some changes to asciidoc to allow the proper replacements done by asciidoc, instructed by the backend.

[dagwieers]

More information about the fix and the related discussions at: https://github.com/dagwieers/asciidoc-odf/commit/2d6e23e1f8ac82a54f0ed19c56a3ddd75c68de5b