Text references don't work with multiline lines

[eliocamp]

Text references don't seem to work if the text is split in multiple lines.

Example: Create a new bookdown project and go to 02-cross-refs.Rmd in the sample book and change the first figure to this:

(ref:caption) Here is a nice figure!

```{r nice-fig, fig.cap='(ref:caption)', out.width='80%', fig.asp=.75, fig.align='center', fig.alt='Plot with connected points showing that vapor pressure of mercury increases exponentially as temperature increases.'}
par(mar = c(4, 4, .1, .1))
plot(pressure, type = 'b', pch = 19)
```

As expected, text reference works and the caption is rendered where it should be:

Now add a new line:

(ref:caption) Here is a nice figure!
And this is a second sentence. 

```{r nice-fig, fig.cap='(ref:caption)', out.width='80%', fig.asp=.75, fig.align='center', fig.alt='Plot with connected points showing that vapor pressure of mercury increases exponentially as temperature increases.'}
par(mar = c(4, 4, .1, .1))
plot(pressure, type = 'b', pch = 19)
```

The text reference is still a single paragraph so, according to the documentation, it should still work. However, the ouput doesn't show the correct caption:

This seems to be an issue for HTML (gitbook and epub) and word formats. PDF renders correctly.

[mschilli87]

@eliocamp: Do you mind linking the documentation you mentioned? I always assumed this was by design. Either way, I can definitely confirm the behaviour you describe for as long as I remember using text references.

[eliocamp]

Here: https://bookdown.org/yihui/bookdown/markdown-extensions-by-bookdown.html#text-references it states that "The text can contain anything that Markdown supports, as long as it is one single paragraph."

In markdown (at least the flavour used by bookdown) sentences belonging to the same paragraph can be each in its own line. You need two newlines to define a new paragraph. (You can see that in the bad example, the text reference is rendered as a single paragraph).

Also, PDF output does work. This seems to be an issue for HTML (gitbook and epub) and word formats only.

[eliocamp]

The issue is around here:

https://github.com/rstudio/bookdown/blob/52c31aa2fa44111b9ea67fdc4004f0ecd036c20f/R/html.R#L807-L821

At this point x has one element per line instead of one element per paragraph; like this:

<p>(ref:caption) Here is a nice figure!
And this is a second sentence.</p>

So grep(r, x) doesn't find it (the line doesn't match r = "^<p>(\\(ref:[-/[:alnum:]]+\\)) (.+)</p>$"). The fix might be to join each p block in its own line, but I don't know if that could break other stuff.

Using --wrap none here actually solves the issue, but it might create others.

https://github.com/rstudio/bookdown/blob/52c31aa2fa44111b9ea67fdc4004f0ecd036c20f/R/html.R#L80-L82

[eliocamp]

Ok. It seems that --warp=preserve was introduced to fix #504. But that's only related to LaTeX, which doesn't have this problem. Removing this option only for HTML documents seems to solve the issue in HTML and all tests pass (at least locally on my machine).

That would just pass pandoc_args directly in all HTML functions instead of passing it through pandoc_args2(). For instance, in this line:

https://github.com/rstudio/bookdown/blob/52c31aa2fa44111b9ea67fdc4004f0ecd036c20f/R/html.R#L59-L62

As a workaround, one can set

  pandoc_args:
    - --wrap=none

on the output format options in the YAML.

Don't know how you feel about this. If you agree with the fix, I can sent a PR.

[cderv]

Thanks for the investigation. I think we should have used --wrap=none for HTML output instead of --preserve.

This is part of change in HTML output with pandoc 2.17 where wrap has now effect. I wanted to do that in https://github.com/rstudio/bookdown/issues/1304 but preserve was already set. You reminded us why (https://github.com/rstudio/bookdown/issues/504)

[king-of-poppk]

I've got a similar issue when embedding \n's in fig.cap: the Figure x.y caption prefix is not resolved. Is this related or is it a separate issue?

[cderv]

@king-of-poppk please open a new issue with a reproducible example and we can have a look