Arjen MarkusDimitrios ZachariadisDonal K. Fellows$Revision: 1.5 $Tk canvas

This TIP proposes to add a rotate subcommand to the canvas widget to facilitate rotating items in very much the same way as is now possible with scaling and moving.

The canvas currently allows a programmer to scale and move items, but the third common affine transformation, rotation, is not supported. This can in itself be simulated by a script (simply get the coordinates of all items involved, transform them and set the new coordinates), but if you have several hundreds or even thousands of items this gets very slow. Rotation is easy for polygons and lines: simply transform the coordinates. For circles and circular arcs new bounding boxes must be calculated and in addition for arcs the starting angle must be changed. Implementing rotation should consider what to do with items that can not (easily) be rotated: text items, rectangles, non-circular ovals and arcs, widgets and images. Currently, text can not be drawn at an arbitrary angle, so I propose to only transform the coordinates at which the text is "anchored". A similar strategy can be used for widgets and images. For rectangles and general ovals and arcs there are two choices: Transforming the item into a polygon would solve the definition problem (these items are defined by a bounding box and the orientation is implicitly assumed), but might break scripts that look for a particular type of item.Therefore we will simply calculate a new bounding box and ignore changes in orientation.

Canvases will have a new subcommand, rotate, which will rotate the coordinates of chosen items by a specified angle about a specified point. canvas rotate itemOrTag x y angle Note that most of the arguments are very similar to the canvas's scale subcommand. Angle is measured in degrees, with positive values indicating anti-clockwise rotation. [These are required for this TIP, but are not yet done.]

A reference implementation does not yet exist.

Should we also consider the possibility of reflections in a line? Should we also consider more general linear transformations (to be specified via a 2x2 matrix)? What about full affine transformations (i.e. with the translation components)? If we implement these from the start, we need to do only a little more work.

It might be useful to utilize the -anchor Tk option in all canvas items and add a new "-anchoroffset $x,$y" option, where $x $y be canvas distances relevant to the anchor position. Once defined, or with their default values, the -anchor and -anchoroffset values combined will provide the item's center, for placement and rotation purposes. Item sets, constituting symbols, can then be manipulated easily. It could probably be beneficial to add an -angle option (and an accomplanying -angleunit one), to persist a rotation angle in the configuration database. The presence of an angle value other than zero would help negate rotation, thus re-instating the item to its initial orientation.

This document is placed in the public domain.