BUG: adjacent comments in Word Files get overwritten

Hi,
scrivener latest version as of today, Win10

Import a docx file with comments
gets converted to rtf
create a new comment which is directly subsequently adjacent in the text to the existing one in the file
export as docx
the previous comment is now overwritten with the content of the new comment, the new comment is also there additionally

Expected behaviour is that both comments exist in the export file. The scrivener project file shows both comments intact, it is only in the exported docx that the previous original comment gets overwritten.

Tested on two separate systems

I’m having troubles reproducing this using a method that would create an adjacent comment. I can of course contrive a scenario where I deliberately delete the previous comment by allowing the software to overwrite a single-word highlight with a new highlight, but that doesn’t require importing a DOCX, that’s how the comment feature works overall. For example:

  1. Put the cursor on a word without a comment and use Insert â–¸ Comment to add one to it.
  2. Put the cursor right after the highlighted word and use Insert â–¸ Comment to overwrite the comment with a new one.

Instead if I instruct the software to make an adjacent comment, it works fine:

  1. Put the cursor on a word without a comment and use Insert â–¸ Comment to add one to it.
  2. Starting from the end of the previous comment, select the next word or two and use Insert â–¸ Comment to add an adjacent comment.

Let me know if that isn’t what you are seeing or doing, and if so, what should I be doing differently?

Hi @AmberV and thanks for getting back to me on this so quickly!

  • I mention import/export explicitly, as this bug refers to what happens if I export comments in an imported docx document with comments which got automatically converted to RTF and is compiled with the target docx on export

when I follow the instructions I gave in the post above, this is what is shown in Scrivener:
WhatsApp Image 2023-06-21 at 22.35.17

on export, this is the result in the word document

WhatsApp Image 2023-06-21 at 22.35.35

If I am overwriting a comment by placing my subsequent comment too close to the previous one (more on that in a moment), I need to see that immediately within Scrivener, not on export. That is too late and confusing and makes managing a document with a lot of comments unfeasible.

On when a comment actually overwrites a previous one:
My intuitive reaction was that one marked up spot in a document should be able to contain several comments. I say that, because it is how Word handles comments. But that is more like a feature request.

However, when I saw that adding a comment (to reply to the previous one) within the same content overwrites, I tried placing the cursor right next to the highlighted area which means “no whitespace between, but next to it”. That overwrites the previous comment, too - but only in the exported version! I need to see immediately that this happens on export. Or something is going wrong on export.

In general, I would kind of prefer a behaviour where one highlight can belong to several comments, because right now, in order to react to commentary by editors, I would have to either edit their comment or add another comment belonging to some other area of the document which is confusing even if it’s close by.

At any rate, if comments are being exported as overwritten due to how Scrivener handles the relationships between comments and highlighted text I need to see that immediately, because if it happens on export only it makes several rounds of revisions with to and fro between two people handling a large document with many comments quite confusing.

Hope that clarifies what this is about?

1 Like

Thank you for the clarification! I missed the crucial ingredient of having to export in order to see the problem, as all appears to be fine in Scrivener with that condition, even after a project reload.

I’ll test this a bit further and get written up for the developer. I noticed it also happens with adjacent inline annotations (which can be achieved by changing the annotation colour). That is unfortunate, as I was going to suggest that could be a bit of a workaround, since inline annotations to me make more sense for a sequence of comments anyway than piling a bunch onto fragments of a word, given how highlighting works.

At any rate, if comments are being exported as overwritten due to how Scrivener handles the relationships between comments and highlighted text I need to see that immediately…

Well, we would want to fix the export problem rather than bring that problem over into the editor as well, and have it delete comments you put right next to each other. Perhaps I don’t understand though.

Thanks for your reply!

What I meant with I would like to see that immediately, is that by then I would still have a chance to edit the placement of my comment to make the revision process work better. But I agree that it much more preferable to make the export work so it reflects what is shown within Scrivener.

Anyway, I hope the problem is now clear, so it can possibly be dealt with in future versions.
If it needs more details or testing, let me know!

Yeah, part of the problem with making it so the editor warns you or something is that it should be perfectly acceptable to have adjacent comments like that, and in fact that is how reply chains should import (though I don’t think that is implemented yet). So we’d have to sort that out anyway since the software itself would ideally create that condition.

1 Like