Syntax for columns in presentations.

[AvverbioPronome]

I believe it is necessary, even the beamer manual tells users to use columns in frames (§5.1.3).

Alternatives I have in mind are:

• syntax for divs in #168, with {.column width=xx%};
• using the three-dotted syntax used in stmd for side by side examples.

[jgm]

Pandoc is multiformat. I don't want to add syntax that is special to beamer.

If you want columns in your frames, you can:

• Use raw latex (will only work in beamer)
• Use divs as you suggest, and write a pandoc filter to convert to the needed column environments in beamer output (not too hard)
• Use a table

+++ Giuseppe C [Oct 22 14 05:41 ]:

I believe it is necessary, even the beamer manual tells users to use columns in frames (§5.1.3).

Alternatives I have in mind are:

• syntax for divs in #168, with {.column width=xx%};
• using the three-dotted syntax used in stmd for side by side examples.

---

Reply to this email directly or view it on GitHub: https://github.com/jgm/pandoc/issues/1710

[AvverbioPronome]

It shouldn't be beamer-specific, but I guess presentation-specific is just as bad. (on the other hand, a presentation is very different from a document)

I thought columns could become subfloats in documents, and I wasn't very convinced.

[jgm]

Well, I suppose we could hard-code a certain behavior for <div class="column">, and add custom CSS to handle this in HTML slide formats. This might be worth looking into.

[N4M3Z]

What is the progress on this? Something along the lines of {.column width=xx%} seems like the way to go. Can we help with implementing it?

[jgm]

I like the div solution on the input side. What I'd need to know is what the output should look like in all of the slide show formats we support, or as many of them as support it -- but, at least, beamer and revealjs.

[jgm]

I assume that in revealjs and other HTML formats we can use CSS to position things --- either floats or, probably more reliably,

<div style="display: inline-block; width: 50%; vertical-align: top;">
</div>

but I haven't actually tested this. In fact, it might be sensible to support this in all HTML output (whether slide or not).

[N4M3Z]

For Beamer, two column output should look like this:

\begin{columns}
  \begin{column}{0.48\textwidth}
    Left column
  \end{column}
  \begin{column}{0.48\textwidth}
   Right column
  \end{column}
\end{columns}

Which can be easily extended to multiple columns. I have been adding this to my markdown and it works fine.

There is a very nice summary of various options implemented by others: http://stackoverflow.com/questions/20847371/two-column-layouts-in-rstudio-presentations-slidify-pandoc

I like the R studio solution using the *** separator. But {.column width} is also nice.

[jgm]

So, for beamer, if we have <div class="column" width="N%">, do we always want (N-1)\textwidth in beamer?

[N4M3Z]

Hmm, I think not. If I am not mistaken, the width percentages need not add to 1, LaTeX will simply not use the remaining space. Hence, we should be fine with specifying <div class="column" width="N%"> as N\textwidth. Let me know if you want me to do some testing.

[jgm]

Another syntax possibility. Currently, if you use a header with level (slidelevel + 1), you'll get a block environment.

\begin{block}{Header}

contents

\end{block}

We could set things up so that, if the main header for a slide has the class "columns", then subsidiary headers create columns instead of blocks:

# My slide {.columns}

## First column

contents

## Second column

contents

Widths could be computed automatically (unless there is a really compelling reason for being able to specify them manually.) An empty header could be used if you don't want a subhead at the top of the column. This approach would be more naturally syntax-wise, but a bit less flexible.

[N4M3Z]

I consider the ability to specify width essential. This is particularly useful for side-by-side figures of different proportions.

Concerning the syntax, personally I am not sure I like it since I might want to use both blocks and columns. I still have a problem once I start using blocks, there is no way to tell pandoc to end the block and continue writing text outside the block and I am afraid the same thing would happen here.

However, I agree that it feels more natural w.r.t. markdown.

[jgm]

Looks like currently the "block syntax" breaks entirely if you put it inside a div. So we may need more serious changes to the LaTeX writer to make this all work smoothly.

[N4M3Z]

I suggest to take the simplest approach to bring the column functionality at least partially to pandoc and taking care of blocks inside columns later. It is a very unlikely use-case I would say.

[barronh]

I can get basic usage with the standard beamer columns. I get a reasonable output with very little effort and only a minor modification of the default template.

I added one use statement and two new commands to my beamer template.

\newcommand{\begincols}[1]{\begin{columns}{#1}} 
\newcommand{\stopcols}{\end{columns}}

And tested with the habits.txt modification below

% Habits - Testing Multicol
% Barron
% 2016-05-05

# In the morning

## Getting up

\begincols{t}

\column{0.5\textwidth}

- Snooze alarm
- Roll over
- Snooze alarm
- Roll over
- Snooze alarm
- Roll over
- Snooze alarm
- Roll over

\column{0.5\textwidth}

- Turn off alarm
- Get out of bed

\stopcols

## Breakfast

- Eat ~~eggs~~ cereal
- Drink **coffee**

[kaspersoerensen]

That works well @barronh - but when using images in the columns it seems that the figure captions are removed. At least in the theme I am currently using. Might not apply to all themes/templates.

[trou]

I think this functionnality would be awesome. I've been using a python filter, but the problem lies in practice in block:

## Slide

[columns]

[column=0.5]

### block1

text

[column=0.5]

### block2

text2

[columns]

will generate the following latex code:

\begin{columns}
\column{0.5\textwidth}
\begin{block}{Block 1}
text
\column{0.5\textwidth}
\end{block}
\begin{block}{Block 2}
text2
\end{columns}
\end{block}

As you can see, pandoc doesn't close the first block before adding the column (of course). Two ways this could be solved:

• add a way for the python filter to close the current block (including updating the current pandoc state)
• add column support in haskell

[jgm]

I think you just need to take a different approach in your filter. One more straightforward approach would be to match on header attributes.

## Slide {.columns}

### block1 {column=0.5}

### block2 {column=0.5}

[trou]

That's an interesting workraround but it wouldn't allow for 2 different blocks in a columns

[jgm]

I think the div option is good, but this should be implemented for HTML formats too.

[mb21]

I agree that the div with a class seems to be the right vehicle for inputting this (both in markdown input and AST).

For HTML output, there is also the option for auto-flowing the content of the div into columns, the necessary CSS (browser support includes IE>=11) would be either:

.column {
  column-count: 2;
}

or:

.column {
  column-width: 100px;
}

[barronh]

The auto-flowing approach would need to be easily separated from the intentional flow. It is frequently the case that the left and right have intentional comparisons: pros vs cons; old results vs new results; etc.

The column-width approach does not work because the number of columns is not knowable and neither is the content. The column-count approach is better, but still the content of the columns cannot be specified.

[mb21]

It is frequently the case that the left and right have intentional comparisons: pros vs cons; old results vs new results; etc.

Right. Then we'd need something like:

<div class="columns">
  <div class="column">
    - my
    - pros
  </div>
  <div class="column">
    - my
    - cons
  </div>
</div>

[HaoZeke]

Surely with CSS Grid columns are a cinch in HTML as well... SO maybe this should be looked at again?

[mb21]

@Haozeke, this was implemented, see the commit referenced above

[henryiii]

@mb21 , I think @HaoZeke was looking at that comment, which shows it was added for LaTeX, and no other backends, like HTML. However, upon testing, the syntax in the release notes (almost) works.

Edit: The "closed in" commit is correct. It is just not as prominent as the other one.

There are two problems. The first is that the release note syntax has a 4 space indent, visually looks nice in the markdown but causes unformatted monospaced text.

The other problem is that blocks are not supported! So this fails to compile for beamer (failing hard, since the block is not closed):

<div class="columns">
<div class="column" width="40%">
## Block one
- Item
</div>
<div class="column" width="60%">
## Block two
- Item
</div>
</div>

[mb21]

@henryiii Have you looked at the discussion in https://github.com/jgm/pandoc/issues/816 ? I think this is currently expected behaviour...

[henryiii]

@mb21 , I believe this is a different issue - the section level is something that's a bit odd, but I'm used to it. Pandoc produces non-valid LaTeX if you put a heading of any sort in a div, and I believe it doesn't ever produce blocks. I'll open dedicated issues.

[zedsmith52]

I have been trying to attempt something similar - the html file I have is test.html containing:

column1

column2

Whatever I do, I cannot get pandoc to output two columns in docx or pdf. I've tried tables, various css and although it works in html through a browser, pandoc just does not seem to be able to convert it.

On a side note, I also lose background images when I convert from html too.

Is this the same problem or something anyone has run into?

[henryiii]

Have you tried the pandoc 2 syntax? I use it heavily, but only tried it through the pdf output. (Use triple back ticks around what you are trying to keep github markdown from swallowing it up)