Pandoc: option to omit titlepage

[vv01f]

feature request

I'd like to have no additional titlepage (single page with title, not the cover) in ePub (and maybe other formats as well)

e.g. with titlepage: false in yaml or --titlepage=false as CLI option.

my quick hack was using custom CSS section.level1 h1 { display: none; } to hide the section in question. another option would be a postprocessing step and removing it from the DOM.

[mb21]

what pandoc version are you on? I think this should already work...

see https://pandoc.org/MANUAL.html#templates and https://github.com/jgm/pandoc/blob/master/data/templates/default.epub3#L21

[jgm]

Messing with the template will probably yield a blank title page rather than none at all, because it will still be referred to in the epub's index.

Why do you want to omit the title page: it's a standard part of a book?

[tarleb]

Closing for lack of feedback; please reopen if necessary.

[NickBarreto]

Hello, coming across this now and I think this option would be useful also, and would suggest reopening.

@jgm is absolutely right that a title page is a standard part of a book and generating one is useful. However, I could see value in being able to suppress the inclusion of one, generally to introduce another title page from within the document source.

For example: the way we produce our title pages in EPUB at the moment (not using pandoc) is in one of two cases:

• Case 1: text title page
  We have an html title page which consists, essentially, of an h1 with the title, an h2 with the author, and an image logo.

• Case 2: title page is a 'patch'
  We have a title page which has 2 images: a title page 'patch' image, used so the book's title and author are rendered in a simplified black and white version of the typography in the book's cover, with alt text of 'book title by author name', and the same logo above. This is necessary because text in a cover is often distressed or otherwise altered in ways that embedding the same font as the cover would not necessarily result in the same visual presentation. Alt-text is very important here, as ever, for accessibility.

I was testing out how we would do this with pandoc, but I'm having trouble including the logo image used in both cases with the epub3 template, it isn't an image linked to in the source document, so pandoc doesn't know to package it in result EPUB, so I get a broken image link. I have managed to work around this in by base64 encoding the logo image in the template, but this is not an ideal implementation.

It also doesn't solve the problem of Case 2, when I want to pass in an image that is specific to this book into the template. Which, again, I could do it in base64 in a custom metadata attribute, but that would add a lot of bloat to a yaml file!

Both of these scenarios are easily dealt with if I could use --titlepage=false as suggested, and have a filter of my own which builds a title page from content in my source document, which would be able to be aware of image references as any other images in a pandoc source.

Alternatively, being able to flag a specific media file for inclusion in an EPUB would also solve the issue in this use case.

[jgm]

Would it work to have a metadata field with the image? This would ensure that the image is linked in the source document, hence included in the EPUB container. And you could just use the variable corresponding to the metadata field in the titlepage portion of the template.

[NickBarreto]

Yes, it would absolutely work if I could specify an image path in a metadata element and that image gets added to the package. That would also let me use an if in the template to include the patch image if one is present, or html h1 and h2 title and author if not, and solve both of those use cases.

This isn't existing functionality though, right?

I have quickly edited the base template to reference a metadata field I added in an external yaml file:

metadata.yaml:

logo_image: images/logo.jpg

template.epub3:

<div> 
    <img src="$logo_image$" alt="logo"/>
</div>

If I build an epub with this at the moment, the referenced resource is missing.
$ pandoc -o test.epub -t epub3 source.md --metadata-file=metadata.yaml --template=template.epub3

I get the same error if I add that metadata element within source.md as a yaml block. Either way would be fine in the end, though I generally prefer external metadata files.

[jgm]

I was thinking rather

logo_image: ![logo](images/logo.jpg)

and in template

<div>
   $logo_image$
</div>

Try that!

[NickBarreto]

That doesn't appear to work at the moment. If I have logo_image: ![logo](images/logo.jpg) in an external yaml file, pandoc appears to fail to load the entire metadata.

If I add it in a yaml block at the start the file itself, when I run pandoc I get the following warning:

[WARNING] Could not parse YAML metadata at line 5 column 1: Lexical error near " ![logo](images/logo.jpg)"

The result epub doesn't contain the image referenced. It is, at least, valid according to EPUBCheck in that since that YAML element hasn't been parsed, that metadata field is blank, and so the template doesn't evaluate it, and I don't have a broken image link – where the img html element should be in the generated file is just blank (which makes sense).

(Just to confirm, I am on pandoc 2.9.2)

[tarleb]

The value has to be quoted (because of the !). Try

logo_image: '![logo](images/logo.jpg)'

[NickBarreto]

Aha! @tarleb thank you very much. It works like a charm.

[vv01f]

Why do you want to omit the title page: it's a standard part of a book?

Sorry, I needed to change my notification settings on GH to receive notice.

Not every epub needs to be a full blown book. And metadata can be restrained to being metadata instead of redundantly in the content additionally. E.g. extracts (for educational purpose, the object was an article from an issue of a collection … where the sources haven been referenced in the texts footnotes and metadata sufficiently) or single chapters (not starting with heading1 for # but e.g. heading2 for ## in markdown source) for comfortable reading are a nice usecase. Then the heading1 will be added with the title so right after a titlepage the title is repeated. Another idea I had was --top-level-division=chapter, but with no effect to the heading1 still being filed with the title. That all is fine with no other titlepage. When adding a toc, the default toc-title (which I couldnt change to an empty string with the metadata variable, so used ol.toc #toc-li-1 { display: none; } for now) might give the title a third time. All together a bit much titleage.

now pandoc version 2.10, since today. :)