- Inkscape Devel - Inkscape Mailman

middle button click, zooming news
by bulia byak 15 Jan '04

15 Jan '04

I have enabled middle button click to zoom in or (with Shift) out. This is in addition to middle button drag which pans the canvas as before. This works in all tools. The zoom increment (used by all zoom methods) is now stored in the preferences [options.zoomincrement]. I also changed the algorithm of zooming in/out on click. Previously, the point you clicked on was centered in the window after zoom. Now it remains under your mouse, i.e. you can position mouse over the object you're interested in and click several times in a row to zoom into it without having to move your mouse, even if that object is not in the center of window. I think it's much more convenient this way. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

RE: [Inkscape-devel] SPOffset standards considerations
by bulia byak 15 Jan '04

15 Jan '04

> 1. use our own inkscape:href (or something like that) attribute instead >of xlink:href for linked offsets -- SVG does not define xlink:href to >have meaning for <path> elements. Yes > 2. populate the d= attribute of the SPOffset <path> with the offset >path, so the SVG requirements are satisfied, and normal SVG UAs have >something to render. Doesn't it do that already? >[ a ground rule here is that an Inkscape document should look no >different in a pure SVG UA than in Inkscape -- at minimum, when in >doubt, check how it looks in Batik ] Yes > 3. All of the SPOffset extension attributes need to be in the inkscape >namespace, not the sodipodi namespace (e.g. inkscape:original, not >sodipodi:original). The sodipodi namespace is reserved for Sodipodi's >use. This holds true for all new functionality we add. Yes, I wrote about that >As interoperability and standards-compliance are core goals for us, I >can't sign off on an 0.37 release until these are fixed. But I think they are really easy to fix :) _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f%2fjoin…

2 1

RE: Scrolling Idea for inkscape
by bulia byak 15 Jan '04

15 Jan '04

>(18:01:59) rejon: feels like the zooming position should be based on the >canvas/page size No, I think +/- zooming should always zoom to the center of view, as it does now. Taking into account the canvas is unreliable, because your drawing may be smaller or larger than the canvas. >unless zoomed in with the mouse scrollwheel, in which >case the point from which the zoom is performed would be the current >mouse x/y position Yes, any click-zoom (be that wheel, zoom tool, etc) must zoom into the mouse point position. Report a bug if that ain't so. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

Re: [Inkscape-devel] new offset commands
by bulia byak 15 Jan '04

15 Jan '04

>Further extensions to make this an uber tool: > >There needs to be a 'convert to path' dynamic tool, which maintains a path >converted from the original shape (spiral, oval etc) so that the user can >edit the handles on the original shape. That is, a spiral can be the parent of a path, and the path, the parent of an offset - so the spiral can affect the offset without becoming a path? That might be cool indeed. >Rather than defaulting to 'cap', outset should allow the user to choose >between the 3 corner choices, cap, mitre and bevel. Simply use the cap/join settings of the shape being offset >Why does the path always get closed? I can't see any justification for >this in the algorithm? Agreed >Why does a crossed (self intersecting) path get 'unwound' when making >outset? I would have thought that a reasonable definition would be 'the >curve n pixels to the left of this curve as I walk in the standard >direction'. This would remove some of the abiguity I think? Intuitively, when I have a shape with a hole, I expect outset to close this hole and inset to make it bigger. This is what the current algorithm does. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

SPOffset standards considerations
by MenTaLguY 15 Jan '04

15 Jan '04

Congratulations on all the great work that's going on with the offset stuff. It's a very useful feature! However... Currently, an Inkscape SVG document using SPOffsets will not render properly in other conformant SVG user agents. This is not good. To remedy this: 1. use our own inkscape:href (or something like that) attribute instead of xlink:href for linked offsets -- SVG does not define xlink:href to have meaning for <path> elements. 2. populate the d= attribute of the SPOffset <path> with the offset path, so the SVG requirements are satisfied, and normal SVG UAs have something to render. [ a ground rule here is that an Inkscape document should look no different in a pure SVG UA than in Inkscape -- at minimum, when in doubt, check how it looks in Batik ] 3. All of the SPOffset extension attributes need to be in the inkscape namespace, not the sodipodi namespace (e.g. inkscape:original, not sodipodi:original). The sodipodi namespace is reserved for Sodipodi's use. This holds true for all new functionality we add. As interoperability and standards-compliance are core goals for us, I can't sign off on an 0.37 release until these are fixed. -mental

1 0

sorry to be so wordy!
by Jonathan Phillips 15 Jan '04

15 Jan '04

Inkscape, with dynamic offset, linked offset and the new node UI tweaks is very rockin' now to design with. I can literally churn out new graphics with it. Great work guys! The Boolean Ops and color palette are so excellent to work with now. GR8 WORK! Jon -- Jonathan Phillips <jon@...15...>

2 1

Re: new offset commands
by bulia byak 15 Jan '04

15 Jan '04

> > - The simple Inset/Outset commands must check if the > > object is already an > > SPOffset, and if so, adjust its radius instead of > > converting it to shapes. > >the offset of an offset of shape A is not in general >another offset of A. what you want is mathematically >incorrect, but maybe what the user expects... That is, you mean that several sequential simple offsets of a path will give a different result than several sequential adjustments of an SPOffset radius? If so that is unfortunate, but if there's no mathematical workaround for this problem, I would still argue that the above described behavior is the most logical. An SPOffset is a higher level of abstraction than a path; if we can perform some operation without lowering the level of abstraction, we must do that, if only because lowering the level of abstraction is generally irreversible. > > - The dynamic offsets do not accept zero radius; > > they snap it to +/- 0.25, > > so you cannot do an exact copy of the original. Why > > this limitation? I tried > >0 width will cause problems, and imposing a minimum >radius was the simplest way around; besides what's the >point of doing a 0 offset? The point is that when I have an SPOffset, I normally use node tool to adjust its radius, and I don't want to have any preset value - I want to start from zero. Another point is that it's not clean to have different inset/outset commands for different offset types; it's much more logical to have one pair of inset/outset commands that act on any objects plus several commands that create (but not adjust) different kinds of offset objects. It's just a matter of a clean separation of concepts. And finally, an object with a parameter that cannot take one specific value (even though this value makes sense for it) is a lack of genericity and looks more like a bug to me. So, can you just add a special-case treatment in SPObject so that if radius is 0 (or very close to 0), it simply copies the original path without attempting any offset? _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjo…

2 1

new offset commands
by bulia byak 15 Jan '04

15 Jan '04

I added two new commands to the Path menu: Dynamic offset and Linked offset. Now simple Inset/Outset commands work on paths, and the two new commands create an "offset object" that can be dynamically adjusted by the node tool. The difference between them is that Dynamic offset transforms the selected object into an offset, while Linked offset adds a new offset object that is linked to the original path, so you can edit the original path and its linked offset will be updated. This is a very powerful tool and I'm really excited about it. Fred, there are some remaining problems where we need your help. It would be great to have them fixed for the upcoming release: - It appears that all offsets now use the imprecise algorithm (you once mentioned that there were two algorithms, one precise but slow and the othe imprecise but fast). I think we should use the precise algorithm for all kinds of offsets, dynamic or not. - The simple Inset/Outset commands must check if the object is already an SPOffset, and if so, adjust its radius instead of converting it to shapes. - The dynamic offsets do not accept zero radius; they snap it to +/- 0.25, so you cannot do an exact copy of the original. Why this limitation? I tried removing if (fabs (offset->rad) < 0.25) offset->rad = (offset->rad < 0) ? -0.25 : 0.25; in sp-offset.cpp but then setting zero radius caused the program to freeze. Is this a limitation of the algorithm? _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

3 2

Re: [Inkscape-devel] Snap Control
by bulia byak 14 Jan '04

14 Jan '04

>Technically, while it's in the user manual, the user manual is in >French, and the English translation is very incomplete. Also note that >the manual was written for Sodipodi rather than Inkscape, so does not >yet address the new user interface, etc. I think it would be easier just to start over using Wiki. Whenever anyone has got a good idea (not necessarily 100% complete or even correct) of how some command, tool, dialog etc works, just take a couple minutes to visit Wiki and share your knowledge (on a page under User Documentation Scratchpad). Or when you have nothing better to do, edit and unify other's notes, add screenshots, etc. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

6 5

RE: [Fwd: RE: [Inkscape-devel] Re: new offset commands]
by bulia byak 14 Jan '04

14 Jan '04

>I wonder though if it should keep the inverse and also have a black >border with an outer white border. It is much better, but still gets >lost sometimes. Thoughts? The outer white border, like on the mouse >pointer helps sooo much to pop out small nodes against dark colors. Double borders? Hmm, that's something even Inkscape cannot handle without some additional coding... Still, consider that we now have an edge over both Xara (which has inversion but no border in its knots) and Illustrator (which has border but no inversion). _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0