Width of table containing math is based on width of LaTeX commands

[Dr-Irv]

When creating a table in markdown and the table has math in the cells, and then converting to PDF, the width of the table is influenced by the length of the LaTeX commands that create the math.

Here's markdown text for 2 tables. The first one is using \mathcal around some of the letters, while the second one doesn't. When rendered, the tables should be of the same width.

# Test

This is test of math in a table.

| a | b | c |
|---|---|---|
| $n_b$ | $\tau^u$ | $\vert\bar{\mathcal B}\vert$ |
| $q_{pb}$ | $\vert\mathcal P\vert\times\vert\mathcal B\vert$ | $\sum_{b\in\bar{\mathcal B}}\vert\bar{\mathcal P}_b\vert$ |

End of table.

| a | b | c |
|---|---|---|
| $n_b$ | $\tau^u$ | $\vert\bar B\vert$ |
| $q_{pb}$ | $\vert P\vert\times\vert B\vert$ | $\sum_{b\in\bar B}\vert\bar P_b\vert$ |

End of second table.

Here is a pic of the output:

Version Info:

pandoc 2.2.3.2                                                              
Compiled with pandoc-types 1.17.5.1, texmath 0.11.0.1, skylighting 0.7.2    

[jgm]

Actually it depends on the separator lines, not the content. See the manual under pipe tables for how it works.

[Dr-Irv]

Look at the example. The separator lines are identical. The second table is correct, but the first table is rendered too wide.

In the docs, it is written:

If a pipe table contains a row whose printable content is wider than the column width (see --columns), then the table will take up the full text width and the cell contents will wrap, with the relative cell widths determined by the number of dashes in the line separating the table header from the table body.

In this case, the printable content of the two tables are identical except for the characters (\mathcal B versus B, for example). The widths are identical.

So I think the way that pandoc is computing the line length is based on the LaTeX length.

If I look at the resulting LaTeX source, the first table has each cell in a minipage, the second table does not.

[jgm]

Read the manual more carefully:

If a pipe table contains a row whose printable content is wider than the column width...

This is saying that the "relative widths based on the separator lines" feature only kicks in when you've got at least one content line that exceeds "columnwidth". That happens in your first table but not your second. If you want narrower columns in the first table, just use narrower separators (e.g. --).

[Dr-Irv]

But the content lines do not exceed the "columnwidth". Even with separators that are -, I get the same result.

Look at the picture and you'll see. The only difference between the math in each cell is that the first table uses \mathcal while the second column doesn't use \mathcal . I think that pandoc is computing the length of the content lines based on the number of characters used to express the math, as opposed to the length of the rendered math.

[jgm]

I think that pandoc is computing the length of the content lines based on the number of characters used to express the math, as opposed to the length of the rendered math.

Yes: what's meant by "column width" is column width in the markdown source. (There's no way for pandoc to compute the column width in the rendered version; it would have to do TeX typesetting to know that. I know that this leads to odd results occasionally.)

But I was wrong to suggest that changes the separators to - would make a difference. Looks like currently pandoc assumes that when relative widths are needed, the table should take up full space, and the separators only affect proportions of widths of the columns.

A workaround for you would be to define a tex macro for the math so you can make the source shorter.

[jgm]

Another workaround would be to specify a larger columnwidth on the command line.

[Dr-Irv]

I did try the macro thing, and that didn't help. If I use --columns=300, that seems to fix the problem.

I'd suggest writing something in the docs about how characters are counted (i.e., the characters in math mode count towards line width), or maybe when you count the width, you count each LaTeX token as a single character (but maybe that won't work since you don't parse the math)

[jgm]

The macro trick should work if you specify -f markdown-latex_macros. This will prevent pandoc from resolving the macros when generating LaTeX, instead passing the macros directly to LaTeX, which is generally what you want. As manual says:

When latex_macros is disabled, the raw LaTeX and math will
not have macros applied. This is usually a better approach when
you are targeting LaTeX or PDF.

[Dr-Irv]

The macro trick should work if you specify -f markdown-latex_macros. This will prevent pandoc from resolving the macros when generating LaTeX, instead passing the macros directly to LaTeX, which is generally what you want. As manual says:

I still had to get the line shorter than 72 chars for it to work right (or just use --columns).

One note that might help. In the docs about pipe_tables it says:

If a pipe table contains a row whose printable content is wider than the column width

What is confusing here is the phrase "printable content". Maybe it should say "number of characters" or something like that

[jgm]

I still had to get the line shorter than 72 chars for it to work right (or just use --columns).

Yes, that's what I meant: the idea was to use a macro to help do this.