find a really nice table generator

[yihui]

discussion here: https://r.789695.n4.nabble.com/nice-report-generator-td4169939.html

[ramnathv]

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]

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.

[ramnathv]

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]

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 (https://github.com/SachaEpskamp/swst).

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 https://gist.github.com/1535472

[hadley]

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]

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

[halpo]

I think it would be a great idea, do you have anything to illustrate
what you mean?
-Andrew

On Thu, Apr 19, 2012 at 10:39 AM, Yihui Xie
[email protected]
wrote:

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

---

Reply to this email directly or view it on GitHub:
#53 (comment)

[baptiste]

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]

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

• Output to latex, grid, tt and html
• Incorporate ODS ideas to make it easy to extract components (separate source and appearance)
• Use "Manual of tabular presentation" from the census for basic structure and common layouts.
• Review infovis literature for other ideas
• Connection to reshape?
• In cell graphics where possible?
• https://www.iq.harvard.edu/blog/sss/archives/2009/03/writing_excel_o.shtml
• "A grammar of tables"
• Ties to algebra of data manipulation?
• https://www.nettakeaway.com/tp/article/446/tabled
• https://stats.stackexchange.com/questions/3542/what-is-a-good-resource-on-table-design
• Look at Duncan Murdoch's tabular package

[baptiste]

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.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.