Interesting interactions between objects and renderers

[Lars Clausen <lrclause cs uiuc edu>]

I've been thinking some more about how to do the arrows and other
transformations right (I did get the arrows to point exactly at the
connection point).  It turns out to be not as easy as I hoped, and here's
why:

When a line gets an arrow at the end, the endpoint of the line should be
moved backwards at least to the backside of the arrow, possibly to the
backside of the stem, if such is used.  I did this in the renderer, and it
worked well.  There were some problems with it though:

1) Non-straight lines (arc & bezier) are suddenly rendered at a different
   place than where they're checked for mouse clicking.  To move a bezier
   with an arrow, I head to click outside the line.  So whatever checks for
   mouse clicks will have to know about the transformation, and ought to
   also include the arrowhead in the clickable area (though that may be
   overkill).
2) The translation is the endpoint is not trivial.  There may be a better
   way, but currently it involves cos() and atan() calls, not very fast.
   Caching will be essential.
3) We can't just move the actual endpoint of the line, as some renderers
   (xfig, pstricks?) will want to render the line as 'line with arrow'
   rather than 'line' and 'arrowhead'.  They would want to know the
   original points.

When looking further ahead, there are more translations we may want to do:
Scaling and rotation, at least.  These can be done as matrix operations,
though some renderers (PS, for instance) would be able to do them by
dumping the matrix directly and then render with the original points.  
A problem with matrix operations is that FreeType would want the scaling
and rotation to be input in separate places.

The arc object is a special problem, as it doesn't actually give the
endpoints to the renderer, but a center, a radius and two angles.  Figuring
out how to move the endpoint would basically require recomputing the points
from the other info, and then recompute the other info from those points.
The alternative would be to change the arc drawing routines to take points
instead and calculate angles in the renderer (possibly caching).  We could
add new functions to do this, if compatibility is an issue.

I'm not sure how to tackle this.  I was thinking for a while a system of
adding functions to do translations, with caching.  However, both the mouse
click problem and support for more advanced renderers get in the way.
We could do the arrow stuff in an ad-hoc manner, but we would still need an
infrastructure for rotation, at the very least (and generic scaling would
be much appreciated, too, both for shapes that don't allow scaling and for
scaling line widths correctly).  

Any ideas are welcome!

And no, the prettier arrows are not in general use yet.  I'm keeping the
code around, but not using it until the above problems are solved.

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?