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
- asciidoctor-diagram 2.03 Should resolve diagram-svg-type https://github.com/asciidoctor/asciidoctor-diagram/issues/110 — committed to bric3/hugo-builder by bric3 4 years ago
- #110 Add experimental 'autoimagedir' feature — committed to asciidoctor/asciidoctor-diagram by pepijnve 4 years ago
- #110 Add experimental 'autoimagesdir' feature — committed to asciidoctor/asciidoctor-diagram by pepijnve 4 years ago
- #110 Make cachedir explicitly configurable — committed to asciidoctor/asciidoctor-diagram by pepijnve 4 years ago
@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:
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 theimages::
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 specifyingimagesoutdir
as a relative path and then settingbase-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 forimagesoutdir
.That’s an easy one to add. I’ll add support for a
diagram-cachedir
attribute to override the current behaviour.That’s kind of what
imagesoutdir
is for. Having a distinct attribute for generated images with the semantics ofimagesdir
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).