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.
