- Inkscape Devel - Inkscape Mailman

Status for 2004-01-15
by Bryce Harrington 16 Jan '04

16 Jan '04

Thursday, January 15, 2004 Statistics Nov 15 Nov 29 Dec 15 Dec 31 Jan 15 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 3676 2452 2444 1928 (68.5%) (73.6%) (82.4%) (82.5%) (86.1%) Max Week's Rank on SourceForge: 62 37 27 22 321 (99.6%) (99.8%) (99.8%) (99.9%) (97.5%) Total SF Page Views * 50,000 86,000 107,600 126,512 Total SF Downloads * 1700 3640 4,751 5,735 Total Freshmeat URL Hits 746 1121 2237 2567 2,958 Total Freshmeat Subscriptions 16 19 28 30 33 Lines of Code in src/: 115,901 116,970 132,134 165,664 166,914 Code lines 100,549 132,458 133,150 Comment line 11,591 12,234 12,468 Blank 20,559 21.540 21,929 Lines of Docs in doc/: 1,135 2,100 2,225 2,615 3,068 Lines of content in website: 1,173 1,624 2,090 2,261 2,885 Size of the Inkscape wiki: 3,700 5,737 7,385 11,062 11,284 Hours since last ChangeLog mod: 6 2 21 0.8 0.1 Bugs open/total: 9/15 40/51 67/111 66/130 74/160 Features open/total: 18/18 23/24 40/45 103/115 104/120 Patches open/total: 1/ 6 5/20 6/25 4/32 4/32 CVS Commits (as per inkscape-cvs): 481 963 * 1580 * Inkscape-devel membership: 49 61 64 65 64 Inkscape-announce membership: 9 14 16 20 22 * - Statistics unavailable

1 0

your nodepath changes
by bulia byak 16 Jan '04

16 Jan '04

Bob, I think your latest changes may result in invalid SVG (which is why I inserted nodepath_destroy and delete_selection in the first place). E.g.: - create a path - f2 - select all nodes but one - del - f1 The statusbar says "Path (0 nodes)", and in XML editor, you will see a <path> with an empty d= attribute. I believe this is invalid SVG, and in any case it's better to avoid such situations. Which is why I added deleting a nodepath which has only one node left. Please fix this somehow. Also, your new command "split path between nodes" gives too generic statusbar error messages. It only works for two adjacent nodes none of which is an end node of a subpath, but when some of these requirements is not met it simply says "You must select two nodes on a path". Please provide more specific diagnostics for non-adjacent nodes, end nodes, more than two nodes, etc. It might be useful to generalize this command so it would work on any number of adjacent nodes by first deleting all middle nodes and then removing the segment between the remaining two selected nodes. Your tooltip says "Split a path..." - first, it should be simply "Split path"; second, all other tooltips for node tool refer to "lines" but I believe "path" is better, so could you please edit other tooltips too, replacing "lines" by "paths"? _________________________________________________________________ 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…

2 1

UserManual
by Cédric GEMY 15 Jan '04

15 Jan '04

Adding news to the last post about the UserManual, In fact the Manual I'm working on is still be written for Sodipodi. I'm working these days on an englo-us translation. There will be few things to do : 1. Improve the translations because my english is really crap; 2. Add Special Inkscape infos to the files (or think of a complete separate manual); 3. Go on writing pages : I'v thought about a beginning tutorial that I'll be working on as soon as my translation will be given for improvement. I'm open to all kind of ideas. Cédric

1 0

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