I use this not infrequently when producing documentation. But it's one of those things which is most of the time ok, but when it's not it's very dissatisfying, and I don't have a concise term for the (common) source of that dissatisfaction. When it produces a poor layout, you have to either abandon the tool completely for that use case, or you have to use an entirely different tool set to fix the output (like just editing the SVG).

I think this is a bit challenging, because if you're hand-writing the structure describing the diagram, you likely have some preconception of what it should look like, but the language doesn't give you a real mechanism to express that. And because the diagram is meant to be _looked_ at, the author's preconceptions may actually be quite relevant in how effective the diagram is at communicating content to a later reader. This is in contrast to a compiler, where the author may disagree with the specifics of the output, but so long as it _runs_ to produce correct behavior, the author should not complain too much (i.e. the primary "audience" is the platform which will execute the program).

As an example, only this past weekend, I tried to produce a diagram about an HMM-style graphical model, where nodes occur in sequence in a few parallel families. I had hoped that because of the regular structure of the links, the layout would reflect that regularity. But instead, nodes of each type were sort of all over the place, and the regular structure was actually not immediately visible in the diagram.