Add blockdiag support

[holmboe]

I am looking to integrate network diagrams in our technical documentation using nwdiag from http://blockdiag.com/ and it would make a really good candidate for pp integrated support. As pp integrates a rather large list similar tools that generate graphics I thought this would be a good addition.

nwdiag comes in a suite of four tools/installables which includes: blockdiag, seqdiag and actdiag.

Note that nwdiag includes also includes the rackdiag tool (http://blockdiag.com/en/nwdiag/rackdiag-examples.html).

[CDSoft]

pp will soon support blockdiag, seqdiag, actdiag, nwdiag, rackdiag and packetdiag.

[rolandog]

Could there also be some detection of the Python 3 (py3) version of BlockDiag (blockdiag3)? I'm not too versed in Haskell to implement this but---for now---my work around was to create a soft link:

sudo ln -s /usr/bin/blockdiag3 /usr/bin/blockdiag

To help anyone Googling this, here was the error message I received:

pp: Error while executing blockdiag -a -Tsvg -o images/pp-blockdiag-example.svg images/pp-blockdiag-example.diag: blockdiag: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory)

[CDSoft]

pp is not very flexible, command lines are hardcoded. I'm testing Pandoc filters (see https://github.com/CDSoft/abp). It uses Pandoc AST and is not bound to a specific syntax. Diagrams (as well as scripts) can be rendered with any command (some are predefined).

[tajmone]

I'm testing Pandoc filters (see https://github.com/CDSoft/abp). It uses Pandoc AST and is not bound to a specific syntax.

This seems promising, although still WIP right now.

[cpkio]

Blockdiag directive behaviour is inconsistent with graphwiz directive behaviour.

For Graphwiz you should write:

!dot(scheme-01.svg)(Scheme)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
digraph {
   ministry;
   financial;
   institution;
   contractor;
   subcontractor;
   ministry -> institution -> contractor -> subcontractor;
   contractor, subcontractor -> financial;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and this will generate the same content scheme-01.dot in current folder.

But, for blockdiag support, if you write this:

!blockdiag(block-01.svg)(Block)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
blockdiag {
  Kroki -> generates -> "Block diagrams";
  Kroki -> is -> "very easy!";

  Kroki [color = "greenyellow"];
  "Block diagrams" [color = "pink"];
  "very easy!" [color = "orange"];
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

the content of resulting block-01.diag will be this:

blockdiag {
blockdiag {
  Kroki -> generates -> "Block diagrams";
  Kroki -> is -> "very easy!";

  Kroki [color = "greenyellow"];
  "Block diagrams" [color = "pink"];
  "very easy!" [color = "orange"];
}

}

Obviously, to get blockdiag directive working straight, you should write without blockdiag opening directive:

!blockdiag(block-01.svg)(Block)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Kroki -> generates -> "Block diagrams";
  Kroki -> is -> "very easy!";

  Kroki [color = "greenyellow"];
  "Block diagrams" [color = "pink"];
  "very easy!" [color = "orange"];
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

which is inconsistent behaviour. I personally prefer first variant, where the diagram code is pasted as-is with an opening directive and does not need any further editing.

This has been tested on 2.13.1.

[CDSoft]

I agree. This inconsistency is very old and also concerns plantuml. Some softwares always use the same header, some not. Changing this now would break existing documents. abp has a better approach. The command for scripts and diagrams can be fully defined by the user, some are predefined. And the content of the block is given as-is to the external command.

[tajmone]

I've just come across Kroki which seems to offer a unified solution for a moltitude of diagrams syntaxes.

Could PP switch to Kroki in the future? And would that break significantly backward compatibility?

[CDSoft]

Kroki is a web service, this means each diagram requires a connection. This may make the rendering process longer and unstable. And the API may change while locally installed tools are versioned.

[CDSoft]

Sorry for the late reply... Please keep in mind that pp is not supported anymore, it's hard to deploy. For new projects I suggest ypp which is is based on a Lua interpreter and way easier to compile and install and binaries are easier to produce (thanks to zig) and deploy (see hey).

ypp image generation is inspired by app.