CALLIGRAPHY TOOL: Tool should allow for ink dots / dotting

[Troy James Sobotka]

The calligraphy tool attempts to emulate a real-world artistic tool. As such, it should allow for touch down / dot. Currently the behavior is exemplified by touching with a tablet and nothing appearing on the surface. This would be the same as a single click with the tool without moving the mouse. Traditional ink based calligraphy pens will leave a dot / line depending on nib width. This is important to allow for dots and flourishes that are almost impossible to achieve by click-drag behavior.

Suggested Behavior: Touch down on tablet or single click on mouse should leave a dot based on pen width / cap variables / etc.

[AVazquezR (ameliovazquez)]

Hi,

I am also highly interested in this feature. I do a lot of handwriting on Inkscape using the caligraphy tool and I need a quick way of inserting dots with it.

It would be great to have something like the Ctrl-click feature that the pencil tool has, or as the first author suggests, to allow the user to leave a dot with a single click on mouse or touch down with the tablet.

This feature would be very useful for those of us who use Inkscape to hand-write notes :).

[James Jong (ribonucleico)]

Same here. This would be incredibly useful! (and it sounds like it is easy to make this change to the program)

[James Jong (ribonucleico)]

Hi,

I know that this thread has been classified under the "wishlist" category, but this is really the way the tool *should* behave. I don't have experience developing for Inkscape but I would be happy to fix this feature myself if somebody points me to the location file in the code repository where the changes have to be made.

It seems that this is something that should not be that hard to implement! :)

Thanks

[ScislaC (scislac)]

Hi James,

The file you'd be looking for in our repo is src/dyna-draw-context.cpp (and possibly .h depending on your changes). This is the file that handles the logic for the calligraphy tool. Good luck!

Cheers,
Josh

[Troy James Sobotka (troy-sobotka)]

I'd have to agree with @James Jong on this front.

The freehand tool does this.

It seems entirely illogical to not respond when the user touches the stylus to the tablet.

The result should reflect the width / shape of the stroke in conjunction with the pressure applied.

This isn't as much of a wishlist in the traditional UI sense as the point when the individual is _touching_ the tablet, they are requesting response. One could take a similar view with the mouse click.

In short, 'nothing happens' shouldn't likely be the response.

[Gabriel R (gabriel-rosser)]

I also agree with @James Jong - I discovered this problem shortly after acquiring a new tablet. It's a shame because the calligraphy tool is probably the most natural to use with a tablet (its response to pressure feels just right) but this limits the user to a certain minimum size of dash/dot which is unnatural.

[MickM (mick-mueck)]

Please add me to the list. Not being able to do handwriting using the calligraphy tool on a graphics tablet is extremely annoying!!

[Yifeng Mu (nicholaelaw)]

So this feature is still unassigned? I got my Intuos 4 today. Love the calligraphy tool in Inkscape, but unable to "dot" kinda sucks.

Eagerly awaits the fix.

[adam (adam-glibbery)]

As short lines are ignored I'd like the functionality that short lines result in circles of diameter equal to the line with at the starting point of the line. I'd prefer this over using the Ctrl because I touched the pen on the tablet surface on purpose so there is no need for a modifier key.

Fingers crossed on seeing this bug fixed, the calligraphy tool is one of the big sellers for me on Inkscape.

[Richard Brown (rgbrown)]

@adam: I'd really rather this didn't happen. I'm trying to draw mathematical diagrams freehand using my tablet pc. As soon as I try to write something too small the minimum length "feature" bites me. But I'd be equally annoyed if it turned into a circle!

[adam (adam-glibbery)]

I was suggesting a circle in that very short lines will have less information with which to decide the direction so if an instantaneous tap was to make a zero length line with end caps then what direction should that line point? A circle gets round this question. I would add two points to my previous suggestion:
1. The length of the line before it is replaced by a circle is set by a slider (such as the pen mass slider). A setting of zero would allow the random direction pair of end caps that I assume that you want to see (perhaps an indeterminate direction is set to horizontal?)
2. The radius of the circle comes from the largest pressure observed before the pen is released.

[Troy James Sobotka (troy-sobotka)]

Egads.

It is called the Calligraphy Tool.

Calligraphy quills will mark a surface when touched. As do othet materials.

This tool doesn't. Judging from the length of time this issue has been around, it likely will never change.

Enough said.

[Scott Norris (scottie-z)]

I can only join this list requesting that the Calligraphy tool act like a real pen, and leave marks no matter how small the stroke. As marvelous as this tool is, it becomes infuriating when one attempts actual handwriting.

[Scott Norris (scottie-z)]

Some relevant hard-coded constants in the file src/dyna-draw-context.cpp appear to be here:

72 #define TOLERANCE_CALLIGRAPHIC 0.1
73
74 #define DYNA_EPSILON 0.5e-6
75 #define DYNA_EPSILON_START 0.5e-2
76 #define DYNA_VEL_START 1e-5
77
78 #define DYNA_MIN_WIDTH 1.0e-6

If anyone is up for adjusting/recompiling and reporting the results, that would be helpful. My suspicion is that merely changing these constants may have adverse effects on the quality of the lines produced by the tool (one of its main selling points).

I need to read the code more closely, but from using the tool, it is clear that the initial part of a stroke is remembered long enough for Inkscape to decide whether or not to keep it. This fix could be as simple as removing a line or three of code.

[Troy James Sobotka (troy-sobotka)]

@Scott Norris:
Good find sir. I will test when I am home. I don't know if any folks with commit access are following this report. Hopefully someone is.

[su_v (suv-lp)]

> This fix could be as simple as removing a line or three of code.

A proposed fix might also include an investigation (commit logs, discussions on the mailing list, …), why those lines are part of the code in the first place, what might be the reason for the currently defined values and if indeed simply deleting one or more lines (i.e. defined variables) doesn't have any unintended consequences.

e.g.
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/2318>
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/2322>
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/2853>

and likely others…

[Allefant (allefant)]

I changed my handwriting style to make small circles instead of dots as a workaround. But I would love to see this fixed.

[Scott Norris (scottie-z)]

After more playing, I realize I was wrong -- Inkscape *doesn't* memorize the beginning of your stroke -- it simply discards it entirely. This can be seen by scribbling a very tiny circle for several seconds before ending the stroke on a long segment. The effect seems to be mass dependent -- if you set mass=0, pick a very precise starting point, and draw a line -- you will see several pixels of missing line. However, as mass increases the effect seems to decrease.

In any case, there seems to be a portion of the code dedicated to smoothing out the raw pen input in real time, and this seems to be the cause of our problem. See here, again from: src/dyna-draw-context.cpp

336 // If force is below the absolute threshold DYNA_EPSILON,
337 // or we haven't yet reached DYNA_VEL_START (i.e. at the beginning of stroke)
338 // _and_ the force is below the (higher) DYNA_EPSILON_START threshold,
339 // discard this move.
340 // This prevents flips, blobs, and jerks caused by microscopic tremor of the tablet pen,
341 // especially bothersome at the start of the stroke where we don't yet have the inertia to
342 // smooth them out.

Again, however this ends up playing out, we need to walk a fine line between preserving the smoothing of the whole curve, while reducing the effect at the beginning.

[ScislaC (scislac)]

This could be as simple as having a toggle on the toolbar for cleaner vs sloppier... this way people could have the best of both.

[Scott Norris (scottie-z)]

A simple toggle -- or even a slider for a relevant hard-coded value -- would be very welcome, although I know nothing about GUI programming and would not be able to contribute it.

However, I am an applied/computational mathematician, so I am pretty confident in my ability to write code dealing with curves in space. I will play with this as time allows; perhaps the algorithm could be tweaked so that a single parameter value smoothly connects "clean" and "sloppy" cases. Even better, perhaps a larger change to the code would allow the the smoothing to be applied everywhere except the ends of the curve.

(tangent: are "tremor" and "wiggle" sliders really necessary? See http://www.stirlingaudioservices.com/ray.htm)

[James Fisher (jameshfisher)]

The importance assigned to this is inappropriate: it is definitely not a "wishlist" item. "Features" are wishlist items. This issue does not call for additional functionality and it does not increase the size or complexity of the code-base. It is a deficiency in current functionality, and it needs fixing.

[ScislaC (scislac)]

The importance is very accurate. The tool works as designed and was intended to be implemented. What is being asked for here is an additional function that the tool does not currently provide. It's not a bug or misbehavior, it is asking for something else, and that is a wishlist item by definition. Do I disagree that it would be immensely useful? Certainly not... but that doesn't change that it is indeed asking for something new, not fixing something that is broken.

[James Fisher (jameshfisher)]

If this tool really "works as designed", that just means the design is wrong.

The calligraphy tool claims to simulate a pen [1], and a pen leaves a mark when placed on a page without dragging it [2]. That this issue is a bug follows immediately from these two facts.

My pen's ability to draw dots is not an "additional feature" (or wasn't advertised as such on the packaging). Rather it is an instance of its line-drawing functionality: specifically, it can draw a zero-length line.

Inkscape aims to implement the general case (drawing lines of arbitrary length), but the implementation fails in a specific case. Failing in a specific case is a pretty standard definition of what it means to be a "bug".

[1]: http://inkscape.org/doc/calligraphy/tutorial-calligraphy.html

[2]: try it.

[Troy James Sobotka (troy-sobotka)]

While I have the utmost respect for ScislaC, I must concur with Mr. Fisher's assessment here.

Sadly, this bug report has wandered on for far too long. The endless cycle of commentary repeats a pattern well familiar pattern within Libre software.

As the individual that registered this bug report four years ago, I'd like to encourage it to be closed.

[ScislaC (scislac)]

James: I don't disagree in certain ways... but it does work as designed, it's just poorly named if it can't really mimic the real world functionality of something with the same name. I totally agree that this is a really key thing, you can probably find discussions about it in the past where I myself was very vocal about a lack of "inkiness"... if I fling wildly or touch anywhere, ink should be appropriately on canvas. But the design of the tool was to keep it tame, controllable, and clean being the preference... is that the best way for it to behave? Completely depends on your usage. Getting it to be properly inky and to give expected results is really asking for more work, not fixing what's there. Additionally, I hope Scott makes headway as it seems like he was interested in working on it.

[JoHan (ringland)]

I'm extremely frustrated that after almost 5 years, this bug still hasn't been fixed.
How can you have a "calligraphy" tool that can't dot an i?
It's such a shame, because otherwise this tool is beautifully implemented.
Without dots, you literally grind your teeth after a minute of trying to write with it.
I beg you ... PLEASE fix it!
Or help me find where in the code I can go to insert my own kludge.
This bug is a complete show-stopper for the use of Inkscape to write lecture notes as I wish to do.

[Ben Sparks (benjamin-sparks)]

I have been searching for a tool to enable to handwrite mathematical notes... I don't want to use Microsoft OneNote (for many many reasons) but even the next best handwriting tool (Inkscape?) can't draw a DOT.

Trying to write mathematics without DOTS is a little tricky...

Please at least add an option to turn on or off 'single-pen-press' dots...!

[Joel Östblom (joel-ostblom)]

This issue is still impairing the experience with the otherwise excellent calligraphy tool in Inkscape 0.92.

I agree with Ben Sparks in that, aside from OneNote, Inkscape really is the best option for taking handwritten notes. It is certainly the best I have come across that is open source and compatible with Linux. It is unfortunate that the calligraphy tool does not support dotting, since the handwriting experience is noticeably limited by the lack of this functionality.

As suggested previously in this bug report, I believe the addition of an option to toggle the creation of dots/short path, would be a vital addition to make the Calligraphy tool work more like the physical instrument it is named after and therefore bring it more in line with the functionality expected from its users. When this option is enabled, it could watch for the same conditions as the error message `Failed to create path: invalid data in dc->cal1 or dc->cal2` and create a small stroke/circle instead of printing the error message (possibly with an additional conditional statement to only include this behavior for short stroke lengths, if necessary).

In addition to the five duplicate bugs, this forum discussion (http://www.inkscapeforum.com/viewtopic.php?f=5&t=11482) also stems from the unintuitive behavior of the calligraphy tool for short strokes.

[Mc (mc...)]

Feature added in r15658. works for a single, *non-moving* click.

[sturgman (sturgman)]

Hello! As always, thanks for all your work. Is the r15658 fix incorporated into 1.0rc1? Because I tested it out and I could not effectively dot while writing with the calligraphy tool. If it is included in 1.0rc1 I can describe the behavior I am observing now.

[Andy (zerkshop)]

Testing on v1.02, the dot is curiously small and independent of the pen width/shape. See attachment, drawing smiley faces with dotted eyes

Also I'm finding sometimes there is a delay in the start of my line such that the first part of where my pen touched the screen is missing. I'm using a Surface Pro 5 with a stylus.

Would be cool to use this as an alternative to OneNote

[Rahul Pillai (thegeekylad)]

I really don't think this is fixed yet as I still can't draw a small dot / very short line (such as a "plus") using my One by Wacom tablet the mouse. I've tried this on 3 different Inkscape versions (1.0.1, 1.0.2, 1.1-alpha) using my Wacom tablet as well as mouse (with Shift+click too) with no luck whatsoever.

Please find screenshots 1-3 on results of drawing the decimal number "2.3" across the above stated Inkscape versions and screenshot-4 on how it's expected to look like as drawn perfectly on KDE Karbon.

[Rahul Pillai (thegeekylad)]

I really don't think this is fixed yet as I still can't draw a small dot / very short line (such as a "plus") using my One by Wacom tablet the mouse. I've tried this on 3 different Inkscape versions (1.0.1, 1.0.2, 1.1-alpha) using my Wacom tablet as well as mouse (with Shift+click too) with no luck whatsoever.

Please find screenshots 1-3 on results of drawing the decimal number "2.3" across the above stated Inkscape versions and screenshot-4 on how it's expected to look like as drawn perfectly on KDE Karbon.