asciidoctor-diagram: When I set the `outdir` attribute, the picture in the gernerated document is not correct.

I have a Asciidoc as follows:

:outdir: target

== Test Diagram

plantuml::puml/class.puml[format=svg, alt="Class diagram", target="{outdir}"]

The class.puml is as follows:

class BlockProcessor
class DiagramBlock
class DitaaBlock
class PlantUmlBlock

BlockProcessor <|-- DiagramBlock
DiagramBlock <|-- DitaaBlock
DiagramBlock <|-- PlantUmlBlock

run asciidoctor -r asciidoctor-diagram sample.adoc, then it gernerates the UML diagram in target/, named target.svg.

But the path in html file is <img src="target.svg" alt="Class diagram" width="254" height="281">.


When I remove the target attribute, as follows:

:outdir: target

== Test Diagram

plantuml::puml/class.puml[format=svg, alt="Class diagram"]

The gernerated UML diagram in target/, named class.svg.

Then, path in html file is <img src="class.svg" alt="Class diagram" width="254" height="281">.

About this issue

  • Original URL
  • State: open
  • Created 8 years ago
  • Comments: 37 (22 by maintainers)

Commits related to this issue

Most upvoted comments

@bric3 ok, I’ll try to reproduce this. That doesn’t sound like the expected behaviour.

Regarding svg-type seems like I already forgot the changes I made . Oops. From looking at the code it seems like what you’re describing should work indeed. I’ll have to run that through the debugger as well.

Another user raising hand due to the same issue.

I would like to keep a clear separation between generated images and the ones provided by the user, else it becomes all too easy to overwrite the originals.

Today I came across the use case that I may not want to generate the files into the same directory that my other images are in, ex:

imagesoutdir == $(img_loc)/gen
imagesdir == $(img_loc)

However, I have no way to tell asciidoctor-diagram where to look for the generated files, and it will look in imagesdir with no way to change it for generated blocks.

This comes into play where we are using git lfs to keep track of our static files, but still want to ignore autogenerated ones. I think it would be great if it was possible to have the resultant image:: tag able to be pointed in more than one location (imagesdir). At this point, I have to have imagesdir be a duplicate of imagesoutdir and then specify my path from there for all of my non-autogenerated images (image::../static/{..}).

A basic solution would be the ability to use :imagesoutdir: for the path that the images:: tag for autogenerated images automatically searches, as that is where they are placed anyway.

@bric3 FYI, I just built and published 2.0.3 which should fix the svg-type issue.

Regarding the relative paths, those are resolved wrt the base-dir value you provide. So specifying imagesoutdir as a relative path and then setting base-dir to some directory means your images are going to end up in <base-dir>/<imagesoutdir>. If that’s not what you want you need to specify an absolute path for imagesoutdir.

Ideally there should a configurable location for the .svg.cache

That’s an easy one to add. I’ll add support for a diagram-cachedir attribute to override the current behaviour.

and the should be a different imagesdir for generated diagrams

That’s kind of what imagesoutdir is for. Having a distinct attribute for generated images with the semantics of imagesdir is not currently possible I’m afraid. There’s no good way for an extension to pass all the necessary bits of information to the backend converters. Or at least not that I know of. @mojavelinux has anything changed in this area in the meantime?

@bric3 the svg-type issue should be fixed by aa9969cb36cc8b9a9c6fbec2746a01ae23cf74c0 already.

No, Gradle will not help you for the IDE. The IDE has to take on this responsibility (as the IntelliJ plugin does). If you are outside of the IDE, then you’d use a build tool like Gradle. Either way, Asciidoctor is not a build tool.

So to clarify my point, you should seek for the vscode plugin to match the behavior of the IntelliJ plugin. (In general, we want the IDEs to align on behaviors such as this, which will be a focus of the AsciiDoc Working Group).