- Inkscape Devel - Inkscape Mailman

GCC 3.4 complaints
by Jon A. Cruz 19 Oct '04

19 Oct '04

I've seen these warnings when building the latest sources display/canvas-arena.cpp: In function `void sp_canvas_arena_class_init(SPCanvasArenaClass*)': display/canvas-arena.cpp:91: warning: invalid access to non-static data member `SPCanvasArenaClass::arena_event' of NULL object display/canvas-arena.cpp:91: warning: (perhaps the `offsetof' macro was used incorrectly) display/sp-canvas.cpp: In function `void sp_canvas_item_class_init(SPCanvasItemClass*)': display/sp-canvas.cpp:110: warning: invalid access to non-static data member `SPCanvasItemClass::event' of NULL object display/sp-canvas.cpp:110: warning: (perhaps the `offsetof' macro was used incorrectly) Someone familiar with the area these are in should take a look. I do think these should be corrected, just not sure of the "proper" fix.

4 4

creating a pdf
by David Christian Berg 19 Oct '04

19 Oct '04

Hi guys, I know that the standart way of creating a pdf with inkscape is using scribus. and I don't really mind. But I have a really old copy of scribus and before compiling a new one, I'd like to know, if by now it can handle transparencies and gradients for the import of svgs. I'll also ask the scribus list, of course :) David

1 0

clean up defs -- extended
by David Christian Berg 19 Oct '04

19 Oct '04

when putting some documents together you might end up with more than just one def-section and for some reason I had linked defs in front of the definitions, they were linked to. This seems to cause some weird behavior where you can't change the gradient with choosing a different one once, but you have to do so twice. Also: Gradients are mor object orientated now, which I really like. going with this, each time I switch to gradient from a solid color, a new gradient is created. This gradient should automatically deleted right away, if I don't do anything exept for switching to a existing gradient. Otherwise I'm kinde forced to do clean up defs and in the worst case I have to create extra objects for the gradients, I want to keep. I hope you understand what I'm saying... seems kinda confusing to me David

3 2

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