[vinodkd]

I agree, and you can see this even with "simple" diagrams. For example, the Pikchr examples page[1] has a SQLite architecture diagram, and if you click through to the source (like the idea of "click to see source" btw), you'll find lines like this:

    line invis from 0.25*$margin east of last.sw up last.ht \
       "Backend" italic aligned

...which is an invible line used to create a label for the box that's vertically aligned. This is the kind of "toil" that adds up to what you describe. Ideally, this should be a feature of the language itself, something like

    box "label" valigned nw

but you cannot anticipate every bit of adjustment users would need to produce a visually appealing image, since that's subjective.

PIC has macros[2] that somewhat make this easier, but as things get larger you'd still have the issues you mention, and you're trading one complexity (hand drawing visually appealing picture) for another (maintaining more complicated code for local visual appeal). I dont know if pikchr supports macros (which are more like functions since troff is a full fledged language, and less like svg symbols afaict)

1: https://pikchr.org/home/doc/trunk/doc/examples.md 2: http://floppsie.comp.glam.ac.uk/Glamorgan/gaius/web/pic-14.h...

[SQLite]

Pikchr author here

It is difficult to find the right balance between a simple language that requires "toil" and a less toilsome language that is also more complex and requires more effort to learn and master. I'm very open to new ideas of how to make the Pikchr language less toilsome without a corresponding increase in complexity. Expect improvements to occur. Your suggestions are welcomed

I envision Pikchr operating in the same nitch as Markdown. (Indeed, Pikchr was originally designed to augment Markdown-based documentation.) An artificial language like PIC/Pikchr is always going to have a steeper learning curve than a GUI diagram drawing tool, just as Markdown documents are always going to be a barrier to entry for pointy-clicky people who prefer MS-Word or Google-Docs. And yet, Markdown persists and even flourishes. Why is that? If point-and-click really is so much better, why are there so many Markdown technical documents out there?

A key advantage of Markdown, which helps it thrive in a point-and-click world, is that it is very simple to learn and requires no proprietary tools. Pikchr is not as simple, though it is simpler (I think) than any other artificial language for graphics that I have encountered, and I've tried to make the Pikchr code as accessible and as easy to integrate as I know how. I'm on a mission to make Pikchr simpler still. Your feedback on how to do that is appreciated.

[vinodkd]

Thanks for responding. Actually, I dont think Pikchr needs to have more features. "Toil" should tell people that they should use a different tool, IMO, so that Pikchr is used for the intended purpose - small diagrams to go with Markdown documentation.

The parallel to Markdown is apt, since it too does not do everything HTML does, and that's good (tm). The use of "same" and "last" also forces a locality that would be lost if the diagram were large.

I gave an example of a box syntax that allowed defining a label aligned vertically, but I did so to illustrate that while such an extension could be done, the library author could not possibly imagine all such attributes that users might want.

The default answer to this is an extension mechanism, i.e, you allow users to create their own primitives, but that might be overkill for the pikchr use case, and would possibly require going past the "single pass through lemon produces a c file that can be integrated into any c project" model.

The other idea - stolen from Markdown - would be to "fall through" to SVG at will by allowing svg syntax as also being valid in pikchr, but I dont know that SVG is as forgiving as HTML to do that.

[archagon]

When I have time, I'd like to create a markup language for diagrams that's paired with a GUI app. You'd define your diagram through text (just the structure without any stylistic elements), then use the app to tweak the style for the generated diagram as needed, e.g. change positions, adjust sizes, align elements, etc. The visual portion would be stored in a separate part of the document, possibly as a delta from the default style, and nothing would break if the graph portion was tweaked. Particular emphasis would be placed on editability of the graph contents. (For example, adding new elements or tweaking the text should not break the diagram.) We'd need a comprehensive, higher-level set of visual rules that aren't just "position of box A should be (122,34)". Maybe something like Apple's Autolayout would be a good fit here.

I've generated plenty of diagrams in Graphviz where everything was great except for a poorly-placed node or two, and I think this sort of two-part solution could provide the best of both worlds. (Or, at least, it would be a fun R&D project.)

[vinodkd]

Did you know that Graphviz can also output its own dot format, but that the output contains layout information? That might help you get started with the 2nd part. There's also an extended dot[1] format with more information

1: https://www.graphviz.org/doc/info/output.html#d:xdot