Fossil Forum
Post: pikchr: "chop" is unreliable for ellipses at some angles
In this example if we set the angle of the "heading" property between [82,98] or [262,278] then line are not correctly "chopped" and go inside the ellipse in the center. The bug also depends of the size of the "gravitating" ellipse, the bug does not appear when the text is two-character long for example.
E1: ellipse "very long ellipse" fit
# For all the following ellipses, the "chop" for the line is OK if the text
# is two-character long.
E2: ellipse "082" fit at 1 heading 82 from E1
line from E1 to E2 chop
E3: ellipse "098" fit at 1 heading 98 from E1
line from E1 to E3 chop
E4: ellipse "262" fit at 1 heading 262 from E1
line from E1 to E4 chop
E5: ellipse "278" fit at 1 heading 278 from E1
line from E1 to E5 chop
# For all the following ellipses, the "chop" is OK because they are outside the
# problematic angles
E6: ellipse "045" fit at 1 heading 45 from E1
line from E1 to E6 chop
E7: ellipse "235" fit at 1 heading 235 from E1
line from E1 to E7 chop
It isn't the angle, it's the distance. Change those 1's to 1.1 and its fine
E1: ellipse "very long ellipse" fit
# For all the following ellipses, the "chop" for the line is OK if the text
# is two-character long.
E2: ellipse "082" fit at 1.1 heading 82 from E1
line from E1 to E2 chop
I suspect the story is that pikchr is supposed to be simple and lightweight. It doesn't actually know exactly where the ellipses are actually drawn, so it is using some approximation. It is also presumably using some minimum length for the line, so if you get too close it takes the line to the centre (i.e. ignores the 'chop').
Put another way, pikchr is deciding whether it is sensible to tell the renderer to do the chop, in the same way that it adds a bit of space around text when you say 'fit', rather than end up with a diagram where the rendering goes wrong.