I like to use http://www.graphviz.org/ to convert from DOT to PNG.
&s=napkin for yourself.
&s=omegapple for management.
Not the greatest samples on there though - better resources on http://plantuml.com/.
Maybe it'd make more sense to just have one of these tools implement export to ACSII?
Having this ASCII -> image converter also allows me to embed diagrams into blogposts as text without actually making images out of them. See  as an example of such embedding.
It may seem "cute" or "toyish", but I woudl try to use it before giving an opinion. I certainly did that with markdown and ended up moving a lot of docs to that format, right in the repos with the code.
But doesn't that still apply if you had a visual tool exporting to ASCII? It'd save you the difficulty of moving sections around in a text editor, but give you the visual diff.
If your visual tool merely exports to ASCII, this won't work. If it stores its data in ASCII, it might. But it needs to be more than just "doesn't use control characters and non-7-bit characters" — it needs to have reasonably short lines that mostly don't reoccur and whose position, if meaningful at all, is meaningful only relative to the position of other nearby things, rather than by absolute line number or byte position or something.
Even then there'd be issues, as e.g. I might want to modify descriptions elsewhere in the file in between modifying the diagram. As a concrete example, I am doing that these days with a spec for a system I'm planning. I'm using a custom Markdown based processor with a filter that takes Graphviz/dot syntax inline, and while I edit the diagram, I'll also then often want to write something about what I've added to it. So if I was going to use an external program, the roundtrip from text editor -> diagram editor -> text editor would need to be very fast and smooth.
Though to be really useful for me, it'd need to work for me via an ssh connection as well...
It's really hard to beat plain text for some of these use-cases. At least without first getting more graphics capabilities back into our terminals.
Right now I'm using SVG for that, but it's kinda rotten.
If it's the second, you can embed XML within SVG or a PNG. If you draw something simple in draw.io  (which I do co-author) and then "File->Export As" either "SVG with XML" or "PNG with XML" the diagram data is stored within the display format itself. This way you can just reload the SVG+XML or PNG+XML and carry on editing. But the PNG and SVG display as you'd normally expect.
Does that solve your problem?
GNU pic can target LaTeX directly, if that helps.
Personally, I build most of my diagrams in either graphviz or LaTeX/TikZ. Graphviz constructs certain types of diagrams very quickly, as long as you don't care deeply about precise placement and layout. And TikZ integrates perfectly with LaTeX documents, and makes complex diagrams and graphs more manageable and scriptable.
Ideally I want a visual editor with an abstract understanding of what you can do in diagrams, a keyboard driven interface and automation of a good first approximation of what I want, giving me the ability to tweak the resulting layout.
Drawing diagrams on a piece of paper or a whiteboard beats both approaches handily. Which is pretty sad.
Agreed. I think what is more helpful is taking a shorthand version of a diagram and generate it into a graph (flowchart.js is an example of this).
Just tried it out and the export->copy->paste->save worked really, really well.
Are you aware of anything that is a local client?
Looks something like this: http://wiki.cornempire.net/_media/asciiart/diagram1.png
sudo apt-get install asciio
When I see something like this part of me always silently wonders 'if you think these handwritten-style fonts are so cool, why didn't you write your whole Readme in the same font? Probably because deep down, you know it's actually hard to read, so why make your diagrams hard to read?'
But creating pretty diagrams with Graphviz/dot is an exercise in pain.
I love seeing more of these tools, and plan to integrate several of them in the scripts I use to build my blog, not to supplant the cases where I use Graphviz, but to augment them for the many situations where I want to do diagrams that need more precise control than Graphviz does.
(My personal Graphviz self-flagellation exercise involves an XSL file to convert the SVG output from dot to something prettier: https://github.com/vidarh/diagram-tools )
That said, just like Graphviz, its weak points is "messy" diagrams. But it supports subgraphs, which can help making them cleaner.
I think Graphviz really needs a better routing algorithm - with many vertices and edges the result starts looking like a mass of tangled hair. Something closer to the routing algorithms used in PCB design would be far more readable.
I can beat that - I had an ASP.Net application that queried a set of SharePoint lists to generate 100s of diagrams giving details of what applications were used for different business processes at each site in a large multinational.
It did work but there was a lot of tweaking of the process to create the dot files....
| | | | | /|
| | | | | / |
| * | *--+--+> * | / |
| | | | | | | / |
| | | | | | |/ |
At its heart, graphviz is great. But the tools so need a nice little modernizing.
At the basic level, I found myself being very repetitive because its not possible for graphviz nodes to inherit attributes from others etc. No CSS kind of hierarchy.
I only found two bugs:
1) if you type just something small, like "asdf", it doesn't render. It seems to require you to start with a long horizontal line to make it properly calculate the width.
2) this one is understandable, but, if you want to write code that decrements something, e.g. x--, it renders the -- as horizontal line instead.
Edit: Oh, you have to edit the field for it to actually render it, okay. That wasn't obvious.