Hi Stephane, As you noted, this is actually the ML for the Asciidoc Python implementation. As your questions are specifically about the Asciidoctor implementation its probably best to ask there.
Cheers Lex On Mon, 15 Oct 2018 at 23:32, Stéphane Gourichon <[email protected]> wrote: > > Hi Dan, > > Finally I understand that Thomas' need cannot be satisfied at all at > document process time, because the URL isn't known at that time. But > your answer raise an interesting point about extensions, so I send this > question anyway. > I ask because overall it is suggested that there are powerful > combinations, but I can't grasp them clearly from the documents I've > found on the net. So let's go. > > Thanks for your reply mentioning extensions. Can you elaborate? For one > thing, are your referring to asciidoctor extensions, cf. > https://asciidoctor.org/docs/extensions/ ? I thought this group was > about the old asciidoc implementation. > > A need similar to what Thomas expressed is the need for assets root URL. > For example, HTML pages would have a root URL, and *some* documents > linked from them would be deployed from a different URL root. > > My first idea would be to post-process the generated document. Somehow > more "integrated" could be to write an asciidoc extension, if that's > really easy, like put a simple extension file in the same directory as > the document being processed, with some short ruby code. > > The postprocessing option may be doable with a tool like xmlstarlet > (xmlstarlet can definitely select elements and change their attributes, > but I'm not sure it offers processing options for element text), a XSLT > stylesheet (worldwide standard with plenty of rock-solid > implementations, but not easy to learn), or even a crude sed script with > some caveats (much simpler and shorter but take care of not substituting > text in irrelevant places). That would be a sane setup because it does > not impose any burden on the consumer of the document, cf my other > answer to another leaf of the thread tree. > > Back to my first question, can you elaborate? Illustrating how > extensions would apply in this case would be very interesting to grasp > the extent of purposes which extensions API can serve. > > Is the "browser extension" you mention > https://github.com/asciidoctor/asciidoctor-browser-extension ? Can this > extension easily generate plain HTML documents that can be read by a > vanilla browser? > > Thanks you for clarifications. > > > Le 2018-10-15 à 11:31, Dan Allen a écrit : > > > I was hoping that I could solve the puzzle directly in AsciiDoc > > because I can't influence which rendering engine will be used. > > > > That's exactly why we created the extensions API. > > > > > I will test if GitLab ... or even better Asciidoctor.js Live Preview > > understands those macros > > > > GitLab (and GitHub for that matter) will not use macros. They will > > show as unprocessed. You can load extensions into the browser extension. > > > > -Dan > > -- > Stéphane Gourichon > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/asciidoc. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
