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:
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 postscript
dot -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
attribute works, I hope to use it to debug.
I have tried to modify routespl.c to output the information of boxes before the printboxes method is executed, like the following:
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.
If the polygons are outside the SVG viewBox, they will not be displayed. This is definitely possible, see also notranslate | Graphviz (neato only).
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.
Share it, make a specified position offset for the vertices of the box, and get the debug boxes display
OK, now I guess I will have to read the underlying documentation.
Impressive. We would like to isolate the box path for a particular bad spline, like this example: Pointy edges in places where straight edges fit
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.