set backend attribute to indicate pdf

Currently the value of the {backend} attribute is html5.

I propose it be either pdf or html or html-pdf or html5-pdf.

Although the toolchain involves the html, the end user is targetting pdf and may have logic (as I do) which seeks to deactivate features or modify the document in response to that.

[ahus1]

Currently the “backend” is the converter from AsciiDoc to HTML, and you could use different converters, for example html5s, the semantic HTML converter.

For now I recommend that you add your own attribute on the command line/build process like this:

asciidoctor-pdf -a testattr=abc basic-example.adoc

Looking forward (and to be discussed) the appropriate attribute I’d see is {env}. You can use it or {env-github} today to find out if your source is rendered for example on GitHub for preview:

ifdef::env-github[]
:imagesdir: foo/
endif::[]

I wonder if this this should be pdfjs or pdf.

[Mogztter]

The backend is strictly intended for converter resolution.

Ok.

Since this conversion relies on the HTML converter to run first, I’m inclined to say the backend should remain unchanged or be html-pdf.

At first, I thought that the conversion to HTML was just an implementation detail (ie. an intermediate step to produce a PDF) but now I don’t think it’s true. The conversion to HTML is a central piece of this converter.

Why not web-pdf? I think it’s important to be consistent in the naming, so if we rename this project asciidoctor-web-pdf then I think the backend should be web-pdf. I also think that html-pdf can be confusing because both html and pdf are output formats.

You could also consider introducing a new attribute to give an indication that pdf is the intended output format.

outfileformat=pdf? outfilemimetype=application/pdf? I don’t use separators because outfilesuffix does not use separators but arguably it’s hard to read…

What do you think about env-web-pdf and env=web-pdf?