The subtitle is omitted when writing rST

[danse]

In the case of rST the subtitle is rendered within the $title variable rather than being handled as a separate template field. Besides this, the rendering of the subtitle is fragile due to a pattern match which causes subtitles to be discarded in the many cases when the structure of the metadata field does not match the pattern. For instance given the following template and native document, no subtitle is rendered:

 rotterdam (master)*$ cat templates/template.rst 
$if(title)$
$title$

$endif$
$if(subtitle)$
$subtitle$

$endif$
 rotterdam (master)*$ cat sottotitolo.native 
Pandoc (Meta {unMeta = fromList [("subtitle",MetaInlines [Str "Un",Space,Str "breve",Space,Str "sottotitolo",Space,Str "che",Space,Str "spiega",Space,Str "di",Space,Str "cosa",Space,Str "si",Space,Str "tratta"]),("title",MetaInlines [Str "Titolo",Space,Str "del",Space,Str "documento"])]})
[Para [Str "Questo",Space,Str "documento",Space,Str "di",Space,Str "test",Space,Str "serve",Space,Str "a",Space,Str "provare",Space,Str "il",Space,Str "sottotitolo."]
,Para [Str "Altro",Space,Str "paragrafo."]]
 rotterdam (master)*$ pandoc sottotitolo.native -t rst --template template --data-dir . -s
====================
Titolo del documento
====================

 rotterdam (master)*$ 

I found that title and subtitle are enclosed in MetaInlines at least when coming from a .docx like sottotitolo.docx, so i would at least add a pattern match for MetaInlines and drop the Plain container.

I also found confusing not to be able to use $subtitle$ in a template, and it's important for my team to render a subtitle within an highlight directive rather than as a bordered title like it's currently hardcoded in the rST writer, so i would change this logic in order to have $subtitle$ as a regular template variable.

I'd be happy to learn about reasons which might have caused the choices above and could affect the way we are planning to address this

[jgm]

Making the pattern match less fragile is definitely a good idea, unless we just decide to put title and subtitle in the template. As for putting it in the template: I believe the reason I did it this way is that rST wants the number of '=' or '-' characters underlining a title or subtitle to match the length of the title or subtitle text. There's no way to ensure this in the template. For example, if the template has $title$ ======= you'll always get 7 '=' signs, even if the title is shorter or longer. I'm open to thoughts about how we might do it differently.

[mb21]

The RST writer could populate the title variable with mytitle\n=======

[jgm]

Mauro Bieg <notifications@github.com> writes:

The RST writer could populate the `title` variable with `mytitle\n=======`

That's true, but I think @danse wanted the subtitle variable to be by itself (without dashes). Maybe we could have a `titleblock` variable that gets populated with title ===== subtitle -------- but keep `title` and `subtitle` as they are. That would give you a lot of options in a template.

[danse]

aha! yes, now i get it. I would opt for a dedicated variable. I would call it $titlerst, or $title-rst, or $titleRST, you know the style of meta variables better than me. This convention would be easy to use also in other formats when we want a smarter rendering of some metadata. I'd still keep $title and $subtitle available for the templates. If this solution works for you i will update the pull request tomorrow

[jgm]

In the markdown template we use `titleblock`, so I think that's the best one to use: $if(titleblock)$ $titleblock$ $endif$ Francesco Occhipinti <notifications@github.com> writes:

…

aha! yes, now i get it. I would opt for a dedicated variable. I would call it `$titlerst`, or `$title-rst`, or `$titleRST`, you know the style of meta variables better than me. This convention would be easy to use also in other formats when we want a smarter rendering of some metadata. I'd still keep `$title` and `$subtitle` available for the templates. If this solution works for you i will update the pull request tomorrow -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #4803 (comment)