latexdiff introduces vertical white space

[bersbersbers]

If you compare old.tex and new.tex using latexdiff (as done in makediff.bat.txt), you will get diff.tex which has additional white space after the newly introduced paragraph.

Here's snapshots of old, new, and diff:

Here's the pdf files: old.pdf, new.pdf, diff.pdf

[ftilmann]

Thanks for the report but I will not fix it. This is simply too much of an edge case and also it is to some extent beyond latexdiff's control: If I remove or add a few 'x's (mayeb only one) it works as expected, so it must depend on just reaching a critical line length. Actually, it is not a bug in latexdiff directly, but a bug in the ulem package which is used for underlining. You can see this by using -t CFONT option, which does not make use of ulem, and where the bug does not appear. If you really care about this I recommend taking it up with the ulem maintainer.

[bersbersbers]

I can understand it may be lot of work. But:

• It happens at least three times in my (9-page, twocolum, IEEEtran) document. So it's not that much of an edge case. Maybe I'm just good at optimizing line lengths to minimize numbers of lines, but I see it regularly.
• It has nothing to do with the ulem package. This MWE reproduces the same effect without it:

\documentclass[a4paper]{article}
\usepackage{color}
\providecommand{\DIFadd}[1]{{\color{blue}#1}}
\providecommand{\DIFaddbegin}{}
\providecommand{\DIFaddend}{}

\begin{document}
foo

\DIFaddbegin \DIFadd{xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x x x x x x x x x x x
}

\DIFaddend bar
\end{document}

• Also, it doesn't have anything to do with the color package:

\documentclass[a4paper]{article}
\makeatletter
\providecommand{\foo}{\write\@auxout{}}
\providecommand{\DIFadd}[1]{{\aftergroup\foo#1}}
\providecommand{\DIFaddbegin}{}
\providecommand{\DIFaddend}{}

\begin{document}
foo

\DIFaddbegin \DIFadd{xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x x x x x x x x x x x
}

\DIFaddend bar
\end{document}

• The problem is caused by the } having an extra (unnecessary?) newline in front.

• There is a workaround that I use: cat diff.tex | tr -d '\r' | tr '\n' \000 | sed -e 's-\(\o000[^^%%]*\)\o000}-\1}-g' | tr \000 '\n' >> diff.tex Update: cat diff.tex | tr -d '\r' | tr '\n' \000 | sed -e 's-\(\o000[^^\o000%%]*\)\o000}-\1}-g' | tr \000 '\n' >> diff.tex Basically, it converts all EOLs to '\n' only (I'm on Windows) and then replaces them by by ASCII 0 characters (the whole file is a single line now.) Then, sed can be used to find EOL + at least (**update: exactly**) one line with no % + EOL + }, which is replaced by virtually the same thing without the second EOL; then the ASCII 0 EOLs are converted back to '\n'. This converts

\DIFaddbegin \DIFadd{xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x x x x x x x x x x x
}

into

\DIFaddbegin \DIFadd{xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x x x x x x x x x x x x x}

fixing the problem.

[ftilmann]

OK I take back that it is ulem's problem (-t CFONT indeed fixed the problem in this particular case, but this is because that style also changes the font with which new material is highlighted, getting the line outside the critical length).
I will also reopen, but please be aware that I still treat this bug as low priority. Newlines have always been quite fiddly to deal with, and it has taken some effort to at least stop latexdiff from either merging paragraphs in some situations, or introduce completely new breaks. Having an empty line is ugly, but does not really interfere with readability. Documents with change-highlighting ultimately are a simple intermediate step where cosmetic issues should usually not be as important (personally I would probably reserve the \twocolumn format for the final version only)

[bersbersbers]

Sounds good! I have a workaround anyway, so this bug is mostly for the purpose of not having that issue forgotten in case you ever deal with line breaks. Having some edge cases is always useful.

Note, by the way, that many IEEE journals ask for submission in the final twocolumn style from the first submission, AND ask for change highlighting from the first revision. So this bug does have some practical relevance ;)

[bersbersbers]

I probably should not do this, but to lower (I meant lower!) priority for this issue even further, here's a MWE where I really don't see how the white space added by the \color command can be prevented:

\documentclass{article}
\usepackage{color}
\begin{document}
	\begin{itemize}\item\end{itemize}%
%	\color{blue}%
	\section{}
\end{document}

This is also discussed here: https://tex.stackexchange.com/questions/46964/problem-with-specialcomment-command-and-equation-align-environments

[matteobachetti]

Hello, refreshing the thread. I'm having this problem in a paper formatted for Astrophysical Journal. Really don't know how to deal with this 😅 I tried to manually eliminate all the extra space before braces, but it does not seem to change the result.