How to highlight changes made in the manuscript as part of a revise and resubmit?

Question

We have a journal paper that got correction requests and need to be resubmitted. The changes need to be highlighted in the manuscript. How do you mark the changes? Is changing the text color enough? What if the reviewer/editor does not have a colored printer? or has color blindness?

I tried underlined text but the manuscript looked ugly and I am afraid this journal has early version that goes live after acceptance as is. Any suggestions from experience?

Edit:

Thanks for all the responses. Just for clarity: I assumed that the changes need to be highlighted in the manuscript. The editor did not specify.

Answer 1

TL;DR Explain the changes in a different document

Send the new article without any marks and a separate document where you detail how you have included the changes suggested or why you have decided not to include them. For instance:

• Reviewer suggests including topic X, we have done so in Section 6.4
• Reviewer suggests including topic Y. However, we disagree because of Z.

I agree with @Buffy on the need of having a publishable paper without modifications. I don't find it necessary either to have the changes marked letter by letter.

However, I believe it is convenient to mention in which part of the paper the changes have been made. If the reviewers are the same, they will find the resubmission easier to follow. If they are different, they will still find a publishable paper to read.

Answer 2

If you are writing in Latex, I recommend Latexdiff; its default seems pretty good:

(Image shamelessly stolen from Track changes with latexdiff).

Sometimes it chokes on some equations and complicated nested environments, but in general it's a great tool that does not require you to track changes by hand.

So, what I am suggesting including in a revision:

1. a clean, "publishable" version of the revised document;

2. the output of latexdiff (between the previous and current revision), to display changes;

3. a separate "response to reviewers" document that addresses the major points raised by the referees (there's no point in describing minor changes such as "yes, we have corrected typos 1, 2, 3, 4, 5").

Answer 3

There is more than one way to do this. Often the journal editor states exactly what you should do. If not, you can always ask the editor.

The most common and most accurate method is to use the change tracking function of MS Word (under the Review tab). That way you have an exact record of everything you deleted and inserted. The big disadvantage of this is that if you delete a large section, it gets moved to the right margin and is pretty messy. An alternative is to track only your insertions, not deletions.

Some journals ask you to highlight your changes. I don't think you have to worry about color printers as the reviewers will most likely read your revised paper on the screen, not hard copy. Color blind reviewers might see your changes in gray, which is OK too.

The final important step is to submit a separate document that describes your changes persuasively. Set the document up like this:

Reviewer 1

Comment: Please clarify your argument about xx on p. 3.

Reply: I have reframed the argument as follows: "xxx"

Do this for every comment from every reviewer to show that you've done everything they asked you to do. If you disagree with a comment, explain why (diplomatically). Including this document also helps the journal editor detect unfair and incorrect criticism from reviewers, which happens a lot, including when the reviewers don't really read the paper.

Answer 4

If you are using Microsoft Word, then you can use the compare documents feature. Simply use the original submission and the updated submission in the compare documents dialog. Put label changes with "Author" to ensure anonymity (i.e., blind review). This will generate a track changes version of the document showing the changes made between the original and revised documents.

You can then upload this track change version as part of your submission (perhaps in addition to the final version without track changes) to highlight the changes you have made.

Answer 5

One option that clearly indicates the changed parts, is colorblind-safe, and doesn't look ugly would be to highlight the changed portions with vertical black change bars along the outside edge of the page.

Example of this type of change-highlighting in the wild:

Answer 6

Other answers have addressed the workflow and submission aspects, but regarding the actual marking up, underlining is a very useful way of showing changes

This is precisely because it's too ugly to make the final version and not routinely used for emphasis (bold and italic may appear in the final document). It also prints well whatever your printer. I've used it quite a bit in internal reviewing, where the reviewer, e.g. co-author, may be working on screen or paper depending on whether they're in the office or travelling when they get time to have a look (even in one case on a Kindle with B&W e-ink display).

It also pairs well with strikethrough for removed text.

LaTeX packages soul and ulem (with the [normalem] option) will allow you to do this if you're using LaTeX and don't want to use a more specific change-tracking package.

Answer 7

I'm assuming the editor hasn't actually required you for a marked up document. In that case, follow their instructions.

Otherwise, I would just write the new version, making the changes you feel warranted. Don't bother to mark it up. When you resubmit it, send the editor a separate communication that says something like "We addressed all of the reviewer comments except...", and detail the ones you left undone along with a bit of reasoning.

The new reviewers might or might not be the same as the old ones. What they want to see, in either case, is a good, publishable, paper, not obeisance on conformity to their earlier comments. The editor can pass this document along with the paper.

If you start to mark it up with many changes you then get faced with indexing the changes to the reviewer comments. Messy, hard to read, and, moreover, it can force the reviewer into a mind-set that isn't optimal for a good paper. Comparing the old to the new isn't the point.

Answer 8

Aside from a separate document, where you can much better and in a more focused manner reply to the requests of the reviewers, I tend to prepare a full diff, even if only for myself.

latexdiff was already mentioned, but if you use some kind of a version control for you paper (you rather should if you use it anyway for your code), there is another option. Here, I use git.

git diff --word-diff --color <old-state> HEAD file1 file2 file3

will give you a difference output, colored, on a terminal. Let's improve that with ansi2html and few tweaks:

• use a script to convert terminal colors to HTML
• adjust it a bit with sed
• use a make rule to generate it automatically, e.g. when building a PDF:

Here is the complete rule for your Makefile (if you have one).

diff.html : content.md content.tex full.bib Makefile
    git diff --word-diff --color submission1 HEAD content.md full.bib | sh ~/bin/ansi2html.sh | sed -e 's|<style type="text/css">|<style type="text/css"> pre { white-space: pre-wrap; } |g' > diff.html

Here is how it looks like in the final diff.html:

There are many other fancy things, like letting a CI build your paper on each commit to a remote repo, but that's a story for another time.