Docs: describe what the letters T/R/B in `{T|R|B}Box` mean

[dotnetCarpenter]

On behalf of @Zearin:

I’m trying to keep straight in my head which class does what, but it’s hard when the only thing I have to go on is the letter prefixing each class.

I can only guess that BBox stands for “Bounding Box”, but without the docs explicitly saying so, I get cognitive dissonance as my brain argues with itself as to whether I am “filling in” the meaning of the letter “B” accurately.

Can you add a quick sentence to all their descriptions to clarify this? Something like:

BBox (short for “Bounding Box”) does «description»…

Moved from svgdotjs/svg.js#574

[wout]

Here you go. I also experimented with adding visual examples:

http://svgjs.com/geometry/#bbox

[dotnetCarpenter]

@Zearin, you need to subscribe to this issue, if you want to get updates.

[dotnetCarpenter]

In the TBox example, it looks like x and y doesn't follow scale, even though the docs suggest that they should.

Cool, that you finally got control over http://svgjs.com/. And I really like both the new fuzzy search and the fiddle examples.

[wout]

I noticed the TBox issue too, it's a bug. We'll have to rework that for TBox to follow both attribute and transform translations. Although, I wonder how many people use TBox in its current state. Is there really a need for it?

Great you like the fiddle examples, because I like them very much too. 😋 They add an instant, hands-on experience. I'll start including them in other places as well.

[dotnetCarpenter]

I don't think people are using TBox but it's a breaking change... Hmm in this case, I think we can get away with not following semver.

https://github.com/svgdotjs/svg.screenbbox.js by @Fuzzyma might be what people are using. I've just read the cover, but it looks like it addresses what TBox does. Not sure about the state of the plugin either.

[wout]

The sceenbbox plugin only seems to target poly* and path elements:
https://github.com/svgdotjs/svg.screenbbox.js/blob/master/src/svg.screenbbox.js#L1

The TBox can be fixed easily:

• get the bbox and apply the scale transformation, resulting in a correctly sized tbox
• get the rbox and use it's cx and cy values to position the tbox at its center

Or am I missing something?

It's not a breaking change if we consider it a bug fix, so I wouldn't worry too much about the semver.

[dotnetCarpenter]

ah, ok. I misunderstood. I thought you wanted to remove TBox.

[wout]

Yeah, sorry about the confusion. We could either remove it or fix it. I implemented it at the time to get the dimensions of an element including scale so that explains the lack of translation.

What do you think? Fix it or toss it?

[Fuzzyma]

The screenbbox thing is a different thing. The tbox does not take rotation into account.
If you take a rect and rotate it you end up with the same bounding box as before. Same goes for polygons and paths. getBoundingClinentRect does not work that way. I wrote it after I got a request for this kind of functionality :)

[dotnetCarpenter]

The TBox can be fixed easily:

• get the bbox and apply the scale transformation, resulting in a correctly sized tbox
• get the rbox and use it's cx and cy values to position the tbox at its center

Or am I missing something?

If it's simple then we should fix it.

I've got some hours the following 2 weeks and are looking to solve for some low hanging fruits, in SVG.js. This might be one I could do. Or do you have another suggestion?

I'm closing this as the documentation part is done.