The official chat room for Asciidoctor, a modern text processor and publishing toolchain for the AsciiDoc markup language.
I'm just kind of getting the sense that you are making this harder than it needs to be
and what I mean by that is that you are trying to change too many variables at once, so you are ending up getting yourself twisted into knots
start with the simplest thing and get that working, then gradually enhance it
I would start by using the preprocessor to convert
// REMARK content into an admonition paragraph. get that working first, then take the next step
Good Sunday.
I'm looking for adding classes to headings. In our case we have a DND Campaign, with bunch of important NPCs. The Idea was that the NPC's get an icon based on if they are: friendly, enemies, merchants etc. My idea was to solve this by adding classes to headings. Which then act as kind of a label. I'm not sure if solving this with classes is the best solution and would I need to write a plugin for asciidoctor to achieve that?
I'm looking for adding classes to headings. In our case we have a DND Campaign, with bunch of important NPCs. The Idea was that the NPC's get an icon based on if they are: friendly, enemies, merchants etc. My idea was to solve this by adding classes to headings. Which then act as kind of a label. I'm not sure if solving this with classes is the best solution and would I need to write a plugin for asciidoctor to achieve that?
This seems a good case for roles(https://asciidoctor.org/docs/user-manual/#role). But I wasn't able to add them to the heading (h2, h3 element), but only to the whole section div. Not sure if this is on purpose
But in this case it make sense semantically, and you can even combine classes, with just
[.merchant.enemy]
=== NPC 1
[.merchant.friendly]
=== NPC 2
@abelsromero you are correct about roles
But I wasn't able to add them to the heading (h2, h3 element), but only to the whole section div. Not sure if this is on purpose
yes, that's intentional. if we add it directly to the heading element, then you can't style the section. but since we add it to the section element, you can style either. the heading is styled used .sect1.rolename > h2 (and so forth)
it's one of those cases where it seems obvious to add it directly to the heading at first, but when you think about all the use cases, you realize it should be on the section container
I know this has a good explanation, but it would be helpful to get a clear picture for teaching others why this is the case.
there can be no confusion about where they are, so they are the most lenient about blank lines
but I strongly discourage putting content directly against them for readability and consistency
if the wrap occurs right before the asterisk, it would become a list
and you would be amazed at how common this is (as I've often had to deal with it when migrating content)
not that marker specifically, but there are many list markers
the more common would be
"When we scanned the room, we counted about 20. Most of them were there for the food."
if the wrap happened right after "about", the next line would end up being a list item
and then give a very strange and unexpected warning that the list counter is out of sequence.
I am still working it out with colleagues but which of the following two examples looks cleaner, thoughts?
To do foo, use teh [command]``foo`` command:
----
foo --bar
----
To do bat, use the [command]``bat`` command:
----
bat --bar
----
Anything wrong with this?
We are throwing together a BP guide for our contribs
To do foo, use teh [command]``foo`` command:
----
foo --bar
----
To do bat, use the [command]``bat`` command:
----
bat --bar
----
Ugh semantics.
[.mark]+foo+
(though we should probably support the highlighting mark now that Asciidoctor PDF supports inline background colors).
file an issue
I would like to add the final output of each pdf to a single file, then echo it at the end of the build for clarity.