# jgm/pandoc

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

# using tables with vertical lines for generated latex #922

Open
opened this issue Jul 18, 2013 · 22 comments

### Sildra commented Jul 18, 2013

 Reader : Markdown Writer : LaTeX Current version : Pandoc 1.11.1 Pandoc lacks the possibility of inserting tables with vertical lines. I've been tweaking the generated tex from a markdown grid such as : +---------+-------------+---------+ | | c1 | c2 | +=========+=============+=========+ | e1 | e2 | 10 | +---------+-------------+---------+ | e4 | e5 | 15 | +---------+-------------+---------+  and it appears that the generated latex have a few issues : the numbers are enclosed with \begin{verbatim} and \end{verbatim} breaking the current font style (minor issue, not related to the issue) each line ends with \noalign{\medskip} which is breaking the vertical lines for the grid (major issue for the implementation of the issue) And it appears that the only element missing for the implementation of the grid is the pipe in \begin{longtable}[c]{@[]|l|l|l|@[]}
Owner

### jgm commented Jul 18, 2013

 I don't think the vertical lines should be included by default, and I won't change pandoc to do that. Maybe eventually some syntax should be added to indicate "vertical line here", but there's no representation of that in pandoc's current Table element. I don't see the verbatims in my output. What version of pandoc are you using? The \noalign{\medskip} is there to help prevent the table from looking too crammed together.
Author

### Sildra commented Jul 29, 2013

 There is 4 representations of tables in pandoc and the grid_tables representation is the one that fit best with the vertical lines in a table (for me I expected this representation to have vertical lines when first using it). For me the behavior of the generated LaTeX fit with the simple_tables representation but not with the grid_tables. For the verbatims, I create a cell with numbers only (version 1.11.1). You can use //[0.5em] instead of \noalign{\medskip}.
referenced this issue Oct 11, 2013

### jacobus commented Mar 25, 2014

 What is the correct way to add vertical lines when it is required?
Owner

### jgm commented Mar 25, 2014

 There is currently no way to add vertical lines, other than postprocessing pandoc's latex output. Use perl or a similar tool to change \begin{longtable}[c]{@{}lr@{}}  for example to \begin{longtable}[c]{@{}l|r@{}} 
Contributor

### timtylin commented Mar 25, 2014

 @jgm John, what are your thoughts on using custom LaTeX commands (or environments), defined in the template, that map semantically to structures in pandoc-types? That way a lot of the LaTeX formatting logic can be segregated to the template, instead of being locked away inside the binary. The tradeoff obviously would be giving up on "standard" LaTeX output, so it wouldn't be an easy decision. I'm just wondering if you've considered it at all.
Owner

### jgm commented Mar 25, 2014

 +++ Tim Lin [Mar 25 14 12:16 ]: [1]@jgm John, what are your thoughts on using custom LaTeX commands (or environments), defined in the template, that map semantically to structures in pandoc-types? That way a lot of the LaTeX formatting logic can be segregated to the template, instead of being locked away inside the binary. The tradeoff obviously would be giving up on "standard" LaTeX output, so it wouldn't be an easy decision. I'm just wondering if you've considered it at all. I have considered it (and it has been discussed on pandoc-discuss). My current view is still that there's value in having pandoc emit standard LaTeX, even though I can also see the advantages in the "custom" (and more customizable) approach. But it's an issue worth reconsidering from time to time.

### jakkubu commented Apr 22, 2016 • edited

 The time passed and issue is coming back. What are your thoughts about it now? @jgm You wrote: Maybe eventually some syntax should be added to indicate "vertical line here", but there's no representation of that in pandoc's current Table element. Does it change?
Owner

### jgm commented Apr 22, 2016

 No change.

### bluddy commented Jan 26, 2017

 This is a seriously strange perspective. I use pandoc to make my lecture notes. The times when you want a table without vertical lines are extremely rare. Given the fact that we have so many representations of tables, it's perfectly natural to expect some of them (at least) to be used to allow vertical separators. Instead, I'm going to have to make a custom command in the filter to specify table layout and hope it works.
Contributor

### svenevs commented Mar 25, 2017

 can't comment on whether it should be available or not, but here's a hack if you don't want to do it manually every time https://gist.github.com/svenevs/41a1a434a055adcee56bd1f0374fa254
Contributor

### ickc commented Mar 25, 2017 • edited

 @bluddy This is a seriously strange perspective. I use pandoc to make my lecture notes. The times when you want a table without vertical lines are extremely rare. Read the manual of the booktabs package in LaTeX first. The author argued why this is wrong, and why it is extremely rare to need vertical rules. If one is not using LaTeX, I have no problem to understand why people do not apply good typography. But as long as LaTeX is involved, I think it is very important to defend for good typography, which is what LaTeX is all about. On the other hand, from the perspective of writing lecture notes, I can understand it is a much more time-constrained task than publishing, and hence might not have a lot of time to design the tables to looks more professional (a table didn't designed to be publishable might not works well without vertical rules). So my point is not that vertical rules should never be applied, but we should understand that having vertical rules in LaTeX is actually a "serious strange perspective", not the other way around. (Albeit there's a need to do serious strange things because of other constraints like available time, source of the table, etc.) From my experience in pandoc's output, I agree that often the time it is the table output that one has to worry about. This is originated from the complexity of tons of different table designed with a different kind of info. There's a huge amount of packages that handle tables in LaTeX, exactly because no one package excels at every kinds of table. The complexity originates from the need of publishing quality and the constraint of a page, which are both not required in any other output formats (except for ConTeXt), especially those based on HTML. (HTML table are usually ugly. My personal CSS actually emulate the kind of tables from booktabs that's without vertical rules.) Lastly, just to point out a common phenomenon: tools like pandoc that emphasize on automatic conversion takes away the burden of the author to worry about the output but the content. While this is true, this might leads one to think they do not need to design the content with the output in mind. This is not true, and in practice can cause a lot of problems (especially for tables, other elements like images also have similar problem, but the complexity of "publishable" table make this a bigger problem for tables).

### hasufell commented Mar 26, 2017

 @ickc The author is using a pathological example to make his point. It doesn't represent most use cases.
Contributor

### ickc commented Mar 26, 2017

 Perhaps I wasn't clear, I edited and added that the previous message is to @bluddy. I was talking specially on his use case. And then I also think what I said is general enough for any use cases. If you read carefully you would see for example "if one is not using LaTeX...", and "my point is not that vertical rules should never be applied", etc. Lastly, my whole argument is based on the quote. I was saying the statement "This is a seriously strange perspective. I use pandoc to make my lecture notes. The times when you want a table without vertical lines are extremely rare." is wrong.
Contributor

### ickc commented Mar 26, 2017 • edited

 @hasufell, oh, do you mean the author of booktabs? Sorry I misunderstood your statement. Yes, that's why other packages exist. And while booktabs is not the definitive package for tables, it is the best one and many are following its recommendation. And I would say when people has use case for vertical rule, either they have no respect on typography, or they have no control over the complexity of the table (say, given by another colleagues, or required by the audiences). Edit: I have symphathy to the later group. And think they should be supported. But for the first group, I wish it doesn't exist. Technology should be used to augmented our capability (e.g. arts, design, etc.) but not to trash them. [Some people think that the convenience of technology outweights the ugliness of the design fom it. And by the way, that's why Apple has such a huge success (not to say it doesn't have it's own problem) because it is rare in the industry where "arts meets technology".] Edit2: The following would be useful on the topic of good table typography in LaTeX: http://tex.stackexchange.com/questions/40542/why-not-use-vertical-lines-in-a-tabular . In short, other kinds of good typography exists, but it seems given the limitation of LaTeX, booktabs is the "only" good solution (at least any that keep mixing vertical and horizontal rules is not).

### banderlog commented Jan 24, 2018

 Well, I think that vertical borders in table out-of-the-box would be very nice feature. Few flavors of Markdown, e.g. GitMarkdown, already implemented it, so it actually in-demand feature. Every time when I need to create nice table in PDF, I must plunge into LaTeX code. I have to literally paste a chunks of tables-latex-code, it decreases overall readability of raw markdown document.
Contributor

### ickc commented Jan 26, 2018

 Well, I think that vertical borders in table out-of-the-box would be very nice feature. It is nice to have the option but I would vote for it to be optional but not the default.

### link2xt added the format:LaTeX label Feb 3, 2018

referenced this issue Nov 3, 2018

### project-repo commented Jun 14, 2019

 Hi guys, I just stumbled across this and since I am having a similar problem, I just wanted to give my brief thoughts on this topic. Anyhow, the problem which is making this so hard to implement is the fact that there is practically no separation between style and content in latex tables. For this reason it would be practical if it were possible to define the style without changing the content. After some research i stumbled across the pgfplotstable package which allows exactly this. For example, the following code compiles to a table with grid lines around it: \pgfplotstabletypeset[ col sep=&, row sep=\\, every head row/.style={ before row={ \hline }, after row=\hline\hline, }, column type/.add={|}{}, every last column/.style={ column type/.add={}{|}}, every last row/.style={ after row=\hline}, string type ] { hello&world\\ This is&a test\\ } By removing the parts with \hline in them one can remove the horizontal lines and by removing the lines which style the columns one may remove the vertical lines. It is also possible to add support for longtables through: begin table=\begin{longtable}, end table=\end{longtable}, The largest downside I see to this approach is the fact that we would then depend on another package, however, I believe that this might be worth it. As I said, these are just some ideas that I had when looking into this briefly and they are still very rudimentary. What do you think? cheers, project-repo
Owner

### jgm commented Jun 14, 2019

 @project-repo we try not to depend on unusual packages, and to generate some fairly standard LaTeX, so that's a strike against this proposal.
Contributor

### ickc commented Jun 14, 2019

 According to https://ctan.org/pkg/pgfplotstable, pgfplotstable is included in pgfplots, which is a fairly standard packages. But I can't find an easy way to find a list of included packages in common LaTeX distributions. (e.g. what's included in TeXLive directly from TeXLive, and also the texlive and texlive-full from deb, etc.) Should we somehow compiled a list of packages that's common enough which can be used in pandoc for future reference? (Or is such a list already known?)

### project-repo commented Jun 15, 2019

 @ickc You seem to be right in that there seems to be no way to get the packages which are commonly installed by default. On Arch Linux the pgfplots package is bundled in texlive-pictures, whereas most of the packages required by pandoc are present in texlive-core. However, I noticed that there already exists the option for pandoc to use microtype and upquote if they are available. Maybe we could do something similar. I totally agree with you that we should be more specific on which packages we want to include so that we avoid becoming to dependeny heavy. However, I believe it will be difficult to come by a complete list (although texlive-core on Arch Linux is a good starting point)
Owner

### jgm commented Jun 15, 2019

 The manual has a list of the packages we currently depend on.
Contributor

### ickc commented Jun 15, 2019

 That's long been there but I mean is there a need to whitelist a core set of LaTeX packages that is common enough that can be considered to be used in pandoc for any future discussions if something can be used or not.
to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.