Text wrapping can mess up latex templaes

[eliocamp]

The (new?) default pandoc behaviour of wrapping long lines can cause issues in templates if there are comments.

For example, if the template has something like this

% \title{$title$}

and if title is long enough to reach the line-wrap character length, then this gets interpolated into something like

% \title{This is a very long title that pandoc will 
wrap into a new line}

This can create all sorts of errors that are very hard to debug. I encountered this issue during a tutorial on creating LaTeX templates and a student was trying different things and commenting out some of them.

Auto wrap also caused issues in bookdown and distill and was solved by adding --wrap=preserve to pandoc arguments.

---

By filing an issue to this repo, I promise that

• [ x ] I have fully read the issue guide at https://yihui.name/issue/.
• [ x ] I have provided the necessary information about my issue.
  • If I'm asking a question, I have already asked it on Stack Overflow or RStudio Community, waited for at least 24 hours, and included a link to my question there.
  • If I'm filing a bug report, I have included a minimal, self-contained, and reproducible example, and have also included xfun::session_info('rticles'). I have upgraded all my packages to their latest versions (e.g., R, RStudio, and R packages), and also tried the development version: remotes::install_github('rstudio/rticles').
  • If I have posted the same issue elsewhere, I have also mentioned it in this issue.
• [ x ] I have learned the Github Markdown syntax, and formatted my issue correctly.

I understand that my issue may be closed if I don't fulfill my promises.

[cderv]

The --wrap change which caused issue in distill and bookdown was impacting HTML only. The change in Pandoc 2.17 was for HTML only : https://pandoc.org/releases.html#pandoc-2.17-2022-01-12

So this may be something else.

I can't reproduce with current template any line wrapping for articles when putting very long title.

Can you provide a reproducible example ?

[eliocamp]

I think this might work. I created an elsevier journal article with the current CRAN version of rticles. I changed the title to a long string. In the .tex file the title is wrapped in line 122-124

  \title{Short PaperShort PaperShort PaperShort PaperShort PaperShort
PaperShort PaperShort PaperShort PaperShort PaperShort PaperShort
PaperShort PaperShort PaperShort PaperShort PaperShort PaperShort Paper}

(weirdly, it is not wrapped inline 46, no idea why)
long paper.zip

In this second example, I extracted the elsevier template and modified it to add a latex comment in line 189

% $title$ %

In the resulting .tex file, the comment is interpolated and broken in lines 119 - 122

% Short PaperShort PaperShort PaperShort PaperShort PaperShort
PaperShort PaperShort PaperShort PaperShort PaperShort PaperShort
PaperShort PaperShort PaperShort PaperShort PaperShort PaperShort
Paper %

Amusingly, the rendered PDF shows these lines in the text 🤣

long paper 2.zip

[cderv]

I can reproduce what you see with older Pandoc version like 2.7.3 or 2.10

I believe --wrap=auto is the default for LaTeX conversion from markdown in Pandoc.

Going to new line in a LaTeX command is something allowed I believed and I don't think it has ever caused an issue in the passed (@yihui do you remember something ?)

Doing something like

% \title{$title$}

is pretty specific as the Pandoc's variable will be field in a commented line. Pandoc's does not seem to account to that, and so the wrapping will happen and cause issue because the new line won't have comment.

I would think this is a Pandoc limitation. We could tweak our pdf_document format to default to --wrap=preserve maybe. 🤔
but it is the first time this was reported it seems and it cause issue only with comment and Pandoc's variable, which is quite limited and it should not really happen.

If you want to comment a line in a Pandoc's template so that it does not apply during rendering, there is a specific syntax for that BTW https://pandoc.org/MANUAL.html#comments:

$-- This will not be shown in the output after Pandoc's template resolution. 
$-- Useful to add comments in a Pandoc's template

Is this causing any specific issue or did you just report because you were surprised by the behavior (which is awesome too) ?

[yihui]

Going to new line in a LaTeX command is something allowed I believed and I don't think it has ever caused an issue in the passed (@yihui do you remember something ?)

It is allowed.

$-- Useful to add comments in a Pandoc's template

I'd strongly recommend using the template comment syntax instead of LaTeX comment. The latter can generate unpredictable results that are not necessarily comments. The former is guaranteed to work.

[eliocamp]

Yes, it is a relatively niche and specific failure case, but it is realistic, as I encountered this live when teaching LaTeX templating and a student had commented out a couple of template lines that didn't quite work. As it's usual for LaTeX, the error messages were obscure and it took us a while to understand what was going on. So it's possible to get this during development process if one is not aware of pandoc-style comments.

My vote would be to add --wrap=preserve unless there is a strong downside in doing so.

[cderv]

as I encountered this live when teaching LaTeX templating and a student had commented out a couple of template lines that didn't quite work.

Commenting out lines in a Pandoc's template as part of development process seems a usual practice, but comment syntax for templates is $-- not the comment character for specific output file.

My vote would be to add --wrap=preserve unless there is a strong downside in doing so.

It seems to me that changing to --wrap=preserve only to solve the above situation is too impactful. It would change all the .tex file generated by rmarkdown which can be surprising as going to line is valid for LaTeX block. And in addition, if anyone is using regex matching for post processing it would break I believe (the same way as --wrap change in Pandoc broke stuff for us).