A lua filter enabling multiple columns in Latex, PDF, and HTML documents

[chrisaga]

It's based on the use of simple Pandoc fenced divs, their class names and some arguments. This filter extends what is already available for HTML output, gives the same features to Latex (and PDF via Latex) documents.
Multiple columns are very useful to format fancy documents with text, pictograms etc. I have been missing this feature for a long time. I finally made my first Pandoc lua filter and share it hoping it will be useful to others.

[chrisaga]

I think I corrected what failed in the test workflow in my two last commits (5296ecd & 9d650d4). Sorry for the inconvenience.

[jdutant]

NB, there's already a filter for that: https://github.com/jdutant/columns . The syntax is the same, and it provides the header-includes if needed. It handles column spacing, rules etc. as well. I didn't submit it here because @tarleb wants to keep this repo for smaller, easily maintainable filters, but I included it in the filters wiki. The main thing I'd like to add to my columns filter is handling tables within multiple columns in LaTeX (this requires converting longtables to xtabs, I've worked on that a bit: https://github.com/jdutant/dialectica-filters/tree/main/longtable-to-xtab).

BTW few people seem to find the filters mentioned in the Pandoc filters wiki. This repo is good because we know we can trust the filters on it; but on the other hand, it can't accept largish filters. I hope at some point we get something more like CTAN...

[chrisaga]

@jdutant Thanks for the clarification.
I eventually found your column.lua when I was trying to figure out a solution.
Am I wrong or It processes even column (multicols style) but not uneven, width fixed, columns ? The later are OK in plain Pandoc for HTML output but not for Latex/PDF output.
I wanted a small easilly maintenable solution to do some document formating which would render the same in HTML and PDF.
This column thing (both types) have been an issue for quite some time (see questions in multiple StackExchange lists). It's the reason why I thought this filter could interest somebody. If this is not the right place. No problem for me.

[jdutant]

@chrisaga ah, good point! Indeed columns.lua only reproduces the functionality of the LaTeX package multicol, which doesn't handle variable width. I see different widths are a challenge; they can't be fluid in LaTeX as paragraphs can't change their width midway, so you need to explicit column breaks, and they can't break across pages if they're created by minipage, as in your filter. I wonder if it's worth implementing that in columns.lua filter, or just make sure that the two syntaxes don't overlap so people can use both.

[chrisaga]

@jdutant I don't know. It's up to you.
minipages is the way I found to implement this :

:::::::: {.columns }
:::: {.column width="20%"}
content ...
::::
:::: {.column width="80%"}
content ...
::::
::::::::

Which is what you find on the net when you google something like "pandoc markdown columns".
It's consistent with what plain Pandoc makes with divs for HTML output. Obviously no page break problem here.
I just say that using both column types makes it super easy to get some pretty fancy page formatting with text and symbols (see attached image below). The rendering is very consistent between HTML and PDF. I am very happy with that. I may just need to add the bells and whistles of multicols (already checked that almost everything can be done both with HTML and LATEX).

F.

[alerque]

Thanks for working on this, dropping the requirement on specific class order, and especially for adding tests!

[alerque]

I am uncomfortable with this. Do we have other instances in Pandoc templates where the default output includes loading 3rd party external resources?

[chrisaga]

Well … I didn't do this. pandoc --standalone did. I can remove the --standalone option on the html test file.
I already did for the latex test file.
Would it be better like this ?

[alerque]

I realize I'm reviewing this still in Draft mode so it might be too early, but just as a note for when this is ready for review lets cleanup the code so there are not instances of commented out bits without explanation for why the logic is not transparent.

[chrisaga]

Of course !

[alerque]

c.f. Comment on L151.