Skip to content

find a really nice table generator #53

yihui opened this Issue Dec 13, 2011 · 10 comments

5 participants


I have done some work on this, mainly with Latex. I looked at the above link, and interestingly enough it is actually easy to implement a function that would accept a color theme as an argument and format the table accordingly. I used the same idea used in themes for knitr. I wrote a function that would (a) grab the color palette from .thmx files for Office, (b) dump them into a css file, and (c) use the css styling to format the latex table. I found that it works quite well. I will share my code in a repository when I find time.

Is this a feature you are planning to roll into knitr ?

yihui commented Dec 20, 2011

Yes, I'm pretty much satisfied with the graphics in knitr now, and the next step is to make tables look nice as well.

I'll be leaving soon, and I'll be happy to see what you have done for tables when I'm back.


I have an idea, which might be more general. It is inspired by the ascii package, which defines functions to pretty print most classes of R output by wrapping them in an ascii() call. It allows you to define the markup language as well, so that the output is consistent with its syntax.

My idea is to take this a step forward and say, why not let knitr automatically wrap the output in a markup() call based on the document type. For example, you would wrap latex output in a latex() call (not referring to the latex function in Hmisc) so that you could pretty print a table in latex, without having to call the function explicitly.

Now, if you have a latex function defined for most classes (which btw is already true if you look at xtable, memisc and latex), then the results would automatically be typeset. As for themes for tables, my idea would be to use a configuration file like css or yaml, and use it to style, so that there is consistent format. Of course, you would have to leave an option for the user to directly call the decorating function, if he wishes to avail of more complex functionality.

I have a nice feeling that the thoughtful design of knitr would actually make this quite easy to implement.

halpo commented Dec 29, 2011

This may or may not be related but I had a thought about automatic printing of tables. I prefer xtable for tables, but thought that there might be ground for having output automatically converted to latex, html, etc. This could build off Sacha's swst package (

The idea for the hook could be that code is evaluated in an environment that overrides base print functions. automatically converting output to latex tables and formatted output. swst provides some of the functions already. I created a working proof of concept at

hadley commented Apr 19, 2012

I think it would be really nice to have a "grammar of tables", where you could easily define the structure of a table (e.g. row/col headers, spanning rows/cols, caption, ...) and then combine it with a theme to produce output for the console, html, latex etc.

yihui commented Apr 19, 2012

sounds like an insightful idea! I'll think about it.

halpo commented Apr 19, 2012

having played recently with the tables and gtable packages, I came to the conclusion that using a layout data.frame like gtable is a sensible and convenient syntax. Each row consists of t r b l z clip name to indicate the extent of the cells. The syntax of tabular() I found much more awkward, where NA values specify spanning multiple cells in a matrix.

hadley commented Apr 27, 2012

Just in case anyone is thinking about this more seriously, I've included my very vague list of ideas on this topic below


I can think of some useful additions to the gtable package to define a general table specification:

## grob: graphical object (text label, plot, sparkline, etc.)
## l, r, t, b : left, right, top, bottom indices for the grob position
## z: layer stack position
## just: justification in the cell
## orientation: orientation in the cell (horizontal/vertical)
## clip: clipping in the cell
## width: width of the grob
## height: height of the grob
## border: type of cell border (as in gridExtra::borderGrob)
## bg: background graphical parameters (fill colour, maybe alpha)
## fg: foreground graphical parameters (separator line colour, linetype)
## name (id): name of the grob
## cell (id): union of all grobs with common l, r, t, b
## row (id): union of all cells with common t, b
## col (id): union of all cells with common l, r
table <- data.frame(grob, l, r, t, b, z, just, orientation, clip, width, height, border, bg, fg, name, cell, row, col)

## table checks
## sanitize_cell: resolve conflicts for e.g multiple border specifications
## set_widths: adjusts widths to respect each cell and optional user-defined widths
## set_heights: adjusts heights to respect each cell and optional user-defined heights

## utilities
## locate_cell: find a cell given a grob name (regexp)
## locate_row
## locate_col
## cell_index: return the matrix layout indices for a given cell
## index_cell: return the cell(s) overlapping with a given region of the matrix layout

## formatting functions
## format_header: sets the borders and other formatting options
## format_core

## spacing
## set_padding: set padding around cells
## add_spacer: adds an empty row / col

Once this table description and helping functions are defined, it is only a matter of providing specific rendering backends (one based on grid should probably be included in gtable as well).

A GUI could be written to provide a visual interface with the data.frame description, and at a higher level themes could be defined to provide default formatting for rows, cols, headers that can later be overwritten at the individual cell level.

@yihui yihui closed this in 057f41d Jun 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.