Should select area for text objects include leading and trailing spaces?
In this bug:
https://bugs.launchpad.net/inkscape/+bug/1243401
there is a discussion about whether or not the selectable area for a text object should include leading and trailing spaces. That is, for text objects 1 = " " and 2 = " a b " the old behavior was that the "arrow" or "+A" selection pointers would not detect object 1 at all and would move across the leading and trailing spaces of object 2 without registering a hit. The patch in that bug makes these pointers treat spaces like any other character.
People were coming down on both sides of the change and ScislaC suggested moving that discussion here. See posts 20-27 for the discussion so far.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
2014-04-11 20:35 GMT+02:00 mathog <mathog@...1176...>:
In this bug:
https://bugs.launchpad.net/inkscape/+bug/1243401
there is a discussion about whether or not the selectable area for a text object should include leading and trailing spaces. That is, for text objects 1 = " " and 2 = " a b " the old behavior was that the "arrow" or "+A" selection pointers would not detect object 1 at all and would move across the leading and trailing spaces of object 2 without registering a hit. The patch in that bug makes these pointers treat spaces like any other character.
The approach in all of Inkscape is that if an object is not visible, it is not selectable. To select invisible objects, you use the outline mode. Therefore, for consistency, whitespace must not be selectable.
Text that contains only whitespace (doesn't generate any paths) should be automatically deleted when it is deselected. This would be an extension of what happens when the user clicks on the canvas on the text tool but doesn't type anything; no object is created in that case. Similarly, when a text editing event results in the object containing only whitespace, it should be removed from the object tree and re-inserted once a visible glyph becomes part of the text.
Regards, Krzysztof
2014-04-11 21:22 GMT+02:00 Krzysztof Kosiński <tweenk.pl@...400...>:
Text that contains only whitespace (doesn't generate any paths) should be automatically deleted when it is deselected. This would be an extension of what happens when the user clicks on the canvas on the text tool but doesn't type anything; no object is created in that case. Similarly, when a text editing event results in the object containing only whitespace, it should be removed from the object tree and re-inserted once a visible glyph becomes part of the text.
Addendum: the paragraph above is certainly up for discussion (in my opinion it would make things easier for users), but in general I am very firmly against redefining the concept of visual bounding box in a completely inconsistent way just because it makes a feature easier to implement.
If decorated whitespace does not become part of the visual bounding box and is not pickable (i.e. clicking it does not select the text object), then the implementation of decoration is buggy. The solution is to fix picking and bounding box calculation for decorated text, not break it for all non-decorated text.
Regards, Krzysztof
On 11-Apr-2014 12:31, Krzysztof Kosiński wrote:
2014-04-11 21:22 GMT+02:00 Krzysztof Kosiński <tweenk.pl@...400...>:
Text that contains only whitespace (doesn't generate any paths) should be automatically deleted when it is deselected. This would be an extension of what happens when the user clicks on the canvas on the text tool but doesn't type anything; no object is created in that case.
These are not the same thing though. A click, do nothing, is a text box with no characters, whereas one with only white space is a perfectly valid text object, albeit one that is not at that moment visible. I agree that an empty <text> or <tspan> should go away.
What you are suggesting for the proper selection mode is very much like those programs that trim white spaces out of text when exporting to various graphics formats. These convert:
"This is a sentence."
to 4 objects:
"This", "is", "a", "sentence".
That is all well and good if the only intent is ever to draw with those objects, but the problems with this philosophy show up when it must be imported into another program. Hence libTERE, which does its best to reassemble this sort of mess, which would never have been needed had the intervening spaces been emitted.
Consider this thought experiment, what actions are going to be needed to convert (these are aligned text objects, not a text box with wrapped lines):
Topic Subtopic A
to
1 Topic 1a Subtopic A
With spaces selectable one would type in the 1, then go straight down to the next line and click, which would put the insertion point on or very near where it needs to be. If spaces are not selectable one must click on "S" in Subtopic and then use the cursor keys to move several spaces to the left before the correct insertion point is reached.
Similarly, when a text editing event results in the object containing only whitespace, it should be removed from the object tree and re-inserted once a visible glyph becomes part of the text.
How is that to happen if the user cannot select it?
It wouldn't be particularly difficult to make the extent of the text pick box for text (+/- spaces) yet another user settable preference. Then we can argue over the default setting!
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Is the Visual Bounding box an actual SVG thing? Or is it an Inkscape thing? If an Inkscape thing, theoretically we could just add another bounding box mode... something like Logical Bounding Box.
I checked out both how Draw and AI handle it... and they both handle text and whitespace differently.
Just to note, in both apps you can create empty text frames... Draw uses faux placeholder text though instead of leaving it effectively invisible when unselected.
Now on to "normal" text...
As for leading: In Draw, you can't even add leading whitespace. It just moves the exiting text object forward by the expected distance... it feels really weird. In AI, you can add it, it is selectable, it expands their bbox.
As for trailing: In Draw you can add it, it is not selectable with the selection tool and does not expand their bbox. In AI, treats it like it does leading.
To me, I think AI's way is just more logical... if you are adding spaces at the beginning or end of text, you are probably intentionally doing it for some reason.
As mentioned in the bug report discussion, if we're going to be nitpicky about the Visual bbox, it's pretty broken when using filters as far as a user is concerned.
Cheers, Josh
On Fri, Apr 11, 2014 at 12:31 PM, Krzysztof Kosiński <tweenk.pl@...400...>wrote:
2014-04-11 21:22 GMT+02:00 Krzysztof Kosiński <tweenk.pl@...400...>:
Text that contains only whitespace (doesn't generate any paths) should be automatically deleted when it is deselected. This would be an extension of what happens when the user clicks on the canvas on the text tool but doesn't type anything; no object is created in that case. Similarly, when a text editing event results in the object containing only whitespace, it should be removed from the object tree and re-inserted once a visible glyph becomes part of the text.
Addendum: the paragraph above is certainly up for discussion (in my opinion it would make things easier for users), but in general I am very firmly against redefining the concept of visual bounding box in a completely inconsistent way just because it makes a feature easier to implement.
If decorated whitespace does not become part of the visual bounding box and is not pickable (i.e. clicking it does not select the text object), then the implementation of decoration is buggy. The solution is to fix picking and bounding box calculation for decorated text, not break it for all non-decorated text.
Regards, Krzysztof
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Other programs:
Powerpoint: cursor shape changes as it passes over leading and trailing spaces. It allows text boxes containing nothing but spaces.
LibreOffice Draw 4.1.12: cursor shape changes as it passes over trailing spaces but it ignores leading spaces. (Bizarre.) It allows text boxes containing nothing but spaces but the cursor does not change shape as it passes over them. These are selectable by dragging a rectangle out and around the text object.
scribus: draws a text box with an outline that is always visible. Cursor shape does not change entering that box, or over visible or whitespace characters within it.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
A couple more:
Dia: Allows leading/trailing spaces, they can be selected (there is no visual hint), they're included in the highlight/selected effect (no bbox to speak of). SVG-edit: Allows leading/trailing spaces, they can be selected, they expand the "object area" (it's some kind of bbox, but doesn't appear as tightly defined as ours is).
I tested LibreOffice Draw (4.2.3rc3) as well and see no cursor change under any circumstances. The leading/trailing is not selectable, but if you click close enough to the object boundary it will select the object (so the area above, below, and to the side of the first/last space). A text object containing only spaces can be select by the same way, but with no visual hint, so you have to know where to click.
Cheers, Josh
On Fri, Apr 11, 2014 at 2:04 PM, mathog <mathog@...1176...> wrote:
Other programs:
Powerpoint: cursor shape changes as it passes over leading and trailing spaces. It allows text boxes containing nothing but spaces.
LibreOffice Draw 4.1.12: cursor shape changes as it passes over trailing spaces but it ignores leading spaces. (Bizarre.) It allows text boxes containing nothing but spaces but the cursor does not change shape as it passes over them. These are selectable by dragging a rectangle out and around the text object.
scribus: draws a text box with an outline that is always visible. Cursor shape does not change entering that box, or over visible or whitespace characters within it.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
2014-04-11 22:38 GMT+02:00 Josh Andler <scislac@...400...>:
Is the Visual Bounding box an actual SVG thing? Or is it an Inkscape thing? If an Inkscape thing, theoretically we could just add another bounding box mode... something like Logical Bounding Box.
It is an Inkscape thing.
Inkscape has two ways of computing the bounding box, and you can select which one is used to draw the selection cue in the preferences of the selector tool. The first is the "geometric bounding box", which corresponds to the SVG bbox used to evaluate objectBoundingBox coordinates. It ignores stroke, clipping, masking, etc. The second is "visual bounding box", which is a tight fit over the area visually affected by the object - it considers the effect of clipping, masking, stroke, filters, and so on.
If we are to maintain this definition, then the geometric bounding box of text should include leading/trailing whitespace, but the visual one shouldn't. Note that there is no requirement for the geometric bbox to be contained in the visual bbox. They can be completely unrelated, because they are used for different purposes.
As for leading: In Draw, you can't even add leading whitespace. It just moves the exiting text object forward by the expected distance... it feels really weird. In AI, you can add it, it is selectable, it expands their bbox.
As for trailing: In Draw you can add it, it is not selectable with the selection tool and does not expand their bbox. In AI, treats it like it does leading.
To me, I think AI's way is just more logical... if you are adding spaces at the beginning or end of text, you are probably intentionally doing it for some reason.
Adding leading whitespace should not move the text anchor, but it also shouldn't expand the visual bbox or the pickbox. Selecting a text object by clicking on a blank area (especially leading / trailing whitespace) is inconsistent with the rest of Inkscape, with the possible exception of filters with too large filter regions (which should be fixed anyway).
As mentioned in the bug report discussion, if we're going to be nitpicky about the Visual bbox, it's pretty broken when using filters as far as a user is concerned.
That's a different problem.
We could automatically set the filter region based on the filter's primitives and settings, and we in fact already perform this kind of calculation when rendering the filter.
Regards, Krzysztof
On 11-Apr-2014 17:00, Krzysztof Kosiński wrote:
Selecting a text object by clicking on a blank area (especially leading / trailing whitespace) is inconsistent with the rest of Inkscape
This case should be different, text is more than just a collection of shapes:
1. A donut shaped object is not selected by clicking in the hole. 2. A line of text is not selected by clicking on the spaces between the words.
The first one is fine, the hole is not a part of the object. The second one is crazy, because the space is very much a part of the text.
To me the text object is first and foremost text, and only secondarily a graphics object, and I want to be able to do text like things to it. I think of the text objects as little text editor windows that I can move around in the diagram. Every character is important whether or not it has a glyph.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On Sat, 2014-04-12 at 02:00 +0200, Krzysztof Kosiński wrote:
(especially leading / trailing whitespace) is inconsistent with the rest of Inkscape
It would only be inconsistent if text characters were svg objects. Text spaces are printed to the screen, they are "visible" parts of the text object's construction. Removing text boxes with spaces, not being able to click on leading spaces, these are conclusions which conflate the svg object space with the text/character space.
A good illustration of this:
Create a text box by dragging a square with the text tool. Add ten spaces to the top line, nine to the next and so on until the last line with one space.
This object now has two non-visible areas. One is the transparent non-text area where no characters exist; and the rest is an non-apparent triangle of spaces. Thus one can demonstrate there is really two realms of "non-visible" areas and these result from their two originating contexts.
I conclude that the rules for these two should not be the same.
All the Best, Martin Owens
On 11-Apr-2014 18:17, Martin Owens wrote:
Create a text box by dragging a square with the text tool. Add ten spaces to the top line, nine to the next and so on until the last line with one space.
This object now has two non-visible areas. One is the transparent non-text area where no characters exist; and the rest is an non-apparent triangle of spaces. Thus one can demonstrate there is really two realms of "non-visible" areas and these result from their two originating contexts.
I conclude that the rules for these two should not be the same.
Excellent example. With the latest patches here:
https://bugs.launchpad.net/inkscape/+bug/1243401
all of the text area within the box (including all spaces) is selectable and all of the non-text area is ignored. The space between text lines is also not selectable.
So are we all OK now on having selectable leading and trailing spaces?
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
2014-04-14 18:27 GMT+02:00 mathog <mathog@...1176...>:
On 11-Apr-2014 18:17, Martin Owens wrote:
Create a text box by dragging a square with the text tool. Add ten spaces to the top line, nine to the next and so on until the last line with one space.
This object now has two non-visible areas. One is the transparent non-text area where no characters exist; and the rest is an non-apparent triangle of spaces. Thus one can demonstrate there is really two realms of "non-visible" areas and these result from their two originating contexts.
I conclude that the rules for these two should not be the same.
Excellent example. With the latest patches here:
https://bugs.launchpad.net/inkscape/+bug/1243401
all of the text area within the box (including all spaces) is selectable and all of the non-text area is ignored. The space between text lines is also not selectable.
So are we all OK now on having selectable leading and trailing spaces?
No, I still think this completely breaks consistency with other tools, and the presented arguments that one kind of invisibility is different from some other kind do not convince me at all. A space is not visible, and in all other cases selection is visibility-based.
I there is demand for this, I am OK with it being an option.
Regards, Krzysztof
2014-04-14 18:58 GMT+02:00 Krzysztof Kosiński <tweenk.pl@...400...>:
No, I still think this completely breaks consistency with other tools, and the presented arguments that one kind of invisibility is different from some other kind do not convince me at all. A space is not visible, and in all other cases selection is visibility-based.
Unless of course it is a decorated space, then it (or more precisely its decoration) is visible and should be selectable.
Regards, Krzysztof
On Mon, 2014-04-14 at 18:58 +0200, Krzysztof Kosiński wrote:
No, I still think this completely breaks consistency with other tools, and the presented arguments that one kind of invisibility is different from some other kind do not convince me at all. A space is not visible, and in all other cases selection is visibility-based.
There is only one way to know for sure. We must collect data. (otherwise we should make the call based on a consensus)
Can you design a test which could be given to users, which could falsify your claims of confusion?
Martin,
2014-04-14 19:12 GMT+02:00 Martin Owens <doctormo@...400...>:
On Mon, 2014-04-14 at 18:58 +0200, Krzysztof Kosiński wrote:
No, I still think this completely breaks consistency with other tools, and the presented arguments that one kind of invisibility is different from some other kind do not convince me at all. A space is not visible, and in all other cases selection is visibility-based.
There is only one way to know for sure. We must collect data. (otherwise we should make the call based on a consensus)
Can you design a test which could be given to users, which could falsify your claims of confusion?
Select all red circles in this document.
For me, it would be very confusing that clicking on the top circles selects them, and clicking on the bottom ones selects the text instead.
Regards, Krzysztof
On 14-Apr-2014 10:58, Krzysztof Kosiński wrote:
2014-04-14 19:12 GMT+02:00 Martin Owens <doctormo@...400...>:
Can you design a test which could be given to users, which could falsify your claims of confusion?
Select all red circles in this document.
You mean by dragging a box around them, or one at a time?
In the former case it also picks up the top text, telling the user that the lower text must extend invisibly outwards.
In the latter case it only picks up the circles, which is not confusing at all.
If one selects the lower text and raises it above the adjoining circle, then clicking on the circle does select the text, which is clearly seen by its visible bounding box to extend beyond both adjoining circles. That is, the text box is wider than and lies over the circles.
It all makes sense to me.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
2014-04-14 20:28 GMT+02:00 mathog <mathog@...1176...>:
On 14-Apr-2014 10:58, Krzysztof Kosiński wrote:
2014-04-14 19:12 GMT+02:00 Martin Owens <doctormo@...400...>:
Can you design a test which could be given to users, which could falsify your claims of confusion?
Select all red circles in this document.
You mean by dragging a box around them, or one at a time?
In the former case it also picks up the top text, telling the user that the lower text must extend invisibly outwards.
In the latter case it only picks up the circles, which is not confusing at all.
I meant selecting them one at a time with Shift. I had the impression that the proposed behavior is to select the bottom text when clicking on the circles (because its leading/trailing space is overlapping the circles), not the current behavior.
Regards, Krzysztof
Some text editors have special modes or options to visualize spaces at the ends of lines. This isn't often needed but sometimes it is necessary. And then, selecting text by clicking on a space between words is a pretty intuitive thing to do as well.
We have the visual and geometric bboxes, so why not make use of this here? Geometric bbox would only include glyph outlines - but the visual one, which already includes things like shadow filters (which can be almost transparent), would also include spaces. I think it would be logical enough and accommodate different needs without introducing a new option.
I also disagree that an all-space text object must be deleted automatically. There may be all kinds of reasons to have such objects in a document. The only automatic deletion which has always been in Text tool, and which is quite enough, is if you just clicked on canvas to start a new text and then immediately pressed Esc or switched tool without typing anything.
On Tue, Apr 15, 2014 at 1:46 PM, Krzysztof Kosiński <tweenk.pl@...972.....> wrote:
2014-04-14 20:28 GMT+02:00 mathog <mathog@...1176...>:
On 14-Apr-2014 10:58, Krzysztof Kosiński wrote:
2014-04-14 19:12 GMT+02:00 Martin Owens <doctormo@...400...>:
Can you design a test which could be given to users, which could falsify your claims of confusion?
Select all red circles in this document.
You mean by dragging a box around them, or one at a time?
In the former case it also picks up the top text, telling the user that the lower text must extend invisibly outwards.
In the latter case it only picks up the circles, which is not confusing at all.
I meant selecting them one at a time with Shift. I had the impression that the proposed behavior is to select the bottom text when clicking on the circles (because its leading/trailing space is overlapping the circles), not the current behavior.
Regards, Krzysztof
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2014-04-15 22:51 GMT+02:00 Dmitry Kirsanov <buliabyak@...400...>:
Some text editors have special modes or options to visualize spaces at the ends of lines. This isn't often needed but sometimes it is necessary. And then, selecting text by clicking on a space between words is a pretty intuitive thing to do as well.
We have the visual and geometric bboxes, so why not make use of this here? Geometric bbox would only include glyph outlines - but the visual one, which already includes things like shadow filters (which can be almost transparent), would also include spaces. I think it would be logical enough and accommodate different needs without introducing a new option.
That's the opposite of what I would expect, e.g. I would expect leading / trailing spaces to be included in the geometric box, but not in the visual box.
I also disagree that an all-space text object must be deleted automatically. There may be all kinds of reasons to have such objects in a document. The only automatic deletion which has always been in Text tool, and which is quite enough, is if you just clicked on canvas to start a new text and then immediately pressed Esc or switched tool without typing anything.
OK.
I think the situation with invisible objects would be somewhat improved if one of the buttons - the color-managed view indicator (in the corner between the scrollbars) and/or the zoom lock button (above the vertical scrollbar) - were replaced by a toggle of the outline mode.
Regards, Krzysztof
On Tue, Apr 15, 2014 at 10:44 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
2014-04-15 22:51 GMT+02:00 Dmitry Kirsanov <buliabyak@...400...>:
We have the visual and geometric bboxes, so why not make use of this here? Geometric bbox would only include glyph outlines - but the visual one, which already includes things like shadow filters (which can be almost transparent), would also include spaces. I think it would be logical enough and accommodate different needs without introducing a new option.
That's the opposite of what I would expect, e.g. I would expect leading / trailing spaces to be included in the geometric box, but not in the visual box.
Perhaps this is a sign that the names of the two bbox types are not the best possible. We may consider renaming them if there are good ideas. The general meaning of them is:
- "geometric" covers the barebone outline of the object: no stroke, no markers, no filters. Just the geometric skeleton.
- "visual" covers object plus all its various "emanations" - drop shadows, stroke, markers, etc. It is called "visual" because these emanations are usually visible in some way, but that's not necessarily so, e.g. shadow or stroke may be fully transparent and still count for this bbox. So I think spaces in texts fit nicely with this general idea.
Maybe we should rename them to "skeleton bbox" vs "flesh bbox" if that's not too extravagant :)
I think the situation with invisible objects would be somewhat improved if one of the buttons - the color-managed view indicator (in the corner between the scrollbars) and/or the zoom lock button (above the vertical scrollbar) - were replaced by a toggle of the outline mode.
I agree about the "zoom lock" button - it seems pretty useless to me. Does anyone ever use it? As far as I remember it's there since Sodipodi times, back when the UI was based on floating per-document windows and shared floating dialogs, so document windows were supposed to be often moved around and resized. I don't think it makes much sense with our current UI with docked dialogs.
On Tue, Apr 15, 2014 at 7:07 PM, Dmitry Kirsanov <buliabyak@...400...>wrote:
Maybe we should rename them to "skeleton bbox" vs "flesh bbox" if that's not too extravagant :)
I think that's a pretty reasonable change/compromise and less limiting than having names with somewhat more rigid meanings.
Cheers, Josh
Interesting bug,
There's an issue in trunk where any text object extends far above and below it's visible bounding box. A serious issue reported to me twice at LGM and frustrating to me doing any sort of text work.
Is this the same or similar issue? Should the selectable area for text be the visual bbox instead?
I'd like to say that spaces in text are not the same as invisible objects which are not the same as no objects. Yet if I understand KK's post on the bug, they should be treated the same way.
My opinion is that spaces in text are visual objects that are visible, even if they are unapparent. As much as 0.1% opacity rectangle is still "visible" anyway.
Make all objects selectable and make the ability to select behind objects easier. Make it easier to deal with transparent objects.
Martin
On Fri, 2014-04-11 at 11:35 -0700, mathog wrote:
In this bug:
https://bugs.launchpad.net/inkscape/+bug/1243401
there is a discussion about whether or not the selectable area for a text object should include leading and trailing spaces. That is, for text objects 1 = " " and 2 = " a b " the old behavior was that the "arrow" or "+A" selection pointers would not detect object 1 at all and would move across the leading and trailing spaces of object 2 without registering a hit. The patch in that bug makes these pointers treat spaces like any other character.
People were coming down on both sides of the change and ScislaC suggested moving that discussion here. See posts 20-27 for the discussion so far.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Martin,
The bug report where the discussion originated is for that very bug (space above and below text causing selection). :)
On Fri, Apr 11, 2014 at 12:34 PM, Martin Owens <doctormo@...400...> wrote:
Interesting bug,
There's an issue in trunk where any text object extends far above and below it's visible bounding box. A serious issue reported to me twice at LGM and frustrating to me doing any sort of text work.
Is this the same or similar issue? Should the selectable area for text be the visual bbox instead?
I'd like to say that spaces in text are not the same as invisible objects which are not the same as no objects. Yet if I understand KK's post on the bug, they should be treated the same way.
My opinion is that spaces in text are visual objects that are visible, even if they are unapparent. As much as 0.1% opacity rectangle is still "visible" anyway.
Make all objects selectable and make the ability to select behind objects easier. Make it easier to deal with transparent objects.
Martin
On Fri, 2014-04-11 at 11:35 -0700, mathog wrote:
In this bug:
https://bugs.launchpad.net/inkscape/+bug/1243401
there is a discussion about whether or not the selectable area for a text object should include leading and trailing spaces. That is, for text objects 1 = " " and 2 = " a b " the old behavior was that the "arrow" or "+A" selection pointers would not detect object 1 at all and would move across the leading and trailing spaces of object 2 without registering a hit. The patch in that bug makes these pointers treat spaces like any other character.
People were coming down on both sides of the change and ScislaC suggested moving that discussion here. See posts 20-27 for the discussion so far.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
From a user POV, lots of people use SVG for scripting (like forms filled by a database, etc. ). For this use, an "empty" (or only containing spaces) text makes sense, as it can be "filled" by a script, and destroying it would not be what th user expects.
Regards, Ed
From: scislac@...400... Date: Fri, 11 Apr 2014 13:18:01 -0700 To: doctormo@...400... CC: inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Should select area for text objects include leading and trailing spaces?
Martin,
The bug report where the discussion originated is for that very bug (space above and below text causing selection). :)
On Fri, Apr 11, 2014 at 12:34 PM, Martin Owens <doctormo@...400...> wrote:
Interesting bug,
There's an issue in trunk where any text object extends far above and
below it's visible bounding box. A serious issue reported to me twice at
LGM and frustrating to me doing any sort of text work.
Is this the same or similar issue? Should the selectable area for text
be the visual bbox instead?
I'd like to say that spaces in text are not the same as invisible
objects which are not the same as no objects. Yet if I understand KK's
post on the bug, they should be treated the same way.
My opinion is that spaces in text are visual objects that are visible,
even if they are unapparent. As much as 0.1% opacity rectangle is still
"visible" anyway.
Make all objects selectable and make the ability to select behind
objects easier. Make it easier to deal with transparent objects.
Martin
On Fri, 2014-04-11 at 11:35 -0700, mathog wrote:
In this bug:
there is a discussion about whether or not the selectable area for a
text object should include leading and trailing spaces. That is, for
text objects 1 = " " and 2 = " a b "
the old behavior was that the "arrow" or "+A" selection pointers would
not detect object 1 at all and would move across the leading and
trailing spaces of object 2 without registering a hit. The patch in
that bug makes these pointers treat spaces like any other character.
People were coming down on both sides of the change and ScislaC
suggested moving that discussion here. See posts 20-27 for the
discussion so far.
Regards,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, Apr 11, 2014 at 12:34 PM, Martin Owens <doctormo@...400...> wrote:
Make all objects selectable and make the ability to select behind objects easier. Make it easier to deal with transparent objects.
I would agree with making all objects selectable (excluding locked objects). As for selecting behind objects, we have two easy methods already when using the Selector Tool... 1) Alt+Click (linux window managers should really just switch to Super+Drag to move windows... just saying) 2) Alt+Scrollwheel (which is very nice visually imho, it seems like we should add this visual hint to the Alt+Click method for the duration of Alt being held after the first click).
Cheers, Josh
participants (6)
-
Dmitry Kirsanov -
Eddy StEsprit -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
mathog