Two bugs with descriptions in ConTeXt.
The first bug is that descriptions interfere with the counters, resulting in the peculiar behavior demonstrated in the resulting PDF. Unless I'm mistaken, I think it happens because the head of the description is evaluated twice, thus incrementing the counter twice---at least, that's the only explanation for how the number is incremented by 2 each time. Further, this issue seems to persist whether we're using macros or writing \incrementcounter directly. The solution is to either make sure that the head of descriptions is evaluated only once, or document that text placed as the head of descriptions is meant to be evaluated twice, if there's a good reason for doing so. Of course, this silly example of incrementing counters can be subdued by placing the \incrementcounter directly in the after option when customizing descriptions. But it demonstrates the issue. I've tried to make the examples given be as varied as possible, demonstrating the different ways in which descriptions interact with the counter. The second bug is that descriptions, or at least that's my intuitive expectation, shouldn't interfere with the bullets of items. I expect that the bullet stays where it is, and the description is placed next to it. But what happens is that the bullet is shifted to the right, making it overlap with the description's head, which isn't pretty. ConTeXt version 2024.1.24
SirColeman via ntg-context schrieb am 13.02.2024 um 22:04:
The first bug is that descriptions interfere with the counters, resulting in the peculiar behavior demonstrated in the resulting PDF.
Still no bug and there is no need to create your own counter because enumerations exist which are descriptions with a counter.
Unless I'm mistaken, I think it happens because the head of the description is evaluated twice, thus incrementing the counter twice---at least, that's the only explanation for how the number is incremented by 2 each time. Further, this issue seems to persist whether we're using macros or writing \incrementcounter directly.
The solution is to either make sure that the head of descriptions is evaluated only once, or document that text placed as the head of descriptions is meant to be evaluated twice, if there's a good reason for doing so. Of course, this silly example of incrementing counters can be subdued by placing the \incrementcounter directly in the after option when customizing descriptions. But it demonstrates the issue.
What you're supposed to do here is to increment the counter *before* you use the counter value. As you guessed the content of the title is evaluated multiple times to get the width of the description title, in cases where a counter is incremented in such a case (very common when you have counters in a table cell) you use the trialtypesetting mode to increment only once.
I've tried to make the examples given be as varied as possible, demonstrating the different ways in which descriptions interact with the counter.
The second bug is that descriptions, or at least that's my intuitive expectation, shouldn't interfere with the bullets of items. I expect that the bullet stays where it is, and the description is placed next to it. But what happens is that the bullet is shifted to the right, making it overlap with the description's head, which isn't pretty.
Is this even a real world example? The reason why the bullet points are at the wrong position is that descriptions and items use the same mechanism to set the text offset on the left and right sides and when you combine both mechanism the values are added. In case you you have a document where a descriptions appear as part of an item I suggest to use a different alternative (e.g. serried) for the description layout. Wolfgang
Oh dear... The serried alternative does indeed solve the second "bug". And to answer your question, I literally encountered this problem in one of my own documents, so yes, it's a real world problem... And also good to know the explanation of why the counter acts weird. I'll also check out enumerations, thanks. Also, I'll be more careful about what I call bugs, because apparently it's very possible that it's not a bug that I have to complain about. Thanks for your time.
participants (3)
-
Sir Coleman
-
SirColeman
-
Wolfgang Schuster