Avoiding (and correcting?) table column widths

[John Muccigrosso]

Just saw that the latest version adds in column widths for pipe tables. Any
way to turn these off? They're killing my css formatting.

I assume I'm getting bitten by this: Pipe tables with long lines now get
relative cell widths
<https://github.com/jgm/pandoc/commit/eb8aee477db045a7449bc752975528263964b8ce>,
but if so, that seems odd to me because some of the tables being affected
have short outputted lines, even though there are links in them which make
the markdown lines long.

For example, from my CV, this table gets the widths inserted:

|aa|bb|
|:--|--:|
Professor of Classics|[Drew University](http://www.drew.edu/)|
|<***@drew.edu>|[214a Brothers College](http:
//www.drew.edu/map/?building=brothers&Perspective=Y#building=brothers)|
|<http://www.users.drew.edu/jmuccigr/>| Madison, NJ 07940 |
|[VIAF](http://viaf.org/viaf/309849093/),
[ORCID](http://orcid.org/0000-0002-9877-1043),
[Academia.edu](http://drew.academia.edu/JohnMuccigrosso)|+1.973.408.3029|

so the html is this:

<table style="width:11%;">
<colgroup>
<col width="5%"></col>
<col width="5%"></col>
</colgroup>
<thead>
<tr class="header">
<th align="left">aa</th>
<th align="right">bb</th>
</tr>
</thead>
<tbody>

Note how narrow the cells are, too. They're so narrow that the text in the
second cell on each line wraps.

In contrast, the columns in this table are left alone, even though they
have more text than the other one:

|date|item|
|:--|:--|
2006–2008 | Chair, Committee on Academic Policy and Curriculum
2004–2005 | Mellon Foreign-Language Grant steering committee
2000–2006 | College Space Committee (chair from 2004)
2002–2006 | University Space Committee
2004–2005 | Co-Chair, Foreign-Language Council
2002 | Student Life Advisory Board
2000–2001 | University Technology Committee

I can in fact force the wrapping by adding more text to one of the cells,
presumably so that it meets the minimum width to get the column width set.

On the other hand, if I remove the links from the first table above, the
column-width formatting doesn't get applied, which suggests to me that
pandoc is (mistakenly) taking non-printing text into account when deciding
whether to add column widths. So that would be a bug, I think.

However, I really don't want any widths applied at all, if possible.

[John MACFARLANE]

Post by John Muccigrosso
Just saw that the latest version adds in column widths for pipe tables.
Any way to turn these off? They're killing my css formatting.
I assume I'm getting bitten by this: [1]Pipe tables with long lines now
get relative cell widths, but if so, that seems odd to me because some
of the tables being affected have short outputted lines, even though
there are links in them which make the markdown lines long.
|aa|bb|
|:--|--:|
Professor of Classics|[Drew University](http://www.drew.edu/)|
College](http://www.drew.edu/map/?building=brothers&Perspective=Y#build
ing=brothers)|
|<http://www.users.drew.edu/jmuccigr/>| Madison, NJ 07940 |
|[VIAF](http://viaf.org/viaf/309849093/),
[ORCID](http://orcid.org/0000-0002-9877-1043),
[Academia.edu](http://drew.academia.edu/JohnMuccigrosso)|+1.973.408.302
9|
<table style="width:11%;">
<colgroup>
<col width="5%"></col>
<col width="5%"></col>
</colgroup>
<thead>
<tr class="header">
<th align="left">aa</th>
<th align="right">bb</th>
</tr>
</thead>
<tbody>
Note how narrow the cells are, too. They're so narrow that the text in
the second cell on each line wraps.
In contrast, the columns in this table are left alone, even though they
|date|item|
|:--|:--|
2006–2008 | Chair, Committee on Academic Policy and Curriculum
2004–2005 | Mellon Foreign-Language Grant steering committee
2000–2006 | College Space Committee (chair from 2004)
2002–2006 | University Space Committee
2004–2005 | Co-Chair, Foreign-Language Council
2002 | Student Life Advisory Board
2000–2001 | University Technology Committee
I can in fact force the wrapping by adding more text to one of the
cells, presumably so that it meets the minimum width to get the column
width set.
On the other hand, if I remove the links from the first table above,
the column-width formatting doesn't get applied, which suggests to me
that pandoc is (mistakenly) taking non-printing text into account when
deciding whether to add column widths. So that would be a bug, I think.
However, I really don't want any widths applied at all, if possible.

An easy workaround for this sort of problem is to use
reference links.

You're right, it would be good for pandoc to be smarter
about this, perhaps comparing the result of applying
'stringify' to parsed inlines, rather than raw text.
Of course, this makes it harder to explain to users
when, exactly, the column-width behavior gets triggered.

[John Muccigrosso]

Post by John MACFARLANE
An easy workaround for this sort of problem is to use
reference links.

In this document using reference links is not going to work for me, because
I've got tables with no links that are being affected. (See the attached
screenshot.)

Post by John MACFARLANE
You're right, it would be good for pandoc to be smarter
about this, perhaps comparing the result of applying
'stringify' to parsed inlines, rather than raw text.
Of course, this makes it harder to explain to users
when, exactly, the column-width behavior gets triggered.

For my money, that it gets triggered on content that isn't visible is
already unexpected, to say the least. I'd expect that users would assume
that only the parsed lines would count towards triggering the column
widths, so that the current behavior is what's hard to explain.

So a couple of bugs that I think I see here:

1. All raw text is counted, as just discussed.
2. The calculated widths are too narrow. That is, it does a bad job (at
least in this one document of mine) of supplying appropriate widths.

For a feature request, if this is going to stick around, I'd still like a
way to turn it off. It really defeats the use of css and its output isn't
very good anyway (see #2 just above). Frankly I'd rather the default be
OFF, rather than ON.

Maybe I'm in a minority here, but this change turns out to make a pretty
big difference in html output. If I'm going to keep using pandoc, I'm going
to have to work around it.

[John Muccigrosso]

Oops, here's that screen shot showing the very narrow widths in a table
without links. The table width is 11% and the columns are 5%. In my css,
the table is 100% width and the columns have a fixed pt width.

[John MacFarlane]

A couple things to note. First, this change was motivated
by persistent complaints that pipe tables gave bad results
in PDF output, so I don't want to just go back on it.

Second, if you read the manual carefully, you'll see that,
when the widths feature is triggered by over-long content
lines, the relative widths are determined by the relative
widths of the separator bars (relative to the text width,
which by default is 80 but can be set differently using
--columns).

So, an easy fix for you would be to adjust the widths of
your separator bars until you get the proportions you want.

Instead of

|aa|bb|
|:--|--:|

try

|aa|bb|
|:----------------------------|------------------------------:|

This will get rid of the overly narrow columns.

The mechanism is extremely flexible, once you see how to use
it, so I don't think it will get in your way.

[John Muccigrosso]

Thanks, John.

Yes, I did see the method of using more bars, but that seems...inelegant,
so I was hoping just to turn off the feature. Is there a rule relating the
number of bars to column width, or to the minimum text length that turns on
the formatting?

I think I might be better off with the --columns option set really really
big, even though that seems very kludgy to me. It'll keep the tables
looking more normal in markdown and I think it should work.


Two things present themselves to me:

1. If the problem is with PDF generation, then why not limit it to PDFs.
2. It still seems that the things I mentioned above are bugs (i.e.,
too-narrow widths and calculating based on raw text)

[John MACFARLANE]

Post by John Muccigrosso
Thanks, John.
Yes, I did see the method of using more bars, but that
seems...inelegant, so I was hoping just to turn off the feature. Is
there a rule relating the number of bars to column width, or to the
minimum text length that turns on the formatting?

Yes, the proportional width of a column is determined by the
width of the delimiter bar divided by the column width
(default 80).

Post by John Muccigrosso
I think I might be better off with the --columns option set really
really big, even though that seems very kludgy to me. It'll keep the
tables looking more normal in markdown and I think it should work.
1. If the problem is with PDF generation, then why not limit it to PDFs.

Because this concerns parsing, and parsing and writing are
always separated in pandoc. The parser doesn't even know
which format you'll be producing.

Post by John Muccigrosso
2. It still seems that the things I mentioned above are bugs (i.e.,
too-narrow widths and calculating based on raw text)

The first is a feature. Sometimes an author wants narrow
columns. This lets the author decide.

The second is debatable. I will probably change it; it just
makes it more complex to predict when this behavior will
kick in.

[John Muccigrosso]

Thanks for all the replies. I understand this a bit better now.

Post by John MACFARLANE

Post by John Muccigrosso
2. It still seems that the things I mentioned above are bugs (i.e.,
too-narrow widths and calculating based on raw text)

The second is debatable. I will probably change it; it just
makes it more complex to predict when this behavior will
kick in.

It was natural to me to think that activation of the behavior depended on
the text that's going to be visible and not the other stuff, like links.

FWIW, I've added "--columns 800" to my command and it solves the problem
for the one document I've worked on that has tables. (To beat a dead horse,
I'd rather just be able to turn it off.)

[John MACFARLANE]

I've made the change in
dd8df6cfbc07271f10f380620ecf8867bf3da8c3.

Now pandoc only looks at width of printable characters in
deciding whether to use relative widths.

Post by John Muccigrosso
Thanks for all the replies. I understand this a bit better now.

Post by John Muccigrosso
2. It still seems that the things I mentioned above are bugs

(i.e.,

Post by John Muccigrosso
too-narrow widths and calculating based on raw text)

The second is debatable. I will probably change it; it just
makes it more complex to predict when this behavior will
kick in.
It was natural to me to think that activation of the behavior depended
on the text that's going to be visible and not the other stuff, like
links.
FWIW, I've added "--columns 800" to my command and it solves the
problem for the one document I've worked on that has tables. (To beat a
dead horse, I'd rather just be able to turn it off.)
--
You received this message because you are subscribed to the Google
Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send
To post to this group, send email to
To view this discussion on the web visit
[3]https://groups.google.com/d/msgid/pandoc-discuss/f9a33f04-d168-416a-
9bc8-dd4ff9531ade%40googlegroups.com.
For more options, visit [4]https://groups.google.com/d/optout.
References
4. https://groups.google.com/d/optout