org-babel support for plantuml, dia, graphiviz and dot for example

[timoc]

Hi,

I would like to see pandoc support org-babel. Two features i would like to see are:

• untangling - to use Pandoc and org-babel without emacs for literate programming. Preferably with tag support.
• source processing. I use org-babel #+begin_src and #+end_src with plantuml to generate UML images to embed in the document, I would like pandoc to support this, and Dia for diagrams, graphviz and dot for graphs etc. So i do not need to version control the artifacts, but just the source.

[tarleb]

This is related to #656. I wholeheartedly agree, this would be nice to have. It's a bit out of scope as far as Pandoc is concerned. One could probably hack something together using either a pandoc filter, panflute, a custom writer, or a separate tool altogether.

There is also the now defunct rundoc project, which I started a few years ago and which never made it past the good-intentions stage. The main reason for this is that babel is just so powerful and complex that it's difficult to get even remotely close. So I rather focused on improving the org reader instead.

If you find or hack something suitable, please do let us know.

[timoc]

I'm not necessarily talking about a full babel implementation processing the output and re-processing it in pandoc, or anything so drastic rather making pandoc both a pre-and post processor, so that say in a script i can:

# export babel src output for external processing.
pandoc --from babel --to src MAKEME.org -o makeme/
# choose the plantuml from the exported source and generate images for document
for plant in makeme/*.plantuml; do 
    plantuml $plant ./$plant.png
done;
# process org document to PDF - now with updated generated images
pandoc --from org --to pdf MAKEME.org -o makeme.pdf

I don't do haskel, so no help from me here, but it would need some measure of exclude/nonexclude support even if it is tags in the exported filename.

[tarleb]

Like I said, it is an important idea which could benefit many people, but it is out of scope for pandoc. If you know python, using the aforementioned panflute is probably the best choice for now. Otherwise you could also re-raise the issue at rundoc.