Tables get mangled when there is a pipe character inside a literal block within a table cellThe pipe character '|' needs to be escaped within table cells. However we have just discovered that it also needs to be escaped when it appears example.adoc (Source) |=== | 1 | Regular cells work before pipes | 2 | .... I'm some content within a literal block with a pipe here | and here | and I break the table. .... |=== example.html (Rendered)
environment $ asciidoctor -v Asciidoctor 1.5.2 [http://asciidoctor.org] Runtime Environment (ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]) I would imagine this is a potential improvement to the parser (to ignore pipes within literal blocks in table cells). However if this is a known issue and expected behaviour is it documented so we can point our team at it? If this is a bug let me know if you want me to file a bug on Github. I have searched the discussion board, and followed a couple of similar bug links to github. However this appears to be the first memntion I can find of pipes in literal blocks within table cells. The example I have given is pretty innocent. But in large, complex tables the destruction wrought is pretty impressive! Side note If the last character in a literal block within a table cell is an escaped pipe then you get this output: source |=== | 2 | .... I'm literal content with an escaped pipe as the last character \| .... |=== renders (in part) .... I'm literal content with an escaped pipe as the last character |.... Thanks the remarkable tool you have built. I have just sent my boss a link to your donation page! Our reference: OCDOC-200 |
Administrator
|
Hello Richard! On Tue, Aug 4, 2015 at 8:52 PM, richard [via Asciidoctor :: Discussion] <[hidden email]> wrote: However if this is a known issue and expected behaviour is it documented so we can point our team at it? Yep, I'm aware of this issue and it's something I'm still putting thought into. It's a tricky one to fix without breaking existing assumptions. I think what we may be able to do is change the parsing rules so that we only look for a pipe at the beginning of the line (optionally following column spec metadata). That doesn't fix 100% of the cases, but it should handle all but the edge cases. The reason this is tough is because the content inside an AsciiDoc table cell isn't parsed until after the end of the cell is found. Of course, that means how it finds the end of the cell may be incorrect. If the last character in a literal block within a table cell is an escaped pipe then you get this output: Uh oh. That looks like another bug. When it restores the pipe, it drops the endline and, as a result, the block doesn't render properly. Can you report this in the issue tracker? Thanks the remarkable tool you have built. I have just sent my boss a link to your donation page! Thank *you*! |
Thanks as always for the quick response.
I've created a ticket for the second issue: https://github.com/asciidoctor/asciidoctor/issues/1457 Also made a donation and my boss was asking how much to donate at stand up this morning :) Really appreciate what you do. I've put out for donations in previous projects and its an amazing feeling when people get behind you with real energy. PS - Have you ever considered building a tree/ui wrapper around Asciidoctor as a commercial arm to help fund your open source work on the parser? Our inhouse tool builds a document tree from Asciidoctor pages. It's deeply integrated into our infrastructure so would not make a good starting point. However I'm sure you could whip something up, especially with your in depth knowledge and flare for design. A tree wrapper makes Ascidoctor really amazing for massive technical documents and potentially could provide you with an income stream so you can do Asciidoctor full time. |
Administrator
|
Fixed!
I really appreciate the support. Thanks to the support from the Salt campaign, I've been able to continue working on Asciidoctor a little bit each day. I'd really hope to be able to do more and more because there's so many things we want to accomplish to make content creation awesome.
I'll have more information about what my vision is once I finally get the website up for my company. Work has kept me so busy that it has been taking longer than expected. Thanks again for your support! The community also thanks you! |
Thanks Dan!
Really appreciate your resolving the issue, the great work you do and your integrity. Best of luck with OpenDevise, you deserve it! |
Administrator
|
Richard, I had totally forgotten about another useful workaround for this issue. You can change the separator characters used for cells using the separator attribute on the table. [cols="1,1a",separator=¦] |=== ¦Pipe output to vim ¦ ---- asciidoctor -o - -s test.adoc | view - ---- |=== See https://github.com/asciidoctor/asciidoctor/issues/1421 to track the progress of documentation regarding this trick.
That really means a lot to hear you say that. It's exactly what I'm aiming to do, and I'll continue doing it. |
Free forum by Nabble | Edit this page |