@uli-f, I am not entirely sure what is the intention. If I look at the test, what is actually being tested by the repetitive .depict(atomContainer) call? Without the fix, what happens that should not have happened?

@uli-f, I am not entirely sure what is the intention. If I look at the test, what is actually being tested by the repetitive .depict(atomContainer) call? Without the fix, what happens that should not have happened?

Yes, that's correct, the test is about the repetitive .depict(atomContainer) call.

Without the fix the property StandardGenerator.ANNOTATION_LABEL that is meant to be used temporarily during depiction generation (at least that's how I understood the intention) is not removed. So there is an unintended side effect to the method call and the 2nd time depict is called an UnsupportedOperationException is thrown b/c only one StandardGenerator.ANNOTATION_LABEL per atom is allowed.

It's not quite temporary, you can usefully use it for whatever you want. If however it has been set by one of the options you are correct it should be cleaned up.

p.s. the atom value/comments you can input like this. Useful for locant labelling which are not purely atom numbers (e.g. OPSIN has a mode to generate them).

C1CCCCC1 |$_AV:1a;2b;3;4$|