Is anyone sitting on or thinking of building an implementation to parse arrays (e.g. Matrix, DataFrame, AbstractArray, etc.) into markdown tables (specifically one of the four table formats described in pandoc’s documentation: simple_tables, multiline_tables, grid_tables, and pipe_tables)?
I agree with everything you said. IMHO, It’s one of those things that are mildly needed in many different cases and would benefit from a centralized single solution.
Right, so I added grid_tables as well, and I wanted to be able to have multi-line cells, but I see now that this isn’t utterly trivial (for me). Will keep hacking at it at some point, but if anyone wants to pick up the ball, be my guest!
I’m working it now. I agree, there’s hardly anything there now…
My ultimate use-case is:
Produce some numbers, url links, and strings from some input.
Populate a String array with those.
Some of these strings in that table will have '\n' newlines in them (to make the final cells a little less wide).
Convert this array to a markdown table.
Insert it to a larger markdown template document (using Mustache.jl).
Use pandoc to convert it all to: html (webpage), html (email), and pdf.
So I don’t care what the markdown code ends up looking like. For instance I actually don’t care about the distinction of how simple_tables, multiline_tables, grid_tables, and pipe_tables all look differently in markdown. That’s because the end pandoced result looks the same no matter what. I do care about the distinction that grid_tables for instance can take multiline cells.
My implementation looks very different than what’s online right now…
I am crappy in that domain (HTML, CSS). But what do you mean, pandoc the html to pdf? In any case, I feel I’m doing good by finally building a markdown printer for arrays…
I don’t know if this is a valid option for you, but my advice based on experience is stay away from anything but very simple tables in markdown. They are easily broken, and sometimes don’t display the same way everywhere when they should. My advice would be to stick to LaTeX if possible which pandoc will convert much more reliably.
Thanks for the links. The use-case is: I have clients that I want send an invoice, quote, or receipt to. I need to populate those with data I save in simple txt files. The whole pipe-line from a test file with their name, the expenses, etc to an automated email+pdf attachment+stripe website (for them to pay with a credit card) requires me to build about 3-4 tables.
My “bottleneck” format where everything needed to go through is/was markdown. I guess I should switch that up to LaTeX… Feel free to PM me if you want to know more.
Yes, I think that would be much safer than having markdown as the “primary” source. Relying on markdown would just be asking for trouble if there are tables.
When I read the name “Markdown tables”, my brain short-circuited and I assumed you were aiming at solving the following problem:
Pretty-printing simple 2D data with row and column headers to the REPL or a text file (i.e. assuming a monospaced typeface), with a few simple customization options concerning lines (where to put lines & which Unicode characters to use for them) and cell alignment (e.g. left, right, center, decimal point).
But now I get the impression that your package is for outputing nice-looking tables in proportional typefaces, using smart layout engines like LaTeX or HTML/CSS to “just do the right thing” for whatever output format or size you need. Is this roughly correct?
Now that I am no longer confusing Markdown text input with its output rendering, can someone point me to some packages that address the “simple monospaced table” use case? (And sorry for hijacking the thread to ask this!)
I like the markdown idea better than html/latex… using markdown means you can print it in the REPL and convert it to anything else as well as well. It will be useful everywhere, packages that extend arrays and dataframes can use it in show().
)