asciidoctor-1.5.5, asciidoctor-pdf-1.5.0.alpha.16
โโโ common
โย ย โโโ variables.adoc
โโโ export
โย ย โโโ Article.html
โย ย โโโ Article.pdf
โโโ images
โย ย โโโ diagram
โย ย โย ย โโโ dataflow.png
โย ย โโโ figure
โย ย โย ย โโโ dataflow-components.png
โย ย โโโ logo.png
โโโ locale
โย ย โโโ attributes-de.adoc
โโโ Article.adoc
cd Article
asciidoctor-pdf -b pdf -D export Article.adoc
md5-337b986f6184f8bb3e40d112fc33ee32
asciidoctor [-b html5] -D export Article.adoc
...requires :imagesdir: ../images for correct output to export/Article.html.
Bug or feature or is the fault with me?
The imagesdir has a different meaning / purpose for PDF and HTML. For PDF, it's interpreted relative to the source document. For HTML, it's interpreted relative to the output document (unless the images are embedded, in which case it behaves like PDF).
Here's why there is a difference.
When converting a PDF, the imagesdir tells the converter where to look for the image to embed. The converter is going to look for the image relative to the source document.
When converting the HTML, the imagesdir tells the client browser where to look for the image. The value should be the path from the output document to the location where you're publishing the images (which sit alongside the HTML document).
That's why there's a difference. So you have to set the attribute accordingly.
Thanks for the fast clarification.
Would not a output handling in the options be better?
One unchanged source file and the relativity triggerd by -D...
This behavior was defined by AsciiDoc Python and thus in order to be compliant (and not break a lot of documents) it must remain this way. However, I have often discuss of adding new attributes that would be used to control image handling in a more fine grained way. That's likely the path forward.
I will handle my configuration so:
:imagesdir: images
ifdef::backend-html5[:imagesdir: ../images]
You've got the idea!
Note, also see related issues https://github.com/asciidoctor/asciidoctor/issues/650 and https://github.com/asciidoctor/asciidoctor/issues/894 where imagesdir is discussed in the context of standalone subdocuments.
Most helpful comment
This behavior was defined by AsciiDoc Python and thus in order to be compliant (and not break a lot of documents) it must remain this way. However, I have often discuss of adding new attributes that would be used to control image handling in a more fine grained way. That's likely the path forward.