asciidoctor-diagram icon indicating copy to clipboard operation
asciidoctor-diagram copied to clipboard

generated img tags disregard output directory

Open chrylis opened this issue 9 years ago • 4 comments

I am using jekyll-asciidoc, and when I use the asciidoctor-diagram extension, files are saved according to the imagesoutdir attribute. However, the img tag in the HTML output always uses the name of the image file with no path information (e.g., <img src="foo.svg">) regardless of location.

chrylis avatar Nov 24 '15 18:11 chrylis

You need to set the imagesdir attribute to control the prefix used in the HTML.

mojavelinux avatar Nov 24 '15 19:11 mojavelinux

Ah; I thought that this would resolve automatically since the plugin is injecting the image tag. Unfortunately, imagesoutdir appears to be a global attribute (can this be overridden per-post in Jekyll?), which would leave all of the images in the same directory.

It seems like managing these parameters automatically (e.g., prefixing the same way that the output HTML files are) would be a good feature to have in the jekyll-asciidoc plugin, but I have no idea whether this would be feasible.

chrylis avatar Nov 24 '15 20:11 chrylis

I've reviewed the code related to this issue and came to the conclusion that there's not much I can do to improve this. At the moment when the block processing code is triggered, there is no information available regarding where the output master file (e.g., the HTML file) is going to be written. That makes it impossible for the diagram extension to produce a correct relative path wrt the output document.

Commit fb26ba2ba7f758067a582ed1bb6645a1cafe98a3 tweaks the the target attribute processing to allow that attribute to contain directory names. That way you can set imagesoutdir globally and specify the target directories explicitly per block. The relative path from the target attribute is also passed on to the HTML generator. It's not an ideal solution, but I think it's the best I can do for the time being.

pepijnve avatar Jan 24 '16 09:01 pepijnve

I also think that this issue should simmer more in the site plugins (Jekyll, Middleman, etc) so that we have a better understanding of the requirements. Once we know exactly what we want to have happen, then I think we can come back here and be productive discussing it. At least, I know I need to go through this thought process to provide useful input. I'm currently working on the Middleman plugin, so I'll explore some of the permutations there and see what we need to have happen (and if core needs any changes to make that possible).

mojavelinux avatar Jan 24 '16 09:01 mojavelinux