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? _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
