October 2004 - Inkscape Devel

Removing duplicate nodes from Potrace
by Bob Jamison 18 Oct '04

18 Oct '04

As pointed out to me last week by Bulia, I was incorrectly reading the path_t information produced by Potrace, and putting it into the d="" attribute of a <path> node. Potrace's own SVG generator uses a duplicate curve on "internal" subpaths. One is used for the reverse-winding to produce a "hole" in the filled area, and another is used to provide opacity to that hole. Since we are not using the information like that, and are only concerned with the curves, it is best to remove the redundant subpaths, which we are now doing (as of today). Now the traces go faster, look better, create fewer nodes, and are thus easier to edit and drag around. Bob

1 0

Get rid of spammers
by Gazal, Geraud (GE Healthcare) 18 Oct '04

18 Oct '04

Hi all, I haven't got some much time to work as much as I would like to on Inkscape. But I try to read mails from development and user ML, plus get a look at evolution of bugs, RFE and CVS on a daily basis. I also try to check wiki updates as often as possible. And each time I consult wiki, i face the same problem : I remove at least 3 or 4 spams a day !!! It's my modest contribution, hoping developpers don't get that much annoyed by the spam. But I think that spam removal is only an emergency solution. I'm not sure is can last for long. First because spam (and its removal) break the history of the wiki modification. Then because I'm not sure that this wiki janitor tasks have a real added value. If I remember well, spam nuisance had already been discussed on this ML a few months ago. I think it is time to think about it once more. Spending some time on this issue now, will save some (stupid) waste of energy in the long run. If I remember well several solutions had been issued but rejected : - post by registered members : main drawback = loss of the direct contact with potential users - confirmation message + non computer readable question = not convenient for people with vision problems. ... Regards, Matiphas

3 2

apply transformation
by David Christian Berg 18 Oct '04

18 Oct '04

I remember that back at the split from sodipodi there was a menu item "apply transformation". This never really worked, but it would be great to have it because the librsvg can't really handle objects with gradients that have a transformation, so far. I'm not sure, how it would handle rotated rectangles, though, since these would become paths, if you'd actually apply the transformation this transformation. Maybe a dialog should be shown. What is the status on this, and what do you guys think?

4 8

Inkscape overview training tutorial
by Cédric GEMY 18 Oct '04

18 Oct '04

Hi, I've added at http://www.le-radar.com/?articles/drawinginkscape a little beginners training tutorial that is made to join the User Manual. Thanx for giving your mind about it. Cedric

1 0

text on path
by David Christian Berg 17 Oct '04

17 Oct '04

Behaviour stuff: ok, sure I love this function, even though usually I don't need so far, but there are some things about it that are really strange: - the menu item should be grayed out, as long as not a text _and_ a path are selected - once I put the text on the path, I can move it around, but it's still dependend on the shape of the path. - while I can move the text around, I can't move the path without the text following my suggestion: don't make the text movable and make the path visible if the text is selected, as a blue line or such, so that even when the path is invisible, you can easily edit it. RFE: - alignment (right, center, left, justify) of the text should apply in a way as that the path is the whole line - put text not only on a path but also with a offset, underneath and centered... you know... :) Guess I'm writing nothing new, but I'm excited about this new feature David

3 5

Proposal: get rid of bbox coords for gradients
by bulia byak 17 Oct '04

17 Oct '04

In SVG, when an object uses a gradient fill, there are two ways to specify the points that define the gradient position (two ends of the vector for linear; center, focus, and radius for radial). First, you can use userspace coordinates which are just regular coordinates in the document space, much like any other coordinates that govern the placement of objects. And second, you can use bounding box coordinates which are relative to the bbox of the object that uses the gradient; for example, the point (0.5, 0.5) will be at the center of its bbox. These two coordinate systems are functionally equivalent, i.e. there's no gradient that can be expressed in one system and not the other. Obviously, bbox coordinates are more convenient for those who read/write SVG manually. For an interactive editor like Inkscape, however, bbox coords are a nightmare. The reason is simple: for arbitrary transformations of arbitrary objects, you cannot predict the bbox after transformation, because it depends on the shape of the object. A simple example: a circle and a square, with equal bboxes, are both rotated 45 deg; now their bboxes are very different. This means that if both use a gradient with bbox coordinates, the gradients will be displaced differently relative to these shapes after the transformation. With userspace coords, however, you just multiply each gradient point by the same transfomation matrix, and the object is transformed along with its gradient as a whole, without any displacement or desynchronnization. So, when I decided to sanitize gradient handling, the first thing I did was write a function that translates a gradient from bbox coords to userspace coords. This function is now called whenever you transform an object with gradient. Without this, it would be impossible to implement the "transform with object" switch which now works reliably for any shapes or paths, in both "preserve" and "optimize" modes. This means, however, that gradients with bbox coords can only survive so long as you don't transform their users. Now, initially my plan was to add a reverse function to convert userspace back to bbox (relative to the object's new bbox, of course) after the transformation, if initially it used bbox coords. This is the least intrusive approach, but the more I think about it the less I like it. This adds more complexity to the already quite complex system of adjustments and compensations that fires every time you transform something. And more importantly, it's just useless. Bbox coords offer no advantages whatsoever in an interactive application; they just make things more complex and potentially confusing to the user. So, now my plan is: - Do not convert gradients to bbox coords ever, only from bbox to userspace (as now). - In Fill&Stroke, remove the "Coordinates" switch from the gradient pane, and make it always create gradients with userspace coords. This switch has no visible effect anyway, so it is likely to be confusing, especially for novices. In other words, the ability to _show_ bbox coords remains, but I plan to remove the ability to _create_ them, and they won't be preserved when you transform things. I have found only one situation where userspace/bbox makes a difference: Paste style. Consider a rect with a vertical linear gradient, black to white. Copy it and paste the style (Ctrl+Shift+V) to another rect which is below the first one. If the coords were bbox, then the new rect will also be black-to white in its place. If the coords were userspace, however, the new rect will be all white, and its black-to-white transition will be outside of its shape, in line with the old rect above it. As for me, I do not consider this a disadvantage, because I often need exactly this behavior (i.e. I want the gradient to stay unmoved relative to the canvas so that the new objects "continue" it) and rarely if ever need the other behavior (where pasted gradient is moved to the position of the new object). Others however may have different preferences. There may also exist advantages to bbox coords that I'm missing. Hence this call for opinions; please put forward your thoughts on this. If there's no opposition, I'll proceed with the above plan.

5 9

Circle/ellipse tool behaviour
by Lucas Vieites 17 Oct '04

17 Oct '04

Hi, I'm having a strange behaviour of the circle/ellipse tool with version 0.39. The thing is I used the tool to create a segment the other day and now every time I want to create a circle it's only possible to create a segment or an arc. The nodes are open by default. How can I turn it back to a normal circle? Thank you for your attention, -- Lucas Vieites Fariña Dept. Desarrollo <lucas@...212...> Asix Informática <http://www.asixinformatica.com/> Tel/Fax: +34 986 54 26 98

5 4

screw up importing some svgs
by David Christian Berg 17 Oct '04

17 Oct '04

Ok, I've been running into this problem for quite a while... I have some files, I based on svgs exported with corel. So now everytime I import them into a new document they are huge, huge, huge. I don't really consider it a bug, since once I import them, scale them down and save it'll work fine.. also graphics directly created with inkscape work fine. If I just open them, they show the right size as well. It's just kinda annoying, you know. I've a file attached so you can tell, what I'm talking about. David

1 0

SPRect attributes
by David Christian Berg 17 Oct '04

17 Oct '04

I hadn't noticed this dialog before, but it's totally useless, isn't it? the position and size are given in the transform dialog and RX and RY are given in the rectangle toolbar. Actually it's rather confusing because I don't understand the values shown. David

1 0

clean up defs
by David Christian Berg 17 Oct '04

17 Oct '04

After doing "clean up defs" the gradients will still show in the gradient selector (with their name, but with this black and white pixel preview) until I create a new object. There should be a update before that imho. David

2 1