Announcing Inkscape 0.40 Release

Gradient nodes will be moved to the canvas (adding a new Gradient tool for manipulating them). The dialog will only be used for selecting the color vector and other options. This way adjusting gradients will be much easier. That's been in our plans since the fork, and we're getting there slowly.

The gradient vector editor (where you set the stops) will likely be redesigned too.

As for rotating by 90, there's no single button, but you can snap the angle at 15 deg increments when dragging a gradient node with Ctrl.

There is a tutorial to make your own markers somewhere in the share directory (I think in share/markers, not share/doc). With this you can improve the situation (I did) but it seems the problem cannot be solved because it is a limitation of the SVG format:
You have the line and on top of it you define the marker. The problem is not the marker, but the line that cannot be "pointy". So as said another post, when you place the marker so that its point is touching the control point, the line appears under the marker and your arrow does not appear pointy any more...

I am replying to myself here...
Go to share/markers and add the following svg code

This is a modification I made of the arrow1L (large) which is not perfect but is an improvement. It appears as niceArrow but you can of course give it the name you want (Arrow3L should be better).

oliv.

(sorry if I break the layout of the page)

I am sorry, but the svg code I had pasted in the message go eaten and lost by Gnomedesktop...

Here is how to generate it.
1- open the marker.svg file in a text editor.
2- copy the paragraph corresponding to the Arrow1L marker. It should be around line 620, and is contained between "marker" opening and closing tags.
3- paste it underneath in the file
4- in the pasted version, replace the Arrow1L by Arrow3L
5- replace the sequence:
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
by
d="M 12.5,0.0 L 17.5,-5.0 L 0.0,0.0 L 17.5,5.0 L 12.5,0.0 z "

6- Save and reopen inkscape. You should now have a Arrow3L available, what is somehow more like what you want.

Optionally, you can change the stroke-width:1.0pt to 0.0pt, but then the previously mentionned issue with the line being visible underneath will appear.

oliv

Thanks a lot for the help. I'll try if your solution is fit for my problem.

Isn't it possible to 'automatically' shorten lines if a marker is attached, or does this have other severe disadvantages?

Martijn

I am not an svg expert, but I did not see something like that in the svg spec:
http://w3c.org/TR/SVG11/painting.html

I may be missing something...

oliv

Yeah, when we set up this feature we were also a bit disappointed at how it turned out. The reason is that if we put the connection point at the tip of the arrow, then you see a bit of the end of the line too, and the arrowhead isn't "pointy".

Unfortunately, like you noticed, our solution isn't that great when you're making technical drawings. There's a few other features necessary to make Inkscape useful for doing technical drawings (such as wrap-text-in-box, snap-to-object, etc.), and those things are being planned.

Markers have several issues against them, and needs some attention, but unfortunately we don't have anyone working on this right now. If anyone would like to work on it, though, we'd love the help.

Bryce

Is there a bug report on this?

For subscript and superscript try Alt+Up/Down arrow keys befor the character you wnat to shift.

But that doesn't do "true" sub/supercripts because you also need to decrease the font size.

Bitmap tracing, that's exactly what I need! I regularly scan things that I drew with my pencil, and color them on the computer. I used to use autotrace (which claims to produce better results than many commercial traces) to convert the lineart to smooth vector lines, but potrace seems to be even better!

You weren't experimenting with the newly-enabled 1024-point randomized curved stars, were you? Yeah, those take a while to draw, for obvious reasons.

I'm using this in Ubuntu Hoary (packages from Ubuntu) and it feels just as fast if not faster than previous releases. Are you using those static builds maybe?

Static, should work _faster_ then dynamic linked. How fast is your pc? Probably fast enough to make this difference minimal. 0.39 was _a lot_ faster, now it crowls.

Yes, static runs by a few % faster than dynamic for me. But both are a bit faster than 0.39, not slower. Something is wrong here. If you are interested in helping us resolve this, please open a bug in the Inkscape tracker with some measureable test case, such as

$ time inkscape tutorial-basic.svg
(ctrl+q as soon as it loads)

and the numbers you get for 0.39 and 0.40. We'll then be able to compare this to other people's results and to further investigate the issue. Note that there were no reports of excessive slowness during the 0.40 testing cycle.

well... that's a false alarm. Potrace generates very complicated views with millions of nodes. Thats the reason. 0.39 with such 'potraced' svg runs similarly. Sorry about inconvenience. And please, announce next time, that 'very dangerous toys are included in this rel.' ;)))

Some numbers:

0.39
min.
real 0m2.852s
user 0m2.552s
sys 0m0.128s
max.
real 0m3.032s
user 0m2.588s
sys 0m0.117s

0.40
min.
real 0m3.269s
user 0m2.765s
sys 0m0.163s
max.
real 0m3.397s
user 0m2.790s
sys 0m0.134s

sys details:
kernel 2.6.8.1-ck9
glibc cvs head
gcc 3.4.3
xorg 6.8.1. radeon dri

pc:
duron 1300
512 mb ram
udma 100 40gb ide

inkscape:
--with: mmx, xft, gnome-print

Thanks, that makes more sense. 0.40 has no reason to be much slower than 0.39 on the same files. However, this does not mean that the current performance is good. It's satisfactory for average files, but degrades heavily for "special" circumstances such as high zoom or many nodes in a path. So we are going to spend more effort on optimization for 0.41, and I hope the next version will be significantly faster.

While I don't know a whole lot about C++ programming, I've read in quite a few places that the performance of a C++ app can be improved by changing the 'visibility' of symbols. It looks like most of the improvement with this is in startup time, but it certainly can't hurt (can it?) The downside is that you need a very very new version of GCC to take advantage of the speed-up.

I can honestly say I don't know what I'm talking about here, but it sounds good.

Well, you are almost right :-) In c++ symbols are visible or not. Most parts of an app are only internal and "outside-apps" don't need to know about it. But if you link an app with another you need some parts to be visible.

Up to gcc 3.4 _all_ symbols have been visible. In gcc 4.0 you will be able to disable the visibilty per default and explicitly enable some symbols. So means that eg. only 10000 instead of 1 million symbols are visible so that linking is faster and you get less linking-problems (same names of symbols).

But this also has some problems: You need to go through your code, this consumes a lot time. You might break outside-apps. gcc 3.x.y doesn't support this (the patch is backported for gcc 3.4 but it does not work as good as in gcc 4.0 and will never be in the official gcc 3.4).

KDE just switched to visibility=hidden per default and will therefore hopefully be a bit faster in compilationtime and startup. Furthermore, the binary-size decreses. How much? Different. But probably some %.

I hope this helps.

I found one thing so far that's a lot slower than in 0.39: showing the fill and stroke dialog. It used to show up instantly in 0.39, now it takes a noticeable time to load after it's closed (close to 1 second). It gives a laggy feel to the application. Other dialogs show up as usual, quickly enough.

Otherwise: great job! I love this program :)