According to my understanding, the box is used as an obstacle when drawing the edge, and the line segment is continuously divided to avoid passing through the box.
showboxes introduces the shoeboxes attribute, but I don’t know how to display these boxes through the description of the documentation.
I tried to do it as follows, but don’t know how to combine it with PostScript:
digraph {
showboxes=2
a->b
a->c
}
then i user the commond dot -v -Tsvg test.dot > test.svg, but I can’t see any changes, so what should I do next? Is there any additional dependencies that need to be added to the computer? What is the complete debug process?
showboxes is only supposed to do anything when output format is postscriptdot -Tps test.dot >test.ps. Then either print test.ps to a postscript printer, convert test.ps to some other file format, or display test.ps with a postscript emulator (like ghostscript). It is for debugging, but the documentation does not indicate if this is for Graphviz developer debugging or user debugging.
When I tried using it, I saw no result. A quick read of the source provided no enlightenment.
What problem are you trying to solve? I don’t think showboxes is going to help, but maybe we can suggest another approach.
It was really a hack, in the classic sense of the word, when we made it. I don’t believe it works any more. I think what we should do, is append the spline control polygon or boxpath to the current spline and just generate it with the rest of the graphics code. I’m sorry that a few things in graphviz were just something we did without thinking very hard in a few minutes after coming back from lunch in the Murray Hill cafeteria in 1996, and they’re hard to defend now.
Should we be resurrecting (or removing) showboxes? I noticed the code was a little incautious (unchecked allocations, memory leaks, …), but left it alone as I thought it was only meant for developer debugging.
I tried to use Java to implement a graphviz-like effect, which is still under development and has not been open sourced yet graph-support.
In my implementation, when I use virtual boxes to route, I can’t achieve smoothness like graphviz, and the effect of each line does not affect each other.Please see the example below:
In particular, when the edge has a label, I treat the label as a “virtual vertex”, like the virtual vertex inserted when the edge spans more than 1 rank, so that the rest of the lines and vertices avoid the label. In this way, the problem mentioned above will become more serious, and the label will make the line segment more curved. The following is my implementation compared to the graph generated by graphviz:
It can be clearly seen that for graphviz, the boxes added according to the virtual vertices can separate the curves well, and make the line segments avoid bending. I believe this is related to the strategy of “placement” of boxes, so I want graphviz to output boxes, See how it makes sense to place the “boxes”,if the shoeboxes attribute works, I hope to use it to debug.
But I pasted the boxes printed by the console into the svg, but nothing was displayed, as if the coordinates of the boxes were beyond the current svg visual range.
So after using polygons to draw the line, the control points of the node and the line segment will be moved as a whole, so the printed boxes information is beyond the scope of the viewBox?
I am not sure if it is common for some or all of the engines to first produce a layout in non-positive direction and then translate, but I believe it sometimes happens.
Look at your stderr SVG code and compare the coordinates with the coordinates of the Graphviz-generated SVG. Do they share the same X/Y space?
You are right, graphviz will move the nodes in the graph as a whole. Using the following test graph, I printed the coordinates of the nodes before generating the boxes.
The abscissas of the corresponding three points are -36 , 0, 36, and the final generated SVG is 27, 63, 99, because the visible range of the viewBox must be greater than 0, and the width of the ellipse is exactly 27, so the center node is at least 27 to ensure the complete display of the graphics.
So I know why the boxes I print out cannot be displayed, because the coordinates of these boxes need to be shifted by an offset as a whole to ensure that they appear in the visible range of the SVG.
I think showboxes here is rendering the box space actually used, after splines have been calculated and unused space has been recovered for potential use in other splines. The documentation says we can use showboxes=1 for pre-route boxes and showboxes=2 for post-route boxes. Does this still work?
I don’t know how this property takes effect, but looking at the code, the points that enter the boxes of printboxes are deviated under svg, but I am not sure if it is under Post Script, because I have not used it successfully.
Based on a few experiments, showboxes can be made to work - sometimes.
Define the C-macro variable DEBUG and (re)build the package (or at least dot)
Add the showboxes attribute to the graph, node, or edge
Hope for the best - sometimes it seems to work and sometimes dot coredumps. (see Matt’s comments about "incautious " above)
p.s. DEBUG seems to break other code.
Rather than trying to fix the current code, here are two other alternatives to “rework” the showboxes attribute. Both would be independent of Postscript, or any specific format.
Add nodes and/or rectangular edges to the graph to show spline control points and/or spline routing paths. This should not be too difficult, but the actual adding to the graph should probably be done after all the routing is complete - so the new nodes/edges don’t mess up the works.
Instead of actually adding nodes or edges, define new attributes to carry the needed info about box pos, width, and height and let a post-processor do the work to add the boxes. While the syntax of defining multiple boxes per edge would be somewhat messy, it has been done for other attributes. e.g. _showb=“ll,ur:ll,ur:ll,ur” (or equivalent).
The best approach would be to enhance the code generator to show the spline constraint polygons (box paths) in a renderer-independent fashion. When we wrote showboxes it was a quick, not well-considered hack, when -Tps was literally the only working code generator. It was just something that could be done in a few minutes to debug some other problem, not meant to be in use over 20 years later.
