Asciidoctor-pdf: {counter: attribute} counts up by 2 when it's used inside admonition

[aokiplayer]

Counter value increments by 2 when I use {counter: attribute} inside admonition like NOTE, CAUTION.
I expected 0, 1, 2, 3, 4, 5. But actual values are 0, 1, 2, 4, 6, 7.

Source

:my-count: 0

== Initial value
Current number is {my-count}.

== One is expected
Current number is {counter:my-count}.

== Two is expected
Current number is {counter:my-count}.

== Three is expected
NOTE: Current number is {counter:my-count}.

== Four is expected
CAUTION: Current number is {counter:my-count}.

== Five is expected
Current number is {counter:my-count}.

Output
example.pdf

[mojavelinux]

This is due to the fact that admonitions blocks are rendered twice, once in a scratch document, then once in the main document.

There isn't an easy solution for this for counters since counters can be any attribute. But what could be done is to snapshot the attributes before rendering in the scratch document and restoring them afterwards. That feels a bit crude, but I can't think of another way right now.

Btw, this is going to be true for any block that uses the scratch document to determine its own dimensions.

[znerd]

To me (and my use-cases) this is a critical issue, as it basically stops me from being able to use counters when targeting PDF output.

[mojavelinux]

What I can recommend is to increment the counter outside of the admonition block using the counter2 attribute function. The line containing this function gets dropped, so it will not get displayed.

== One is expected

{counter2:my-count}
NOTE: Current number is {my-count}.

== Two is expected

{counter2:my-count}
CAUTION: Current number is {my-count}.

[znerd]

@mojavelinux : That sounds like a useful workaround for the time being – thanks!

[aokiplayer]

My current workaround is same as @mojavelinux 's one.

[znerd]

Tried it out and this does not work (it still triggers the double bumping of the counter):

IMPORTANT: {counter2:req} *Requirement {req}:*
This is the requirement text.

However, the following does work:

{counter2:req}

IMPORTANT: *Requirement {req}:*
This is the requirement text.

So it appears to be significant that the {counter2} macro is invoked outside of a rendered block.

[mojavelinux]

it appears to be significant that the {counter2} macro is invoked outside of a rendered block.

You are exactly correct. If you look closely, that's what I was suggesting.

[mojavelinux]

Note that this side effect will mostly go away once we switch to breakable blocks by default in Asciidoctor PDF 2. The converter will not attempt to dry run the block and thus it won't be rendered multiple times. Unbreakable blocks will still be affected...and there's no much we can do to change that (at least not in this converter).