Hi, i wrote a simple extension for example purpose;

require 'asciidoctor/extensions' unless RUBY_ENGINE == 'opal'

include ::Asciidoctor

class UmlBlock < Extensions::BlockProcessor
  use_dsl

  named :uml
  on_context :open
  parse_content_as :raw

  def process parent, reader, attrs

    html = %(<div><strong>#{attrs['name']}</strong></div>
    <img src="#{attrs['src']}">
    <div><b>Content:</b> #{reader.read}</div>)

    # QUESTION should we allow attribute references in the slim source?
    create_pass_block parent, html, attrs, subs: nil
  end
end

reader.read prints words without linebreak, it print in same line, How can i generate with linebreaks?

Second question is, is there a documentation for developing asciidoctor extensions?

Thanks

Issue #39 introduced a new attribute imagesoutdir whose usage is not explained in the documentation.

If the width and height of the image are not specified, set the width and height explicitly by examining the generated image (or however else the information can be acquired).

Hi,

is it possible to specify command line arguments or something equivalent in the asciidoc file when running ditaa? I would like to control effects like box shadows and box separations which is possible via ditaa command line arguments --no-separation and --no-shadows.

Thanks.

The problem only appear on consecutive calls to asciidoctor-diagram in the same process.

Context

I made a Ruby script to convert several adoc located in differents directories.
Some documents include PlantUML blocks including images using the creole syntax (e.g. <img:my_pic.png>).
The images for each document are in the same directory of it.

For each document the script changes the working directory using Dir.chdir and trigger the conversion using Asciidoctor.convert

Problem

Only the PlantUML blocks of the first rendered document has the creole images rendered correctly. With the next documents there is an error in the drawing saying that the image files were not found.
One can see in the path of the image that the directory of the first document was used instead of the current one.

My 2 cents analysis

The JVM is only launched once for perfomance concerns.
It will get the working directory set by Ruby and keep it forever.

For testing purpose I patched the Asciidoctor::Java::Java::CommandServer.instance method to have it create a new server at each call.
The performances are for sure horrible but all my documents were rendered correctly.

To speed up the processor, and avoid redundant image generation, the plugin should be smart about using a cached version of the diagram if available. A simple approach would be to take a signature of the diagram source (md5sum or lighter) and look for a matching diagram on disk. Since the file name is customizable, it may be necessary to store the signature information in an index file, such as a json, YAML or flat text file.

This optimization is especially important since diagrams change very rarely once they are sorted out.

Currently RJB is a required dependency of asciidoctor-diagram. It's used when running PlantUML and Ditaa to avoid starting a new JVM instance for each diagram. RJB uses native ruby extension which makes it more difficult to install compared to regular gems.

To make asciidoctor-diagram installation simpler, consider making RJB an optional dependency. When RJB is not available at runtime, fallback to launching a JVM using a subprocess instead. This will be considerably slower than the current RJB based codepath, so we should document that installing RJB can provide a performance improvement.

This is probably already in your backlog but making these extensions work with both asciidoctor-maven-plugin and asciidoctor-gradle-plugin plugins would be very practical. This would eliminate the need to invoke Asciidoctor via the Ruby API.

Or maybe there is already a way to achieve it?

BTW, I'm amazed by the ease of creating and inserting any kind of diagram in a document. Great job!

PlantUML is able to generate sequence diagrams without using dot. However the asciidoc-diagram extension still fails with:

ERROR: Failed to generate image: PlantUML image generation failed: Bad Req
uest java.io.IOException: Could not find GraphViz 'dot' tool
at org.asciidoctor.diagram.PlantUML.getGraphviz(PlantUML.java:24)
at org.asciidoctor.diagram.PlantUML.generate(PlantUML.java:35)
at org.asciidoctor.diagram.CommandProcessor.processRequest(CommandProcessor.java:34)
at org.asciidoctor.diagram.CommandProcessor.processRequest(CommandProcessor.java:11)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

I worked around it by creating an empty "dot.bat" file that does nothing and then it works and shows the diagrams correctly, which proves it doesn't actually need dot. This is true only for sequence diagrams.

For example:

plantuml::file.puml[ "target", "svg" ]

just writes to file.svg

whereas

["plantuml", "target", "svg"]
---------------------------------
include::file.puml[]
---------------------------------

writes to target.svg

( same for png format )

Can not install extension:

#gem install asciidoctor-diagram --pre
Building native extensions.  This could take a while...
ERROR:  Error installing asciidoctor-diagram:
        ERROR: Failed to build gem native extension.

        /usr/bin/ruby1.9.1 extconf.rb
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- mkmf (LoadError)
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from extconf.rb:6:in `<main>'


Gem files will remain installed in /var/lib/gems/1.9.1/gems/rjb-1.4.9 for inspection.
Results logged to /var/lib/gems/1.9.1/gems/rjb-1.4.9/ext/gem_make.out

Currently plantuml and ditaa are packaged inside the gem, but shaape, blockdiag, etc are not. I think we should consider taking plantuml and ditaa out of the gem and treat them like the other external tool dependencies.
As a convenience a small bit of code could be added to asciidoctor-diagram to download the jars from a maven repo. Additionally new document attributes could be introduced that allow the default version numbers to be overridden which allows users to use more recent versions of plantuml.
There are two benefits to this change:

• the gem becomes smaller
• the version of plantuml and ditaa is decoupled from the version of asciidoctor-diagram

The look of plantuml generated images can be controlled using skin parameters. Parameter values can be defined inline in each diagram or externally in a configuration file. In order to get a common customised look throughout a document it would be useful to be able to provide the path to a plantuml configuration via a document attribute.

It would be nice if there would be a possiblility to scale the generated svg diagrams. Especially for plantuml this would be nice:

[plantuml, scale="200%"]

A->B

In my experience, the digraph for Graphviz cannot be defined on a single line. Doing so results in a broken image. This should either be documented or fixed.

For example, if I create the following digraph in my AsciiDoc document:

[graphviz]
....
digraph g { rankdir=LR; Text->Graphviz->Image }
....

I get the following image:

If I add a newline after the opening curly brace:

[graphviz]
....
digraph g {
  rankdir=LR; Text->Graphviz->Image }
....

then I get a proper diagram.

This minor detail could be a big stumbling block for new users. Let's give them a good start.

It would be nice to have ASCIImage as an extension similar to the diagramming one.

There's a Ruby-based library already: https://github.com/Oblomov/asciimage-ruby

Originally submitted here: asciidoctor/asciidoctor#1317

Currently, the rendered images that have auto-generated image names can be hard to cleanup because there is no easy way to refer to them as a group. Introduce a fixed prefix to the auto-generated name, such as diag-, so they can easily be identified in bulk.

You can make this prefix configurable using a document-level attribute, though that may be overkill.

Currently we can not specify another output folder.

We can use the 'outdir' document attribute for this.
The gem should generate images relative from this folder, if the document attribute is specified.

Maybe i'm missing something but I don't find mention of dot being required for usage of asciidoctor-diagram but it seems it is.

At least when I add a diagram I get this error:

Could not find the Graphviz 'dot' executable in PATH; add it to the PATH or specify its location using the 'graphvizdot' document attribute

and it breaks the rendering of any asciidoc very abruptly.

Should document the requiremnets and how to install dot on the various OS's.

But that said - i would much rather prefer that a "Dot not installed - cannot render document" image put into the document rather than breaking the asciidoctor rendering completely.

This is to not require everyone to "fight" having to install dot just to render a single document out of possible hundreds that works fine without it.

I am running the following command:

$ asciidoctor --safe-mode unsafe -a lang=ja -b html5 -d book -r asciidoctor-diagram -o temp.html test.adoc

which gives me an error: No Java runtime present, requesting install and popups dialog inviting to install Java SE 6. I've installed Java 8 from Oracle website, but the behavior remains unchanged.

I've verified that Java 8 has been installed correctly:

$ java -version
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)

What can cause this issue?

I'm trying to convert over to asciidoctor from asciidoc and installed the latest version of both asciidoctor (1.50) and asciidoctor-diagram (1.2.0) on my Ubuntu machine. All my ditaa and plantuml figures get generated correctly, but the only "diag" figure I can get to work is blockdiag, the others, like seqdiag and packetdiag give me:

invalid style for listing block: packetdiag
invalid style for listing block: seqdiag

Is there a step or syntax I missed someplace? Any help would be greatly appreciated.

Thanks,

-Mike

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.

A great feature for the PlantUML Integration would be to inline the SVG with the html5 backend. This would have the advantage that no external files would be needed.

Generated png images are corrupt on windows. Svg output does work.

Add support for the Shaape diagram language and converter.

https://github.com/christiangoltz/shaape

The nice part about Shaape is that it already has an extension for AsciiDoc Python, so it should be straightforward to see how it gets invoked from plain-text input.

Since Shaape is written in Python, it will have to be invoked over the system process bridge.

The PlantUML included in the gem - Version 8004 - does not handle the detach keyword

how or is it possible at all to run this extension asciidoctorj?

Initially reported as pepijnve/asciidoctor-diagram-java#1 by @0000-bigtree.

i use asciidoctor-diagram (1.3.0.preview.4) CRuby(2.2.2p95 (2015-04-13 revision 50295) [i386-mingw32]) with below ditaa code in a adoc(UTF-8)

ruby -Ku -S asciidoctor -r asciidoctor-diagram xxx.adoc

[ditaa, "header", "png"]

+---------+
| 4 bytes | CRC
+---------+
| 1 byte | 协议版本(Chinese Character!)
+---------+
| 2 bytes | 消息类型 ID(命令码)

+---------+

produced png did not render Chinese character correctly.

but i use

java -Dfile.encoding=UTF-8 -jar ditaa0_9.jar(from sourceforge)  xxx.ditaa

produced png，it rendered fine.

Update PlantUML to the latest revision.

Note that the latest builds include an old version of Ditaa. We should probably repackage PlantUML using jarjar to avoid any weird behaviour due to version incompatibilities.

In asciidoctor-diagram 1.2.0 the location of the graphviz dot command could be specified using the graphvizdot document attribute. Since 1.3.0 this is no longer supported.
Support for this attribute should be restored.

Additionally it would be convenient to support this attribute for graphviz type diagrams as well. Currently only the dot document attribute can be used for this.

When I render the following block:

[graphviz,"test",svg]
----
graph G {
  clusterC -- clusterB
}
----

I get the following error message: (RuntimeError) Invalid PNG signature

I am using the basic maven setup from the maven examples (asciidoctor-diagram-example) on a french Windows 7 Pro.

I patched the file 'png.rb' which causes this error by returning a size by default. With this patched version the png file gets created but is corrupted.

I suspect this being an encoding issue UTF-8 vs ISO.

(Btw, I also tried generating the png on my command line with the exact same parameters and it works.)

Below the complete error output.

[INFO] --- asciidoctor-maven-plugin:1.5.0:process-asciidoc (generate-html-doc) @
 asciidoctor-diagram-example ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.248 s
[INFO] Finished at: 2014-11-06T13:30:58+01:00
[INFO] Final Memory: 12M/30M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.asciidoctor:asciidoctor-maven-plugin:1.5.0:pr
ocess-asciidoc (generate-html-doc) on project asciidoctor-diagram-example: Execu
tion generate-html-doc of goal org.asciidoctor:asciidoctor-maven-plugin:1.5.0:pr
ocess-asciidoc failed: (RuntimeError) Invalid PNG signature -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:

Hi,

Are the graphviz custom shapes supported ?
http://www.graphviz.org/wiki/how-create-custom-shapes

In other word, is there a way to activate the options -Tps, -Tps2, -Tpng, -Tsvg .....

Thanks in advance.

This error is thrown when trying to generate the same files a second time without deleting the files that were already generated:

NoMethodError: undefined method `[]' for nil:NilClass
Use --trace for backtrace

Hi,
This is a bit 'yak shaving'ish - but here is the story.

Ditaa extension for asciidoctor-diagram (great stuff - btw) allows (recently - as of #69) for ditaa options.
One of the options on DItaa sourcecode is "transparent" background (https://github.com/stathissideris/ditaa/blob/master/src/org/stathissideris/ascii2image/core/CommandLineConverter.java#L71). However - this is not a feature available in the downloadable version of DItaa.

When I build Ditaa from source I can easily run it with

{ examples } master » java -jar /tmp/ditaa/releases/ditaa0_9.jar -S -T ditaa.txt                                               /tmp/asciidoctor-diagram/examples  

ditaa version 0.9, Copyright (C) 2004--2009  Efstathios (Stathis) Sideris

Running with options:
no-shadows
transparent
Reading file: ditaa.txt
Rendering to file: ditaa_3.png
Done in 0sec

Then for a following snippet

                   +-------------+
                   | asciidoctor |-------+
                   |  diagram    |       |
                   +-------------+       | png out
                       ^                 |
                       | ditaa in        |
                       |                 v
 +--------+   +--------+----+    /---------------\
 |        | --+ asciidoctor +--> |               |
 |  Text  |   +-------------+    |Beatiful output|
 |Document|   |   !magic!   |    |               |
 |     {d}|   |             |    |               |
 +---+----+   +-------------+    \---------------/
     :                                   ^
     |          Lots of work             |
     +-----------------------------------+

I got result as expected (with transparent background!)

However that doesn't get supported by the diagram extension.
The ditaamini0_9.jar doesn't look to me as a standard ditaa distribution and simple replacement of an old jar with a new build triggers a following error

Exception in thread "main" java.lang.NoSuchMethodError: org.stathissideris.ascii2image.text.TextGrid.loadFrom(Ljava/io/InputStream;Lorg/stathissideris/ascii2image/core/ProcessingOptions;)V
    at org.asciidoctor.diagram.Ditaa.generate(Ditaa.java:61)
    at org.asciidoctor.diagram.CommandProcessor.processRequest(CommandProcessor.java:34)
    at org.asciidoctor.diagram.CommandServer.processRequests(CommandServer.java:38)
    at org.asciidoctor.diagram.CommandServer.main(CommandServer.java:20)
asciidoctor-diagram: ERROR: Failed to generate image: end of file reached

Now, when I browse further - I see some more changes are required in here https://github.com/pepijnve/asciidoctor-diagram-java/blob/master/src/main/java/org/asciidoctor/diagram/Ditaa.java#L33

Before I start drilling there and fiddling with the code further, I just want to confirm that my thoughts are right. The steps should be

• update the ditaa.jar in the asciidoctor-diagram-java project
• fix the api changes
• apply "transparent" flag in both asciidoctor-diagram-java and asciidoctor-diagram
• pull request

Additional question, if the freshly built ditta.jar is not a drop-in replacement how can I reproduce the built of ditaamini0_9.jar

--Kuba

PS. My usecase. I started to use diagram for my training presentations. I have the diagrams together with slides and when it gets rendered into any html deck - the transparent background would make a bit more sense in some cases.

I'm trying to use asciidoctor for a highly linked documentation mostly based on generated graphs.

I'll use graphviz and nwdiag for this.

The graphs and their integration look very good, thank you.

But the hyperlinks set in the graphs (Ex: web_srv [href="web_srv_details.html"]) are dead when clicked upon from the html page.
Actually they are useable if I view the .svg file alone, so they work well.

I found out it is caused by the way the -svg files are embedded into the html, using <img src=
This is known to make svg elements "inanimate".

An SVG embedded with an tag and one embedded as a CSS background image are treated in a similar way when it comes to CSS styling and animation. Styles and animations applied to an SVG using an external CSS resource will not be preserved once the SVG is embedded.

If I manually edit the html to embed the .svg with <object type="image/svg+xml" data=, then
it works well, with the links clickable, as expected.

I also noted another side-effect: nwdiag seems to embed icons/images (think cisco plugin) using their
full-path. When I replaced the path with a local one it didn't work (blank image).
But after using <object type="image/svg+xml" data= for the html embedding, it started to work.

I think the images of format SVG should be (at least optionally) embedded as <object ... />.

Thanks for the good job.

The examples using 'gemPath' are not working on windows.

[ERROR] Failed to execute goal org.asciidoctor:asciidoctor-maven-plugin:1.5.0:process-asciidoc (generate-html-doc) on project asciidoctor-diagram-example: Execution generate-html-doc of goal org.asciidoctor:asciidoctor-maven-plugin:1.5.0:process-asciidoc failed: (LoadError) no such file to load -- asciidoctor-diagram -

If I replace
<gemPath>${project.build.directory}/gems-provided</gemPath>
by
<gemPath>target/gems-provided</gemPath>
it is working.

I think it's an issue with the ${project.build.directory} using \ instead of / as file seperator on windows. And the \ is probably considered as an escape character somewhere further in the chain.

It would be nice to have Wavedrom(https://github.com/drom/wavedrom) as an preprocessing extension.
It is 4 years old open-source software, It's really cool to adding waveform in documents.
It's implemented with javascript, but it also served as an executable cli version on here: https://github.com/wavedrom/wavedrom.github.io/releases

It would be nice if it were possible to specify the font used in diagrams (for instance, in salt file trees).

This definitely isn't something we should encourage at the block-level since it mixes content and presentation. We could, however, allow document-level attributes to be used, such as:

:diagram-font-family: Noto Sans

Another option is to consider having a configuration file for Asciidoctor Diagram in which we can put all diagram-related options. For instance, it might be nice to be able to customize the look and feel of various types of nodes. Too much of this in the AsciiDoc document and it gets cluttered.

Now that Asciidoctor 1.5.0 is released, I think we're ready to flip the switch on the Asciidoctor Diagram branch for 1.5.0 by making it the main gem release.

Prelease 1.2.0.preview.5 errors:
"""
~> ~/.gem/ruby/1.9.1/bin/asciidoctor-diagram --trace Desktop/Article.adoc
/home/thorsten/.gem/ruby/1.9.1/gems/asciidoctor-1.5.0.preview.8/lib/asciidoctor/cli/options.rb:226:in rescue in parse!': uninitialized constant OptionParser (NameError) from /home/thorsten/.gem/ruby/1.9.1/gems/asciidoctor-1.5.0.preview.8/lib/asciidoctor/cli/options.rb:36:inparse!'
from /home/thorsten/.gem/ruby/1.9.1/gems/asciidoctor-1.5.0.preview.8/lib/asciidoctor/cli/options.rb:32:in parse!' from /home/thorsten/.gem/ruby/1.9.1/gems/asciidoctor-1.5.0.preview.8/lib/asciidoctor/cli/invoker.rb:20:ininitialize'
from /home/thorsten/.gem/ruby/1.9.1/bin/asciidoctor-diagram:9:in new' from /home/thorsten/.gem/ruby/1.9.1/bin/asciidoctor-diagram:9:in

asciidoctor-diagram was installed with
"""
gem install --prerelease --user-install asciidoctor-diagram
"""

asciidoctor-diagram-1.1.5 works without problem

I've added the following to Gemfile:

gem 'asciidoctor', '1.5.0'
gem 'asciidoctor-diagram'

Run bundle update.

Added require 'asciidoctor-diagram' to pipeline.rb

If i do not run 'brew install graphviz' I get #41

When I have run 'brew install graphviz' I get:

"Constants DL and Fiddle is not defined."

When trying to render

[ditaa]
----
                   +-------------+
                   | Asciidoctor |-------+
                   |  Diagram    |       |
                   +-------------+       | PNG out
                       ^                 |
                       | ditaa in        |
                       |                 v
 +--------+   +--------+----+    /----------------\
 |        | --+ Asciidoctor +--> |                |
 |  Text  |   +-------------+    |Beautiful output|
 |Document|   |   !magic!   |    |                |
 |     {d}|   |             |    |                |
 +---+----+   +-------------+    \----------------/
     :                                   ^
     |          Lots of work             |
     +-----------------------------------+
----

Full stacktrace is:

/Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-diagram-1.2.0/lib/asciidoctor-diagram/util/java_rjb.rb:51:in `load'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-diagram-1.2.0/lib/asciidoctor-diagram/util/java_rjb.rb:51:in `load'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-diagram-1.2.0/lib/asciidoctor-diagram/ditaa/extension.rb:11:in `ditaa'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-diagram-1.2.0/lib/asciidoctor-diagram/ditaa/extension.rb:32:in `block (2 levels) in '
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-diagram-1.2.0/lib/asciidoctor-diagram/util/diagram.rb:130:in `call'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-diagram-1.2.0/lib/asciidoctor-diagram/util/diagram.rb:130:in `create_image_block'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-diagram-1.2.0/lib/asciidoctor-diagram/util/diagram.rb:105:in `generate_block'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-diagram-1.2.0/lib/asciidoctor-diagram/util/diagram.rb:23:in `process'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-1.5.0/lib/asciidoctor/parser.rb:1084:in `[]'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-1.5.0/lib/asciidoctor/parser.rb:1084:in `build_block'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-1.5.0/lib/asciidoctor/parser.rb:891:in `next_block'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-1.5.0/lib/asciidoctor/parser.rb:303:in `next_section'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-1.5.0/lib/asciidoctor/parser.rb:52:in `parse'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-1.5.0/lib/asciidoctor/document.rb:448:in `parse'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-1.5.0/lib/asciidoctor.rb:1337:in `load'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/asciidoctor-1.5.0/lib/asciidoctor.rb:1415:in `convert'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/handlers/template/asciidoc.rb:20:in `evaluate'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/tilt-1.4.1/lib/tilt/template.rb:103:in `render'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/handlers/base_tilt_handler.rb:130:in `rendered_content'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/handlers/asciidoctor_handler.rb:87:in `rendered_content'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/handlers/layout_handler.rb:48:in `rendered_content'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/page.rb:135:in `rendered_content'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/page.rb:174:in `content'
          /Users/max/code/jbosstools/jbosstools-website/blog/index.html.haml:47:in `block (2 levels) in singletonclass'
          /Users/max/code/jbosstools/jbosstools-website/blog/index.html.haml:23:in `each'
          /Users/max/code/jbosstools/jbosstools-website/blog/index.html.haml:23:in `block in singletonclass'
          /Users/max/code/jbosstools/jbosstools-website/blog/index.html.haml:65535:in `instance_eval'
          /Users/max/code/jbosstools/jbosstools-website/blog/index.html.haml:65535:in `singletonclass'
          /Users/max/code/jbosstools/jbosstools-website/blog/index.html.haml:65533:in `__tilt_70111851345320'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/tilt-1.4.1/lib/tilt/template.rb:170:in `call'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/tilt-1.4.1/lib/tilt/template.rb:170:in `evaluate'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/tilt-1.4.1/lib/tilt/haml.rb:24:in `evaluate'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/tilt-1.4.1/lib/tilt/template.rb:103:in `render'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/handlers/base_tilt_handler.rb:130:in `rendered_content'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/handlers/layout_handler.rb:48:in `rendered_content'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/page.rb:135:in `rendered_content'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/engine.rb:310:in `generate_page'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/engine.rb:380:in `generate_page_internal'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/engine.rb:373:in `block in generate_page_by_output_path'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/engine.rb:372:in `each'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/engine.rb:372:in `generate_page_by_output_path'
          /Users/max/.rvm/gems/ruby-1.9.3-p547@jbosstools-website/gems/awestruct-0.5.4.rc3/lib/awestruct/cli/auto.rb:40:in `block (3 levels) in run'

I compile my documents from the CLI like this:

asciidoctor -r  asciidoctor-diagram   -D target/   source/samle.adoc

asciidoctor will create the output sample.html in the target/ directory.
But asciidoctor-diagram creates all the PNG files in the active directory . and not in target/. Therefore, the image links in sample.html are also wrong.

I installed asciidoctor and asciidoctor-diagram as instructed but I can't generate a test diagram. I got an error and I'm not sure what it is:

/usr/local/Cellar/ruby/2.1.0/lib/ruby/gems/2.1.0/gems/asciidoctor-0.1.4/lib/asciidoctor/cli/invoker.rb:98:in `rescue in invoke!': java.io.FileNotFoundException:  (No such file or directory) (RuntimeError)
    from /usr/local/Cellar/ruby/2.1.0/lib/ruby/gems/2.1.0/gems/asciidoctor-0.1.4/lib/asciidoctor/cli/invoker.rb:32:in `invoke!'
    from /usr/local/Cellar/ruby/2.1.0/lib/ruby/gems/2.1.0/gems/asciidoctor-0.1.4/bin/asciidoctor:15:in `<top (required)>'
    from /usr/local/bin/asciidoctor-diagram:23:in `load'
    from /usr/local/bin/asciidoctor-diagram:23:in `<main>'

I was digging around and found out that initawt.jar is missing. Maybe this is the problem?

If you specify the -D <destination dir> or -o <output file> options to asciidoctor, you get the following warning (which is actually an error as the image is not included in the document.)

WARNING: image to embed not found or not readable: <document src dir>/<diagram name>

Note that in the failing case <output file> is in a directory other than the document source directory.

This error happens because the diagram image is generated in the destination directory while asciidoc is looking for it in the source directory.

In version 1.2.1, when dot command was not found,an exception was thrown and the conversion aborted. But in version 1.3.1 the conversion shows the exception in the console, but also inserts it into the generated HTML (see attachment). Seems to me that it is not thrown or asciidoctor (ruby) is not catching it.

I am using the example https://github.com/asciidoctor/asciidoctor-maven-examples/blob/master/asciidoctor-diagram-example/src/docs/asciidoc/example-manual.adoc with asciidoctorj-1.5.2.1 and asciidoctorj-1.5.3.2 and both have the same behaviour, so I guess it isn't a change in Asciidoctorj.

example-manual.txt

Let me know if you need anything else.

I want to integrate PlantUML to AsciidocFX because It is based on Java. What can be the best practice with Asciidoctorjs. How can i extend it?

Just tried to install on windows+cygwin, but can't get it to work. I'm not sure if this is my instalation problem or i have found a bug.

My instalation procedure (from cygwin prompt):

$ apt-cyg install graphviz
$ apt-cyg install rubygems
$ gem install ascii-doctor-diagram
$ cd my-project-dir
$ asciidoctor -r asciidoctor-diagram Test.adoc
Error: Could not find or load main class org.asciidoctor.diagram.CommandServer
asciidoctor-diagram: ERROR: Failed to generate image: end of file reached
$ cd ~/.gem/ruby/gems/asciidoctor-diagram-1.3.0/examples
$ asciidoctor -r asciidoctor-diagram -I ../lib design.adoc
Error: Could not find or load main class org.asciidoctor.diagram.CommandServer
asciidoctor-diagram: ERROR: Failed to generate image: end of file reached
Error: Could not find or load main class org.asciidoctor.diagram.CommandServer
asciidoctor-diagram: ERROR: Failed to generate image: end of file reached

My version is:

$ gem list

*** LOCAL GEMS ***

asciidoctor (1.5.2)
asciidoctor-diagram (1.3.0)
json (1.8.2)
minitest (5.4.3)
power_assert (0.2.2)
rake (10.4.2)
rdoc (4.2.0)
test-unit (3.0.8)

When I embed a "blockdiag" diagram into a table's cell (with cell's type = asciidoc) it does not get generated.

However, if I place the same diagram's code outside and before the table too, then it gets
a) generated and displayed before the table (which I do not want, of course)
b) the diagram, for which a file now exists, gets gracefully displayed in the table's cell (which is what I want)

What this means:
a) my environment is correctly configured (called with asciidoctor -r ascii-diagram)
b) the asciidoc interpretation of the cell does kick in (the file link obviously gets generated)
c) but it does not kick the generation of diagrams in )-:

Thanks for your help.

Here an example:

// pre-generate the diagram
[blockdiag, target='hosts-relationships-0-from', 'png']
----
{
  A <- B -> C -- D <-> E;
}
----

// table with embeddings
[cols="2", options="header", width="100%"]
|===
a| This host is involved in following relationships

[blockdiag, target='hosts-relationships-0-from', 'png']
----
{
  A <- B -> C -- D <-> E;
}
----
a| This host is involved in following relationships

[blockdiag, target='hosts-relationships-0-to', 'png']
----
{
  A <- B -> C -- D <-> E;
}
----


|===

When trying to run asciidoctor-diagram on a 'clean' Mavericks installation without Java 6 installed (but with Java 7 installed from Oracle) it fails with an error stating that Java was not installed and it pops up the dreaded Install Java modal dialog, which directs to Apple's Java 6 download.

• JAVA_HOME is pointing to the right JDK (export JAVA_HOME=$(/usr/libexec/java_home) in bash_profile)
• jruby was installed through homebrew, and updated to the latest
• gem is latest installation

plantuml has an included subproject called "salt".
It should be possible to draw a tree like this:

[plantuml,format="svg"]
----
salt
{T
+ A
++ a
+ B
++ b
}
----

Unfortunately I get a syntax error here. Suppose that the starting line "salt" isn't sent to plantuml.