Any C or C++ alternative implementation for the ASCII parser?

[cesss]

The functionality in this project is just what I need, but, unfortunately, I cannot use Python. However, I'm only interested in the parser (i.e.: reading the ASCII art and translating it into a graphics description in memory). OTOH, the backend is less important in my use, as I'll quite likely be writing my own.

I tried to understand the source code for the ASCII art parser, hoping that I could reimplement it in C/C++ (the languages I use), but I wasn't able to understand the places where shaape supposedly detects lines, connectors, closed contours, etc...

Do you happen to have a C/C++ version of the parser, even if it's incomplete? Or do you know of any C/C++ project that also converts ASCII art into vector graphics? (I searched, but I only found Java, Haskell, and PHP projects that do this, and, BTW, your project seems to be more powerful and complete than these other ones)

[christiangoltz]

Hi and sorry it took me some time to answer this ;) I don't know of any C/C++ version of a similar tool and don't have one myself. The shortcomings of other solutions have been the reason why I did this project. Funny thing is, if I read the code today I realize the especially the parser is written in an not understandable way, so that even for me it is hard to exactly understand what I was doing some years ago. However, I can give you the rough idea about what shaape does real different than most of the other tools.

Parser in shaape means "converting text to graphs and other stuff". I split up the parsers into different tasks. The most interesting one for you should be the overlayparser. At the beginning of that file you can see one of the core parts that you have to understand, the sub overlays. One sub overlay is basically a mapping of one or more connected characters to a graph. Easy examples include '-' which is mapped to a simple edge from left to right. More complex examples include down arrows for example, which look like this ['|'],['v'] and are converted to a line from top to bottom.

The parser hands over all these sub overlays into the substitutes function of overlay.py, which then searches for the patterns of the sub overlay starting with an empty result graph. If it finds one of the text patterns, it takes the graph that was defined for the according sub overlay and appends it to it's result graph. The appending happens relative to the position of the found text match and new edges are connected to existing nodes if possible.

In the end you get a graph out of this (which is not necessarily connected). This graph is easy to render with any method. The rest of the features are basically

• finding all connected graphs inside the overall graph (this is standard math) and then finding all closed polygons in these graphs (didn't find anything with usable runtime, so I wrote this graphalgorithms.py with the planar_cycles function for that, but theory behind that was also standard as I can remember, had something to do with that you need to find all planar chord free cycles in a graph)
• z-ordering the connected graphs by checking if polygons are inside other polygons
• parsing text and converting it into text objects
• parsing arrows and converting the to cairo drawable objects
• parsing styles and connecting the to the polygons found before

I needed to fine tune the cycle-finding a lot and I am quite sure that it is not math correct anymore and probably this is the only part that is not so easy to rewrite by just looking at the code because there is a long undocumented thought process behind it. If you are good in graph theory however this should be easy to rewrite.

[cesss]

Thanks a lot for explaining it! Considering what you mention about the cycle-finding needing study (and having a long undocumented reasoning behind), maybe my best bet would be to start from scratch rather than trying to port your code.