fenced span/div for latex output

[brainchild0]

Most implementations of Markdown permit the inclusion of HTML fragments to achieve effects beyond those available in native Markdown structures. Such a solution has numerous deficits, leading to Pandoc’s introduction of fenced span and div regions. Fenced regions are permitted arbitrary class labels and attribute assignments, the former being particularly relevant in styling, as they are a basis of element selection in Cascading Style Sheets.

Fenced regions appear to be conceived specifically for HTML targets, the terms div and span following from names of HTML tags. Indeed, documentation on fenced regions does not explain any particular effect for non-HTML output formats. In LaTeX output, there is no useful effect from use of a fenced region. As such, authors targeting LaTeX are unable to benefit except through the use of ad-hoc filters maintained by themselves or shared by other users.

Practically, among the varied benefits of fenced regions over HTML fragments within Markdown is the former’s suitability to non-HTML targets, though this potential is not yet fully realized.

This problem is closely related to #5879, discussing the handling of Markdown buitlin constructs in LaTeX output.

Fenced regions, in principle, could be used in LaTeX output.

A span region with a myclass label enclosing text “Hello World” might be represented using a LaTeX command, as follows:

\myclass{Hello World}

Similarly for a div region, an environment might enclose the region of text, as follows:

\begin{myclass}
Hello World
\end{myclass}

A few complications make the benefits of these LaTeX constructs less certain than those of their HTML counterparts. Whereas the span and div elements, in HTML, can have arbitrary and multiple class labels, which have no effect unless specifically selected, use of a command or environment in LaTeX creates an error unless it has been previously defined. More, no representation is available for multiple labels except a cascade of nested enclosures.

One solution is to invoke the commands or environments only for labels preselected by the user.

Another solution is to create an empty definition in every case that none is given by the user.

A further issue is that the crowded, pre-populated namespace into which command and environment names enter opens the possibility of name collisions. A static prefix used to determine the LaTeX names from those in the Markdown might lower the chances of collisions. For example:

\pandocmyclass{Hello World}
\markdownmyclass{Hello World}

No compelling obstacle appears to prevent the possibility that LaTeX documents generated by Pandoc can include specialized formatting choices based on Markdown source featuring fenced regions, if the decision is made to add such support.

[jgm]

In general, I want to avoid producing LaTeX that requires special definitions to compile.
It's quite easy to use a lua filter to generate special LaTeX commands and environments for Divs and Spans meeting whatever condition you specify; that is currently the recommended approach. It requires a few lines of lua and it forces you to say how you want these constructs to be interpreted, but it's super-flexible.

[brainchild0]

I want to avoid producing LaTeX that requires special definitions to compile.

So would I, though I fail to see how this drawback is inevitable. In fact I addressed it directly.

[kysko]

As such, authors targeting LaTeX are unable to benefit.

Check Demko's python filter about this, which dates from april 2016.

And I regularly use DIvs with my filters to wrap in multicol, tcolorbox, etc.

But you're right about the user guide, it might not say enough about its possibilities through filters.

Altough your proposition wouldn't prevent any of the above, the latex template is already quite loaded as it is since the beamer template fusion (2017?).
What more would adding macros do, that can't already be done?

I think this is more a case of giving examples on what can be done with Div's outside HTML, with filters (and possibly custom template additions).

[brainchild0]

Thank you for the correction.

Given your comments it would be true that the quoted text is inaccurate as worded.

Even so, the essential idea, of adding functionality that is uniform and robust into the core application, remains a feature useful to discuss, and one I strongly push for inclusion.

However, this particularly line of discussion takes largely the same form as the one in #5879, so such conversation should probably be consolidated to that side until some resolution is achieved.

[tarleb]

IIUC, then a feature like this would cause great pains to other projects, see, e.g., the bookdown issue linked above. Filters are a good solution to get the desired features. Hence closing.

[brainchild0]

Yes, @tarleb, note the following, reproduced from above:

A few complications make the benefits of these LaTeX constructs less certain than those of their HTML counterparts. Whereas the span and div elements, in HTML, can have arbitrary and multiple class labels, which have no effect unless specifically selected, use of a command or environment in LaTeX creates an error unless it has been previously defined. More, no representation is available for multiple labels except a cascade of nested enclosures.

One solution is to invoke the commands or environments only for labels preselected by the user.

Another solution is to create an empty definition in every case that none is given by the user.

Reliance on filters would force everyone to construct a home-grown solution literally by writing their own code. It's cumbersome, obtuse, and inaccessible for most, even while perhaps enjoyable for a few. I wrote on this subject when the similar suggestion was given against logical mappings of builtin Pandoc types to LaTeX macros and environments.

The possibility exists to expand the Pandoc platform to one of very complete accessibility and flexibility, in turn to expand the user base to those who would receive the benefit of this feature, and many benefits of filters, without writing a single line of code, which most cannot do.

[bordaigorl]

My two cents on this: one could approach it by providing a new pandocdiv environment which takes the label and other options as parameters; then the default template can simply define it as an empty environment

\newenvironment{pandocdiv}[2][]{}{}

This would give us the standard behaviour running with the default settings, but by properly redefining the pandocdiv environment one can change the treatment of the fenced blocks depending on the labels.
For example one would have

::: WARNING :::
Text
:::::::::::::::

translated to

\begin{pandocdiv}{WARNING}
Text
\end{pandocdiv}

and then one can define in the template (or as an override in a header using \renewenvironment):

\usepackage{etoolbox}

\makeatletter
\newenvironment{pandocdiv}[2][]{%
  \ifcsdef{pandocdiv@#2}{%
    \def\pandocdiv@endenv{\csname endpandocdiv@#2\endcsname}
    \csname pandocdiv@#2\endcsname%
  }{%
    \def\pandocdiv@endenv{}%
  }%
}{%
  \pandocdiv@endenv
}
\makeatother

\usepackage{xcolor}
\newenvironment{pandocdiv@WARNING}{\bfseries\color{red}[\,!\,]\;\ignorespaces}{}

which would have the effect of applying special styling to the WARNING divs.
One can then add other special cases by adding new pandocdiv@NAME environments in header files.