Thanks for the bug report.

The error seems to arise because the center of C6 is exactly the same as the center of the big blue box. This gets the chopper confused such that it is chopping the line to the edge of the big blue box rather than to the edge of C6. Here is a simpler test case (click on the diagram to toggle between the diagram and the Pikchr source text):

circle "C0"
move
circle "C1"
box at C0.c width 8cm height 2.5cm
arrow from C0 to C1 chop color red

Working on a fix now. Stay tuned....

A partial fix is in check-in 6210a902d508c4b9. The severity of the problem is reduced, and the test cases shown in the posts above now render correctly. However, the problem is not completely resolved. Consider the following diagram:

circle "C0"
move
circle "C1"
B2: box at C0.c width 2.5cm height 2.5cm
text "B2" with .n at B2.n
arrow from C0 to C1 chop color red

The red arrow is suppose to go from C0 to C1 with chop. (Click the diagram to toggle between the source text.) But instead of truncating to C0, it truncates to the box B2.

This problem again arises from the fact that C0 and B2 have the same center. When it comes time to process the "chop", the arrow only knows about the coordinates of its path. It does not know that it is suppose to go from C0 to C1. So the chop algorithm searches for an objects centered at the starting and ending point of the arrow in order to chop at those objects. But because B2 and C0 have the same center, the search finds B2 and uses it to chop, rather than C0.

This is an important problem of the implementation. The symbol "C0" has already been translated into a coordinate pair by the time it is handed to the arrow object. The arrow never has an opportunity to know that it originated at C0 rather than B2. Some major structural changes to the code might be required to resolve this situation.

The fix in check-in 6210a902d508c4b9 is a simple change to the chopper such that when searching for an object to do the chopping, it ignores objects whose bounding box enclose the second point along the line that is to be chopped. That is probably an important improvement to the chopper, and should likely be retained even after a more general solution to the chop problem is found. But it is not itself the general solution.

Here is a better test case for the remaining problem:

circle "C0" fit color blue
C1: circle at C0 radius 2.5*C0.radius color red
text "C1" with .n at C1.n color red
circle "X1" at 8*C0.radius heading 60 from C0 fit color blue
circle "X2" at 8*C0.radius heading 80 from C0 fit color red
circle "X3" at 8*C0.radius heading 100 from C0 fit color blue
circle "X4" at 8*C0.radius heading 120 from C0 fit color red
arrow color blue from C0 to X1 chop
arrow color red from C1 to X2 chop
arrow color blue from X3 to C0 chop
arrow color red from X4 to C1 chop

The arrows are all generated using "chop". The blue arrows should connect the blue circles and the red arrows should connect the red circles. If you are looking at this before the problem is fixed, you'll see that all arrows connect to C1, regardless of color.

As of check-in 2090a12c76d960e1 all issues with "chop" should now be resolved.