Re: [Inkscape-devel] [Inkscape-user] bbox calculation
On 12/8/06, MenTaLguY <mental@...3...> wrote:
I think some things (e.g. selection outlines) should probably always use the visual bbox. But the line between "technical" and "artistic" can be very fine. Even if we ignore technical users, there are artistic users (including myself) who sometimes require geometric bounds -- tiling is one of the most common cases, but there are others as well.
We need to have a better solution in those situations, because there, the lack of geometric bounds isn't just annoying, it's debilitating. I just wish I knew what that solution was. :/
I can change it back, but I don't want to get back all the problems we had with no-stroke bboxes, and I don't really want to introduce a user option which will be hard to explain to the user and a maintenance burden. On the other hand, we now have an even worse option in Options
Tools > Selector > Default scale origin, which is highly obscure and
rather buggy. It seems to me that if we add a "bounding box includes stroke" option we'll be able to get rid of that "default scale origin" which is a good thing in itself.
It would be still better to find a compromise which would work for everyone and therefore not require an option. Suggestions are welcome. Please also consider that we now have blur, and in at least some cases, it makes perfect sense to include the blur margin in the bbox too.
It'd at least be an incremental improvement if we had an option to select between "visual" (which should include filter area, IMO) and "geometric" bounding boxes.
But there are still a lot of questions around that: which things should it affect? As I noted before, I think selection cues should always correspond to the visual, and probably also selection/click sensitivity as well. Also, should it be one option for everything, or individual settings for separate purposes?
Here's an idea: what about making bbox calculation for most purposes geometric when in outline mode, and visual when in normal mode? I think that should interact well with people's expectations.
-mental
On 12/8/06, MenTaLguY <mental@...3...> wrote:
But there are still a lot of questions around that: which things should it affect?
Exactly - that's what we need, an analysis of all the places a bbox is used/displayed with an assessment of whether that place should use stroke/blur or not.
As I noted before, I think selection cues should always correspond to
the visual, and probably also selection/click sensitivity as well.
I think I agree.
Also, should it be one option for everything, or individual settings for separate purposes?
It's best to minimize options, of course.
Here's an idea: what about making bbox calculation for most purposes geometric when in outline mode, and visual when in normal mode? I think that should interact well with people's expectations.
I'm not sure. Changing e.g. scaling or snapping behavior depending on mode does not sound like a good idea to me. Also, it is useful to have the bbox show me the extent of the object with stroke even in outline mode - that way, I can see how wide is the stroke even without seeing the stroke itself.
bulia byak wrote:
On 12/8/06, MenTaLguY <mental@...3...> wrote:
But there are still a lot of questions around that: which things should it affect?
Exactly - that's what we need, an analysis of all the places a bbox is used/displayed with an assessment of whether that place should use stroke/blur or not.
That is definitely a good idea, to start this off I looked at the SVG specification to see what should be used for SVG, and if I read it correctly (Batik and Firefox seem to agree with me btw) Inkscape should at least ignore strokes when calculating bounding boxes for objectBoundingBox units:
"The bounding box is computed *exclusive* of any values for clipping, masking, *filter effects*, opacity and *stroke-width*."
See: http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBox
I filed this as bug 1612108 (with a test case which shows the problem).
(Note that the SVG test suite apparently doesn't test this, I could only find tests that don't use stroke or use userSpaceOnUse units.)
participants (3)
-
bulia byak -
Jasper van de Gronde -
MenTaLguY