Open jenitivecase opened 7 years ago
P.S. It is not specific to the number 7...
... but it does seem to be specific to single-digit numbers.
Thanks for the report, but I'm not sure if it's a pander
issue. I mean pander
does the R object to markdown transformation, but the rest (eg markdown -> PDF) is down via pandoc
. So we should figure out if it's a problem in the markdown (as per the markdown specs at http://pandoc.org/MANUAL.html) or it's an issue with converting the markdown to PDF.
The markdown looks right to me, but I'm open to other opinions -- can you do some research on this?
Additional things I have tried, with results:
removing parentheses from colnames = success
commenting parentheses in colnames with a single \
= failure
commenting parentheses in colnames with a double escape, \\
= failure, and the part of the colnames enclosed in parens became italicized (? this is a total mystery to me)
From the pandoc manual, I gather than parentheses may be used for section numbers and list markers. This is why I tried using character escapes. The only relevant bit of info I could find was:
The man page writer extracts a title, man page section number, and other header and footer information from the title line. The title is assumed to be the first word on the title line, which may optionally end with a (single-digit) section number in parentheses.
I didn't find anything in the section of the manual on tables. I'm starting to think you're correct that this is a pandoc
bug rather than a pander
issue. Maybe this issue could be addressed with a caveat in the pander
documentation, especially since the pandoc
documentation doesn't seem to be especially helpful here.
Could you try converting the markdown document into tex
instead of PDF first? Then checking the tex
file would show if it's a pandoc
, or maybe PDF rendering issue.
Meanwhile, I'm closing this ticket, as I suspect the issue to be outside of pander
-- but please report back with the above information and let's try to debug if you find something
Okay, I did some tests and figured out what is happening. The bits that are formatted incorrectly are all enclosed in {verbatim}
in the tex
code. For example, here's the line with the weird 7 from Table 1 of my test output:
\begin{minipage}[t]{0.42\columnwidth}\raggedright\strut
Red Light - Rec. Against\strut
\end{minipage} & \begin{minipage}[t]{0.12\columnwidth}\raggedright\strut
4.5\strut
\end{minipage} & \begin{minipage}[t]{0.15\columnwidth}\raggedright\strut
\begin{verbatim}
7
\end{verbatim}
\strut
\end{minipage} & \begin{minipage}[t]{0.15\columnwidth}\raggedright\strut
12.3\strut
\end{minipage}\tabularnewline
\begin{minipage}[t]{0.42\columnwidth}\raggedright\strut
I've attached the tex
and PDF outputs from this test run as well as the Rmd file used to create them.
Wow, good catch! Let me see if there's a fix for this in pandoc
or we might want to eg add an extra space in the column in such case to avoid triggering the verbatim env due to the four spaces.
BTW do you insist on using the grid
table format? As per the pandoc
docs:
The cells of grid tables may contain arbitrary block elements (multiple paragraphs, code blocks, lists, etc.).
So if you switch to eg the default multiline
, this problem should in theory go away.
I wouldn't say I insist on grid
, but it was a quick fix to other formatting issues.
To illustrate my point, I reran my test file after changing the type to multiline
for all examples. As you can see in the attached file, this output lacks the consistence in width and alignment across tables, even though the arguments in the pandoc.table()
function are the same in all cases. This is why I switched to grid
. Use of multiline
does, however, fix the main issue we've been discussing.
As per most recent pandoc
docs at http://pandoc.org/MANUAL.html#extension-grid_tables, alignment is now specified in grid
tables just like in the pipe
tables (since version pandoc 1.19
) -- so this is a bug in pander
.
Sorry it's a bug, but thanks for looking into it!
There is a 7 that is randomly getting formatted differently from all other values in my table output:
The table appears totally normal in R Studio and in the LaTeX code:
I've reproduced the issue with a toy dataset. In doing this, I determined the issue is connected to the presence of column names somehow.
Here's my code for the test case:
Here's some fun output:
And here's a bonus example of output from when I removed newline characters and parentheses from the column names in a troubleshooting attempt:
I no longer know what to trust. Any help is appreciated.