Hi,
I want to create a new adoc file dynamically using blocks, in the following way: doc = Asciidoctor::Document.new .... doc << block1 doc << block2 ... If I do that, is it possible to write the source content to a new adoc file? I don't want to convert it at this point, I just want to read an adoc file and generate a new file with some modifications. It is like a converter to Asciidoc itself or a pretty printer for Asciidoctor::Document Thanks guido |
I don’t think there’s an actual converter that can be used with asciidoctor that can do this.
It’s possible that asciidoctor-kramdown has something similar, as it emits asciidoc. One difficulty with this is that it’s easy to create block trees that can render fine to html but that cannot be created from an asciidoc document. For instance, it’s possible to have the blocks in a section be paragraph, section, paragraph, but when parsing asciidoc all the subsections have to be at the end of the blocks, with no paragraph blocks following. David Jencks
|
Hi David,
Thank you for the anwser, I will look into asciidoctor-kramdown to see how this tool creates the asciidoc files. I need to walk over the block tree and translate the content (text only) and write the same file but translated. I want to take advantage of the parser and work with blocks or abstract blocks but it seems that it is not enough. (I don't care at the moment with include: directives) Thanks |
Administrator
|
In reply to this post by guidog
> is it possible to write the source content to a new adoc file? Asciidoctor does not currently have an AsciiDoc backend. It's possible to create one, but someone has to do it. I have no doubt it would be useful to have. Up to this point, I have generated AsciiDoc using string concatenation. Another route is to convert to DocBook, then use docbookrx to convert back to AsciiDoc. Best Regards, -Dan On Thu, Aug 13, 2020 at 8:12 AM guidog [via Asciidoctor :: Discussion] <[hidden email]> wrote: Hi, -- Dan Allen (he, him, his) | @mojavelinux | https://twitter.com/mojavelinux |
Thanks for the answer Dan
I am checking both approach at this moment, create a backend to AsciiDoc or use some XML as intermediate languages. It is possible that a backend (using converter) or a pretty printer (using doc.blocks) will not be same as the original code because there are instructions like #ifdef or any code executed by the preprossor or the parser (syntax sugar/alias). It is not a problem in my case, but I expect this kind of issues. I'll let you know when I have something functional, even if it doesn't cover all functionality. I think the basic ideas about walk over the tree are explained in an old thread: https://discuss.asciidoctor.org/Walking-the-Asciidoctor-document-tree-td479.html Also I am checking about the different extensions. https://asciidoctor-docs.netlify.app/asciidoctor/1.5/api/register-extensions/ Regards, guido |
Administrator
|
guido, Yes, it's true that a converter cannot reproduce exactly the same document as the input. For one, the preprocessor reader runs before the parser and omits certain lines. But the parser also doesn't keep track of where it took metadata, so it's not possible for instance to recreate the attributes on a node (block or inline) in the exact same way. However, you could emit something more tidy ;) > I'll let you know when I have something functional, even if it doesn't cover all functionality. That's great news. I look forward to seeing it. Best Regards, -Dan -- Dan Allen (he, him, his) | @mojavelinux | https://twitter.com/mojavelinux |
Free forum by Nabble | Edit this page |