Hello! I'm still having a tough time with Inkscape's snapping behavior. I'm trying to use it for technical illustration, and thus I find myself moving very large chunks of my drawings around throughout the design process, and need things to line up perfectly.
This is made more difficult by snapping confusion with the following points: 1. Text snapping appears to snap to all edges of a particular text block. Would there be any interest to changing this to snapping to the anchor point in the text, where you initially click the "text" cursor (the i-beam)? This would make it much easier to have the baseline for text line up -- i.e. at the moment (using the current CVS) text with letters that drop below the baseline (words like "happy") snap to the lowest point in the word (the bottom of the 'p' instead of the bottom of the 'h'). 2. Grouped objects can snap to any of the internal nodes when "snap points to grid" is enabled. But not when "snap to bounding box" is selected. What I really want (and what I think most users expect, and would most clearly emulate Illustrator's behavior -- but I could be wrong) is a "snap to the points in a group which form a convex hull around the object".
Point #2 is important to me because I create lots of little EE symbols that are groups of off-grid objects, but inside of an on-grid object (think a register symbol, or anything with internal text that's smaller than the grid size).
I know snapping may be a religious issue with some, and I know that someone else was working really hard on getting the snapping behavior "just right". I'm going to punt the rest of my real work for today and see if I can implement these changes in the current CVS -- what do people think, are these desired behaviors? If so, would a patch be well-received?
Thanks for making such an amazing piece of software, ...Eric
On Mon, 25 Oct 2004, Eric Jonas wrote:
1. Text snapping appears to snap to all edges of a particular textblock. Would there be any interest to changing this to snapping to the anchor point in the text, where you initially click the "text" cursor (the i-beam)? This would make it much easier to have the baseline for text line up -- i.e. at the moment (using the current CVS) text with letters that drop below the baseline (words like "happy") snap to the lowest point in the word (the bottom of the 'p' instead of the bottom of the 'h').
Good idea. This should probably be treated as a bug, since it's definitely not 'expected behavior'.
- Grouped objects can snap to any of the internal nodes when "snap
points to grid" is enabled. But not when "snap to bounding box" is selected. What I really want (and what I think most users expect, and would most clearly emulate Illustrator's behavior -- but I could be wrong) is a "snap to the points in a group which form a convex hull around the object".
I also use Inkscape for technical drawing and also have noticed that the snapping usability is a bit off. It's better than it used to be, though, but like you say sometimes it is hard to just get things snapping where you expect them to.
Point #2 is important to me because I create lots of little EE symbols that are groups of off-grid objects, but inside of an on-grid object (think a register symbol, or anything with internal text that's smaller than the grid size).
I know snapping may be a religious issue with some, and I know that someone else was working really hard on getting the snapping behavior "just right". I'm going to punt the rest of my real work for today and see if I can implement these changes in the current CVS -- what do people think, are these desired behaviors? If so, would a patch be well-received?
Personally I think that'd be great. It's true that we have a mix of developers, and that some people prefer artistic-oriented snapping and others technical-drawing-oriented snapping, so it may take some work to find a snapping solution that'll address all needs, and/or includes preference settings for users to select how it should behave.
This project's policy since the start has been to receive and include all (topical and legally acceptable) patches into the codebase, and discuss later. The one exception is if the patch comes in really close to a release and there won't be sufficient time for review/discussion, we may choose to delay inclusion until post-release. Sometimes Bulia will suggest some alterations before including it, but I think it's pretty unusual for a patch to not get included.
Anyway, so we couldn't say whether it'd be well-received by everyone, but we can say it'll get a fair shake. :-)
I wonder, if there's enough of us with an interest in the technical drawing capabilities of Inkscape would it make sense for us to collaborate on creating a wiki page listing the changes we'd need?
Bryce
Hi Eric,
On Mon, 25 Oct 2004, Eric Jonas wrote:
Hello! I'm still having a tough time with Inkscape's snapping behavior. I'm trying to use it for technical illustration, and thus I find myself moving very large chunks of my drawings around throughout the design process, and need things to line up perfectly.
Good. Sounds like what I want to do in Inkscape ;-)
This is made more difficult by snapping confusion with the following points:
[snip]
I know snapping may be a religious issue with some, and I know that someone else was working really hard on getting the snapping behavior "just right". I'm going to punt the rest of my real work for today and see if I can implement these changes in the current CVS -- what do people think, are these desired behaviors? If so, would a patch be well-received?
I was working on the snapping code a while back, but I got sidetracked with other stuff.
I think a patch would be well-received, at least so that everyone can try out the behaviours you are suggesting. They sound reasonable to me.
Let me know if I can be of any help.
Cheers
Carl
I think a patch would be well-received, at least so that everyone can try out the behaviours you are suggesting. They sound reasonable to me.
Is there generic convex-hull code in inkscape? I was poking around libnr and it appears that there is something called convex-hull in there, but that apparently only stores bounds as a rect, not as a real convex hull (i.e. it just keeps track of the bounding box). I started writing my nice little implementation of Graham Scan, but then realized I was creating lots of little helper functions and whatnot, cluttering up the namespace. Before I get too far into this:
1. Would it be appropriate to create a real Convex Hull class in NR (or modify the existing one) such that you could call either: ConvexHull c(stl-container-of-points) or just do: ConvexHull c; c.add(p1) ... (where the points are NR points)?
2. Or, do people think that simply snapping to the bounding rectangle formed by the set of points should be sufficient?
Thanks again, ...Eric
On Mon, 2004-10-25 at 23:19, Eric Jonas wrote:
I started writing my nice little implementation of Graham Scan, but then realized I was creating lots of little helper functions and whatnot, cluttering up the namespace. Before I get too far into this:
- Would it be appropriate to create a real Convex Hull class in NR (or
modify the existing one) such that you could call either: ConvexHull c(stl-container-of-points) or just do: ConvexHull c; c.add(p1) ... (where the points are NR points)?
That'd be nice to have; if you'd like to have a go at it, it'd be much appreciated. ConvexHull isn't apparently being used for its original purpose now, so you are free to do what you like with it.
Hmm, one thing ... having a constructor that takes a reference to an STL container isn't really in the spirit of the STL; it's probably better to have one that takes a start and end iterator. That's particularly helpful since some STL iterators do not have associated containers.
The only other thing to keep in mind is our definition of "insideness" for libnr: all points on the perimiter of a figure are considered to be inside the figure.
Hence, given a rectangle with opposite corners at (0,0) and (5,5), the points (2,3) and (3,5) are both considered to be "inside" the rectangle.
This also holds true for degenerate figures; for example, a rectangle with "opposite" corners at (0,0) and (0,5) still contains all points on the line from (0,0) to (0,5), inclusive, despite having no width and hence zero area. Similarly, a rectangle with corners (0,0) and (0,0) is considered to contain exactly one point.
[ If the above definition seems counterintuitive to anyone reading and thinking of bitmapped displays, please remember that pixels are a unit of area, not of length, so your expectations about the "insideness" of pixels still hold. A zero-area figure will contain no pixels. ]
I mention this since in the past we had difficulties with different definitions being applied in different parts of the code, resulting in happy fencepost errors; after long discussion we settled on this definition as the least mathematically troublesome.
-mental
I just submitted the convex-hull-of-selected-points snap patch (sf request id 1054639). If people would try it out and let me know what they think, I'd be quite happy. It's not a "real" convex hull, but instead uses the libnr code to get the bounding box of the convex hull.
I tried looking at the text code, but quickly became lost; is there any documentation anywhere on how to get the baseline of a particular text object, or even just an overview of the text subsystem in general? Typography is a scary, complex field... ...Eric
I tried looking at the text code, but quickly became lost; is there any documentation anywhere on how to get the baseline of a particular text object
Baseline is a property of font, not text object. I guess Pango may have something for this. If you find it, you can add a corresponding method to our font_instance class.
, or even just an overview of the text subsystem in general? Typography is a scary, complex field...
Bad luck. Our text system was recently entirely reimplemented by a brilliant programmer who unfortunately decided to stop coding soon after that. As a result, it is now very capable but largely unexplored and uncharted. It is not totally unpenetrable, however; recently I fixed several text bugs and got some superficial understanding of how it works, so you can try asking me specific questions.
On Tue, 26 Oct 2004, Eric Jonas wrote:
I just submitted the convex-hull-of-selected-points snap patch (sf request id 1054639). If people would try it out and let me know what they think, I'd be quite happy. It's not a "real" convex hull, but instead uses the libnr code to get the bounding box of the convex hull.
Cool!
I tried looking at the text code, but quickly became lost; is there any documentation anywhere on how to get the baseline of a particular text object, or even just an overview of the text subsystem in general? Typography is a scary, complex field...
The Pango portion of the text system has some docs, via the Pango website. Not great but perhaps enough to get you going. That's where I'd look first in order to find baseline info about text.
In general, though, much of the codebase lacks documentation, but only for historical reasons. We encourage adding docs as you go, or even just random notes and comments. :-)
Bryce
participants (5)
-
Bryce Harrington -
bulia byak -
Carl Hetherington -
Eric Jonas -
MenTaLguY