Hi
I stumbled on this problem with tkpath and bbox:

% package re tkpath
0.3.3
% pack [tkp::canvas .c] -fill both -expand 1
% .c create prect 20 20 50 30 -stroke red -tags test
1
% .c coords test
20.0 20.0 50.0 30.0
% .c bbox test
17 17 53 33     <-------------------------- bbox has a 3px padding
% .c itemconfig 0 -matrix [tkp matrix rotate [expr {2 * atan(1)}] 100 100]; # rotate 90°
% .c coords test
20.0 20.0 50.0 30.0   <--------------------------item's coords did not change
% .c bbox test
167 16 183 52   <-------------------------- bbox's coords changed
% .c itemconfig 0 -matrix {}
% .c coords test
20.0 20.0 50.0 30.0
% .c bbox test
17 17 53 33
# ^^^^^^^^^ ----- back to normal

What is the expected behavior exactly?

I'd expect both bbox and coords to return coords in the same frame of reference in which an item was drawn. In the example above, I'd expect:

# after rotate 90°
% .c coords test
20.0 20.0 50.0 30.0
% .c bbox test
17 17 53 33

TL;DR

Imagine doing land surveys on (the rotating) Earth using GPS coordinates, but when it came to the bbox of the area you'd just measured, finding your instrument returned coords in the frame of reference of the Sun.

When rotating the root of the canvas, the whole frame of reference (FoR) of the canvas is rotated. Transformations specified for item 0 with -matrix [tkp matrix ...] are applied to the FoR of the root and not to the individual items or their bboxes. From the standpoint of an individual item, its coords, transformations and bbox should all be in the same FoR.

The way it stands now, bbox seems to refer to a different FoR (that of a 'universal' observer?) than do the coords. Bbox's FoR cannot have any items drawn with it, because the items are instead drawn on the canvas root. If I were to describe in tk's parlance the behavior of coords and bbox, using the Earth-Sun example above, that would be:

.c create prect 10 10 60 30 -tags coords_on_Earth
.c bbox -ref Sun coords_on_Earth

If one tries to draw items using the coords reported by _bbox_ of a transformed canvas root, e.g. [.c create prect 167 16 183 52] using the coords returned by bbox in the rotated example in my first message above, he'll find that the items end up drawn _not_ where they are expected in the FoR of _bbox_ (the 'universal' observer?). This is because the items are actually  drawn on the transformed canvas root and _not_ on the imaginary fixed FoR of bbox. The FoR of bbox lacks a physical 1:1 representation on the canvas. Tk's canvas escapes this problem by having just one FoR and by not being capable of doing transformations.

There may be some other conceptual discrepancies too: gradients use a 'bbox' in the definition of linear transition units; that 'bbox' retains the same orientation with the orientation of the (transformable) items where said gradient is used. This is the expected behavior, but it is different from the way [.c bbox items] behaves.

So again, I'd expect bbox to return the same coords in the rotated root FoR as it does in the un-rotated one, because the frame of reference in which the items are drawn has _not_ changed _for the items_. This, seems to me, would be the only way bbox can have some practical use when drawing on a transformable canvas.

Generally speaking, I'd expect default [.c coords items] and [.c bbox items] to return coords in the frame of reference defined by their ancestor(s). This is how -matrix behaves today, but not how coords and bbox behave. An general optional case could be made for returning coords or bbox in a different FoR, with something like:

.c coords -ref otherFrame tagOrId
  and
.c bbox -ref otherFrame tagOrId

Hopefully the above make sense.

Since right now development in the Tk core is ongoing to integrate both
tkpath and rbc I will not put further time and energy in the current tkpath.

I wasn't aware of that development work taking place.

Reading the docs for the new "path" widget, it looks like the issue of different coordinate systems is resolved by removing functionality, as witnessed by the following:

"Canvases do not support scaling or rotation of the canvas coordinate system relative to the window coordinate system."

Which probably means that the canvas root will now be fixed and not allowed to have a -matrix option and be transformed, and therefore, bbox and coords will always refer to the coordinate system of the root. This is obviously possible with the present tkpath canvas too, if one restrains from using transformations on the root. But leaves canvas items without a native command to obtain coords and a bbox in their own coordinate system.

I might bring this issue up with the Tk developers at some point.

Thanks for the consideration.

Closing this ticket for now.