Because this is a lot already. The class TRRotatedLabelShape is complex. It is not _just_ applying a rotation matrix. We also need to have the encompassing rectangle, which is needed by the layouts. We also need the bounding box, for checking the point inclusion (i.e., is your mouse above the text?) I haven’t done any benchmark, but I suspect the rotated label to be slower than the non-rotated label. But indeed, the shape of hierarchy will surely evolve over the time. Having rotated labels is just a (minor but important) milestone that we wanted to share with you. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

to have rotated labels :-) Actually no. Having rotated labels can be considered as a primitive for data visualization. DSM, GraphET need rotated labels. I see Roassal as an abstract for data visualization. Not really as a better API than Athens. Neither as an alternative. Athens works very well, and the API is relatively clean. Yesterday with Ben we had exactly that discussion. Why not exposing the notion of matrix, like that I can rotate anything? That is a very good point, and we will probably offer such a thing on some point. But the problem with matrixes is that they are highly complicated. Finding the right combination between translation and rotation is always a long set of try-and-see-what-we-get. Yes, it is a prototype. It will probably evolve over the time. Maybe we will not keep RotatedLabel at the end, but merge it with Label. One some point, we will introduce a hierarchy for transformation. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.