Extended boxes

[wout]

While we're talking about boxes, I've been thinking for a while now to implement more values on the boxes. Much like Snap does:

http://snapsvg.io/docs/#Element.getBBox

The additional values Snap introduces are interesting. They might as well be methods on a super class (e.g. SVG.Box). So getting an SVG.ViewBox from an SVG.BBox would be:

var b = element.bbox()
b.viewbox() // -> creates viewbox from bbox

Additional methods could be:

b.enclosing() // -> radius of a circle that fully encloses the box
b.smallest() // -> radius of the smallest circle that can be enclosed
b.largest() // -> radius of the largest circle that can be enclosed
b.path() // -> path command for the resulting box

Making them methods skips the overhead of creation.

Also, creating the SVG.Box super class, will remove the need for the fullBox() helper. I would like to get rid of the helpers, or at least most of them. But that's another story.

[Fuzzyma]

We have rbox which is basically what you want

[saivan]

I do agree that all of this is already available in rBox, except enclosing, smallest, largest, path.

Now I would like to check my understanding of what you're proposing before having a crack, but what you're saying is summarised in this picture:

A few points to make:

• (possibly dumb) Isn't the radius of the smallest circle that can be enclosed in a box always zero?
• The radius of the largest circle is just min(width/2, height/2) of the axis aligned box
• The enclosing circles radius is just sqrt((width/ 2) ** 2 + (height/2) **2) again for an axis aligned box
• Implementing path is easy enough, just a few line to commands, although this really should be another method; I don't believe this will be used terribly often (except possibly for debugging).

Is getting rid of the helpers part of this proposal? Or should that be left for another day?

[Fuzzyma]

I think my answer was related to another answer post which got deletet but I am not entirely sure. For the extra methods: It's a nice to have but not the top priority.

Getting rid of the helper is not part of An proposal yet. In M opinion they can be quite valuable. The way we create objects does not allow class methods and that's why we need them for now

[saivan]

@wout Have we captured your original intention here? If not, could you clarify what these extra properties should do.

[saivan]

So we want input on this, from everyone... if you have a particular calculation you want done; let us know :D

[wout]

@saivan I've missed this one. What you're describing is exactly that.

[saivan]

Oh awesome. Well it should be easy enough to add this sort of thing in. Seems like a pythagorus to me :P

[wout]

Exactly :)

[saivan]

Okay, lets throw it back in the milestone. I don't think it will take me too long to implement

[wout]

The question is, will it be useful to anyone?

[Fuzzyma]

I didnt have a case where I need it. However I am not using this library very often. The problem might be, that the people who potentially use it wont know about it (at least I wouldnt expect such a function on the box).

So I am not sure. I lean towards not implementing it. The lib is bloated enough already :D

[saivan]

Yea, I agree on that front. Its probably not the highest priority. But it could be cool. Not sure there.

[saivan]

looks like this won't make 3.0, but hopefully 3.1