[ANN][WIP] Go port of DITAA ("DIagrams Through Ascii Art")

[Mateusz Czapliński]

"ditaa is a small command-line utility that can convert diagrams drawn using ascii art ('drawings' that contain characters that resemble lines like | / - ), into proper bitmap graphics."

This Go port is still work in progress, but I brought it to the point where I can show some advanced visuals. So, in case anyone was interested and/or wanted to help fixing the remaining differences:
a visual side-by-side table comparing the current Go port results to the Java original is available at:
  http://akavel.github.io/ditaa/
and the sources of the port live at:
  https://github.com/akavel/ditaa

Notes:
- the codebase is absolutely *non-idiomatic* at the moment! this is more or less "port the Java codebase function-by-function", with only some coding style tweaks when muse struck me;
- I use freetype-go for drawing, and it doesn't support dashed lines, so that's probably not coming soon, as I'm not aware too well how to do this at the moment;
- the license is GPL v2 (2+? not sure, must verify); the original DITAA switched to GPL v3 recently, but I forked from v2 (from the codebase before that switch);
- some specific features not supported yet at a glance: colors, tags (shapes), dashed lines, commandline options, point markers, other output formats (png-only for now);
- features supported at a glance: boxes, lines, text, arrows, drop-shadows;
- I keep the Java sources (slightly modified) in orig-java/ subdirectory; specifically, I introduced an intermediary XML format (for diagram description, just before rendering) both in the Java and Go codebases.

The original DITAA has its homepage at:
  http://ditaa.sourceforge.net/
and the Java sources from the original author live at:
  https://github.com/stathissideris/ditaa

Cheers,
/Mateusz.

[Egon]

On Wednesday, 8 April 2015 02:08:29 UTC+3, Mateusz Czapliński wrote:

"ditaa is a small command-line utility that can convert diagrams drawn using ascii art ('drawings' that contain characters that resemble lines like | / - ), into proper bitmap graphics."

Why not write to svg instead of png? Was it just because it was just a translation?

Once you have the graphical model you should be able to directly create a svg quite trivially without all the image rendering. With SVG you get all the dashes & colors for free. Also, all major browsers support svg (http://caniuse.com/#feat=svg). Of course, there might be some problems I'm not aware of.

+ Egon

[Dan Kortschak]

On Wed, 2015-04-08 at 00:32 -0700, Egon wrote:
> Why not write to svg instead of png? Was it just because it was just a
> translation?
>
> Once you have the graphical model you should be able to directly
> create a svg quite trivially without all the image rendering. With SVG
> you get all the dashes & colors for free. Also, all major browsers

> support svg (http://caniuse.com/#feat=svg). *Of course, there might be
> some problems I'm not aware of.*

Or draw to github.com/gonum/plot/vg where the backend is then plugable.

[Mateusz Czapliński]

On Wednesday, April 8, 2015 at 9:32:20 AM UTC+2, Egon wrote:

On Wednesday, 8 April 2015 02:08:29 UTC+3, Mateusz Czapliński wrote:

"ditaa is a small command-line utility that can convert diagrams drawn using ascii art ('drawings' that contain characters that resemble lines like | / - ), into proper bitmap graphics."

Why not write to svg instead of png? Was it just because it was just a translation?

[...] With SVG you get all the dashes & colors for free. Also, all major browsers support svg (http://caniuse.com/#feat=svg). Of course, there might be some problems I'm not aware of.

Why write to svg instead of png?
Also, I'm more interested in PNG because of various reasons. PNGs I can render on any bitmap surface, especially with Go's decoder. SVGs render only in "all major browsers". Um, more like: "modern" browsers/versions. Aaand, I strongly suppose that not without some weird quirks, etc, similarly to HTML, JS, etc. No? Now, AFAIK PNGs do render on all modern major browsers too. They also render on old browsers. They may even render on non-major browsers. And, a plus: they may easily render on *non-browsers* too. Like, desktop apps, or similar weird stuff. I'm not a very browser guy.

Once you have the graphical model you should be able to directly create a svg quite trivially without all the image rendering.

Yes. That too. I could even have SVG rendering living happily along the currently available bitmap rendering. What a happy coincidence that I do have a graphical model (as mentioned).

By the way, if you're interested in having SVG output, you're more than welcome to contribute an SVG renderer to the project!

Cheers,
/Mateusz.

[Mateusz Czapliński]

On Wednesday, April 8, 2015 at 10:33:47 AM UTC+2, kortschak wrote:

Or draw to github.com/gonum/plot/vg where the backend is then plugable.

I don't suppose it has a bitmap backend supporting dashed cubic curves?

/M.

[Dan Kortschak]

The bitmap backend is code.google.com/p/draw2d. I think it might, though we don't make use of it in vg AFAIK.

[Sean Russell]

Hi,

First, thanks for this. I've been a huge fan of ditaa for a while, but not the Java dependency.

On Wednesday, April 8, 2015 at 3:08:51 PM UTC-4, Mateusz Czapliński wrote:

...

Why write to svg instead of png?

One reason is that the output is quintessentially vector data, and SVG is a vector format, and PNG is not.  Scaling and rendering for different outputs doesn't have to require reprocessing.

Another reason is because SVG is fairly easy to modify, with quality results and relatively low cost of entry.  Changing colors can be easily done with CSS, for instance.

A final reason is that it is (again) relatively easy to convert SVG to a bitmap format; going the other direction is less easy, especially if you want to retain text-as-text.

Feel free to replace "SVG" with any vector graphic format, although amongst other popular vector formats SVG is comparatively easy to manipulate.

 

SVGs render only in "all major browsers". Um, more like: "modern" browsers/versions.

This is mostly true, although "modern" includes versions going back, what, almost a decade?  Except for IE, of course -- that was a latecomer.

 

Aaand, I strongly suppose that not without some weird quirks, etc, similarly to HTML, JS, etc. No?

Yes, bot as much as you'd expect.  Even IE supports gaussian blur; SVG does really give you some sophisticated rendering tools for really, really cheap -- mitering, decent text handling (although getting good cross-browser consistency does require some care and effort), nice line effects, the aforementioned gaussian blur.

Now, AFAIK PNGs do render on all modern major browsers too. They also render on old browsers. They may even render on non-major browsers. And, a plus: they may easily render on *non-browsers* too. Like, desktop apps, or similar weird stuff. I'm not a very browser guy.

If your main target is bitmap, obviously you're scratching your itch and that's great.  Although it adds a step, you can easily get from SVG to bitmap with rsvg-convert (from the librsvg toolset) will generate PNG, as well as PDF and PS, in your preferred dimensions and at your preferred DPI.

 

By the way, if you're interested in having SVG output, you're more than welcome to contribute an SVG renderer to the project!

I hear you. Is it your intention to keep the code base the way it is (as you described, non-idiomatic), or do you have plans to drift from the upstream structure?

Incidentally, have you encountered Shaape?  If you like ditaa, you may find some of the features of Shaape compelling.

--- SER

[ajstarks]

Speaking of Go, SVG, and diagrams, there's SVGo [1] and compx [2]

[1] https://github.com/ajstarks/svgo

[2] https://github.com/ajstarks/svgo/tree/master/compx

[Sean Russell]

On Wednesday, April 8, 2015 at 11:31:36 PM UTC-4, ajstarks wrote:

Speaking of Go, SVG, and diagrams, there's SVGo [1] and compx [2]

[1] https://github.com/ajstarks/svgo

And thanks for that, AJ.  I use svgo regularly.

--- SER