My first inkscape task after Friday: If a "ghost spike" is detected (i.e. if the curve goes too far from the data points) then use a sharp corner instead of a smooth node. I wouldn't expect this to have much effect on the cases being discussed here. After that, there are a couple of possible freehand changes, and also three non-freehand patches, which I'll discuss first because they're more ready, and in the hope of comments as to what stuff's worth doing when. - A simple patch adding a g_return_val_if_fail to something in sp-object.cpp. There are two possible conditions: one equivalent to what would cause a crash now anyway, or a tighter but simpler (and less random-looking) test. I'd like to check callers to see whether I can use the simpler tighter test. And get mental's opinion too. - A patch whose correctness one can be fairly confident of but whose benefits are relatively minor: - Rejecting some strings that have a valid value as a prefix, e.g. rejecting foo=nonebglx rather than treating it as foo=none. - Minor efficiency gain through using memcmp instead of strcmp (though a reviewer may prefer to keep strcmp for simpler-looking code). - A patch that makes our style string parsing more conformant, both in what we accept and what we reject. The patch more or less rewrites sp_style_merge_from_style_string, so is harder to verify correctness. We could just fix where we currently reject style strings that have lots of whitespace (caused by confusion as to whether trim_space sets *right to a length or final index) and delay applying the rewrite until after 0.40, so that it gets more testing. Back to freehand: - I have a fairly short patch that affects only the first segment of the curve (so it's helpful for short / smooth curves but no significant effect for the signature example). Its effect will improve fairly straight lines, but worsen curves that start with a sharp bend: more specifically, curves whose initial radius of curvature is comparable to or smaller than the tolerance. Actually, you can tell what its effect will be by looking at the current CVS version of inkscape and comparing the start of the curve with the end of the curve (which already has this modification). See below for comments on tolerance setting. - I have a larger, unfinished, patch that delays committing a curve until we have two (or more) curves' worth of data points. This patch would approximately triple the CPU cost of freehand drawing, in exchange for a small improvement in curve fidelity. That improvement can be built on if we use more sophisticated maths for curve estimation (for yet more CPU cost, as well as of course development effort). On the subject of the default tolerance setting: I really think the ideal tolerance would be a function of pointer speed. (I'm not commenting on how worthwhile it would be to implement this.) The thinking is that if one is moving fast then clearly[*1] one is not paying much attention to the exact position of the pointer, so we can use a larger tolerance and get smooth curves (assuming smoothness is considered good). If moving slowly, then it may be that one cares about the position, or maybe the user's just resting the pointing device, so we shouldn't make the tolerance too small, but at least it needn't make allowance for the broad-strokes case. [*1]: Exception: if using a tablet and tracing around a physical object (e.g. the templates used by architects when using pencil on paper, or tracing something with a distinctive shape, for use as line art). Some experimentation would be needed as to the right function, and we'd want, say, two parameters instead of the current one. That should be enough to adjust for different people's thinking speed (which may differ markedly if on medication, and I'd guess in other cases too, though I wouldn't know). pjrm.

On Wed, 2004-11-10 at 01:41, Peter Moulder wrote: Yes. Unless you have a compelling reason (i.e. order-of-magnitude performance improvements as demonstrated by profiling), please don't. n.b. I'm also decidedly uncomfortable with macros, especially those that reference local variables. Makes later refactoring painful. -mental

On Wed, 10 Nov 2004, bulia byak wrote: No, it's only about 12 days old. I'd try it against CVS but I'm still working on the code. I found that if I set the pencil tolerance to about 2.75, it works a bit better, although I still obtain better results from Sodipodi. Bryce

As I understand, the underlying code for this has changed considerably. Btw, I tried it against code from 3 days ago, and still get better results from Sodipodi. I'm using a mouse btw, not a tablet. With the 2.75 setting, the results are closer to being correct but the issue is that now the benefit of smoothing isn't there so the results look jagged and sloppy in comparison to Sodipodi. I've tried this both with Inkscape and Sodipodi at their default initialized window size, as well as maximizing and drawing as large as I can, but it doesn't really make a difference. Also, I notice that when drawing with Inkscape, occasionally there are these flashes as though a line is projecting across the screen to the border. Bryce On Wed, 10 Nov 2004, Jon Phillips wrote:

On Wed, 10 Nov 2004, bulia byak wrote: I have no intent to do any changes to this piece code. I don't ever use the freehand drawing tool; my goal was simply to understand the complaints that people voiced, and provide some feedback. I'm sorry to see the feedback being dismissed as useless. Perhaps the changes in 0.40 and the default setting will be sufficient to settle the complaints. Bryce

Exactly. It was useful to demonstrate that the needs of people may be very different, but it's likely to not be useful to try to persuade each other that one particular set of requirements is more important than the other :)

On Wed, Nov 10, 2004 at 11:08:00PM +1100, vellum wrote: They do use different code in some respects. Is that for calligraphic tool or for pencil tool? The pencil tool in current CVS should be producing smooth nodes; indeed at present it never produces corner nodes, though we intend to change that before 0.40, so that it does use corner nodes if a smooth curve doesn't fit closely enough. Can you confirm that you're using current CVS? Perhaps wait for a week before replying, in the hope that I commit one or two things (see another of my posts in this thread). pjrm.

The handles of the node are collinear, that's what makes the node smooth. If the handles do not rotate together in the node editor, that's a problem with the node editor which we must fix. Surely making them symmetric adds smoothness. But I'm afraid that making them symmetric while drawing would make the line too distorted (i.e. too far from the line you drew) and "jerky" as you describe below. We might try, however. If by "jerky" you mean that calligraphic is closer to the actual line you drew, then yes. But I think the purposes of the two tools are different. For calligraphic, I need exact reproduction of my movements, with all trembles and wiggles, because that makes calligraphy look natural. With freehand, I usually need to draw some abstract geometric shape, and here I need it to generalize and smooth my drawing, much as it does now. The problem seems to be that when people draw on too small a scale (like Bryce did) it generalizes out the essential elements of the line rather than the artifacts, and that gives the impression of jerkiness. I draw on a larger scale and faster, so for me this generalization works very well.

Can you show a sample of corner nodes produced by CVS freehand tool?

As I explained in this thread, this is a problem with the node editor, not with freehand tool. You might want to file a bug for it, or try to fix it yourself (it's simple; when loading the path into SPNodepath, just consider the node smooth if its handles are collinear and there is no sodipodi:nodetypes).

On Thu, 11 Nov 2004 08:58:06 +1100, vellum <vellum@...68...> wrote: i.e. from diamond to square not really a bug, just that we don't have a visual indication for symmetric nodes. You can file a RFE. Calligraphic tool has no nodes. Node tool works with any paths as paths, no matter how they were created.

That's a possible approach, but it's not elegant, because sodipodi:nodetypes would not contain any information which would not already be present in the path itself, in implicit form. So it's much better to teach the node editor to recognize node types on its own - this way it will work better with any paths, not only Inkscape-generated ones.

----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "vellum" <vellum@...68...> Cc: <inkscape-devel(a)lists.sourceforge.net&gt; Sent: Thursday, November 11, 2004 1:44 AM Subject: Re: [Inkscape-devel] Freehand drawing tool are making Bulia, have you or Peter tried making them them all symmetric? It may not be 'overkill' since although 'the curvature before and after the point (node) is constant', the final drawn curve that actually runs through the node is not a mirror image because the curve is also affected by the nodes on the opposite end of each adjacent curve segment. It may make little difference, but I'd like to see the overkill statement made on experiment rather than thinking. :-) vellum

Yes, I noticed today that decreasing tolerance makes it behave better for small curves. I will decrease the default though I haven't yet decided by how much.

Yes, top-posting is the devil... sorry. First off, I'm resurrecting this thread as I have updated information/observations from trying most of the big commercial apps to compare various functions, here's what I noticed with freehand drawing. In all of the commercial apps, they lay down placeholders of the lines you draw with freehand tools while you are drawing them. In CorelDRAW & Freehand it is just a raster line it plots and then replaces it with the vector line on mouseup. Illustrator does that for one type of drawing tool, the other uses a dotted line (like a vector line with stroke set to a decently spaced dotted pattern). And in Xara it appears that it lays down a vector line that is not antialiased, as well as it is a bit more rugged than the finished line (you see more straight segments while plotting, but they smooth out when it commits the line). What I'm getting at is that we should probably look at doing something similar with our freehand drawing & calligraphy tools to keep them more responsive while drawing. The pencil tool in Inkscape is significantly less responsive than our commercial counterparts (especially if you try long strokes... the longer the line, the less responsive we are). In fact, the commercial apps all stay just as responsive from start to finish regardless of line length, so that's definitely a reason to look into it. I think it mainly has to do with us trying to lay down the end result while it's being drawn. Is there any way we can achieve the rough/low quality placeholder lines just while drawing to keep those tools responsive? In my testing, the commercial apps are all a lot more accurate than we are (we don't compare too well at this point), with Illustrator being the most accurate by quite a bit. So, even if you say that people should just draw shorter lines to keep it responsive... it also seems like we could theoretically improve accuracy as well, as it would help give us extra time to calculate the appropriate type and location of nodes as well as more accurate curves. These were just my thoughts/observations on the subject since I'm doing comparisons of various features of the big apps with ours. I'm not thinking that any work would be done on this for a while, but I just wanted to see what others think. -Josh decided I do brush speed go is maybe

I've now had a look at sodipodi's freehand tool, e.g. looking at diffs between sodipodi 0.29 (roughly what we inherited in Inkscape) and 0.34. Between those two versions, sodipodi has rewritten the curve stuff, e.g. changing the behaviour according to how long has elapsed since the last movement event. Thankfully, Inkscape's & sodipodi's changes are complementary: we can incorporate sodipodi's additions while still benefitting from Inkscape's improvements, and similarly I can notify sodipodi list of changes in Inkscape that they may consider incorporating into sodipodi. I suggest that we're too late into 0.40 to add a bunch of new code, so this will have to wait for 0.41. pjrm.