Calligraphy pen: optionally rotate tablet tilt by 90deg

Bug #172219 reported by Dmounty
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Inkscape
Confirmed
Wishlist
Unassigned

Bug Description

In the past I have used a fountain pen with a broad nib for calligraphy.
With such a pen, strokes in the direction the pen is inclined are thickest
and perpendiculr strokes are the thinnest... That's to say if the paper is
flat on the table and the pen is inclined downward and directly away from
you, a left/right stroke will produce the thinnest possible line and a
forward/back stroke will produce the thickest. This is however the opposite
of what happens when I use my (tilt sensitive) graphics tablet. I'm not
sure if this is a bug per se, but it could be rectified by providing a
toggle button to provide a 90 degree rotation of the calligraphic brush
(with respect to the tilt reported by the pen). That way the behaviour
could match that of a fountain pen or it could be left in its original
state. I'm guessing this would not be tremendously difficult to implement.
Good luck!

Tags: tablet ui other
Revision history for this message
Dmounty (dmounty) wrote :

Originator: YES

PS: I understand that if you use an italic felt tipped pen for calligraphy
then the nib is oriented perpendicular to that of a fountain pen and hence
the calligraphy tool works are expected. I guess a toggle to go between
italic pen and fountain pen mode (as I described) would be the most
flexible option, as for which should be the default... that's a matter for
debate.

Revision history for this message
Buliabyak-users (buliabyak-users) wrote :

Originator: NO

Just to clarify, so you are using Inkscape with a tilt-sensitive tablet
pen and the direction of the nib is not what you expect?

Revision history for this message
Dmounty (dmounty) wrote :

Originator: YES

Yes, that's correct, the nib is rotated 90 degrees from what I'd expect of
a fountain pen (and that's the picture on the icon).

John Cliff (johncliff)
Changed in inkscape:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
meientau (jan-schormann) wrote :

I, too, would expect the nib to be 90 degrees different from the result in Inkscape. Note that this is not merely a matter of surprise, it makes the difference between useful or not for writing classical scripts.
Could the value in the nib angle input field (labeled "Angle:" in English locale) be added to the value calculated from the tablet pen tilt? That way,
 - there is no need for an additional check box
 - users can have it their way
 - and you could even simulate a slant-cut nib fountain pen, as used by left handed people for classical scripts.
(Even if this isn't the right place for that: Inkscape is among the most marvellous tools I know! Keep going!)
Inkscape 0.46 + 0.47pre3, Wacom XD-0608-U (Intuos 2 DIN A5), Windows XP SP3

Revision history for this message
meientau (jan-schormann) wrote :

I thought I'd try and use the source, followed the instructions for the Win32_Port, and picked something from launchpad using bazaar, so it's probably head (see the date of this post).
What I found by adding some debug output in the tilt code in src/dyna-draw-context.cpp:363 (in the usetilt part of sp_dyna_draw_apply()) is that dc->xtilt and dc->ytilt only ever have values of 1 or -1.
The result *looks* as if the nib was wrong by 90 degrees *if* you hold the pen in certain positions, e.g. conveniently with your right hand, but some other tilts give strange results. Holding the pen straight up/down, for example, makes the angle flip back and forth between 45 degrees and 135 degrees, both of which are "wrong".
 - Is it possible that this only occurs for certain versions of the tablet? My tablet seems to work fine in Photoshop 7, for example. Do they have a workaround for a driver or hardware bug?
 - Am I the only one who observes that tilt has deterministic but completely arbitrary effect on the nib angle, or can someone else reproduce this behavior?
 - Would it help if I would use screen shots / drawings to explain what I mean?
 - Do you have a hint where I should continue to look for the cause, i.e. the calculation/origin of dc->{x,y}tilt, or is the 1/-1 value OK and I'm on a wrong lead?
I'd love to contribute by solving this issue - if it is seen as an issue, that is.Hence I'd be grateful for any hint!

Revision history for this message
meientau (jan-schormann) wrote :

I don't think I'm quite ready yet to really join the project, so I don't really know what I'm doing here - please give it a thorough review.
However, the patch works fine for me and is rather short, so maybe someone can give it a review and it might just go into 0.48.x?
That would be soooo cool.

The attached patch contains 2 distinct issues:

1.) As stated above, dc->xtilt and dc->ytilt behaved strangely for me.
NOTE: I did not observe the strangeness in a vanilla 0.47 installation, and I don't understand where the values come from, but:

In the latest version I got from the repository, the values read from the tablet have a range from about -900 to +900 (I assume it's really meant to be -1024.0 to +1023.0 as found in the Wacom docs), but are then (in sp_dyna_draw_extinput()) CLAMPed to [-1...1], which isn't very helpful.
Why divide by 1024? To retain the full resolution, the resulting value should always be smaller than the clamp limits to prevent cut-off, but I assume the values will never be above 1024 (absolute).

2.) More to the original point of this report: to calculate the final nib angle, I just add up the fixed part and the part calculated from the tilt. Thereby we gain the flexibility of defining the angle between the tilted pen and the nib, just by entering a value in the nib angle input box.

I would now like to be able to not disable the input field for the fixed nib angle, because it is now still valid even if tilt is active. But I don't understand the code in toolbox.cpp, if that's the right place at all.
Also, I'm not sure how to train/explain the fact that there is a difference on how pressure is used to calculate width, and tilt is used to calculate the angle, but I really strongly believe that this behavior is more like "what you want".

I know that's a far shot - how would I go about to get feedback on whether other people support this change or not?

Revision history for this message
Juha Lento (juha-lento) wrote :

The importance is marked as "wishlist"? This is a bug. Writing (classical) calligraphy using stylus tilt is incorrectly implemented.

Fortunately this is trivial to fix. Quick fix is to swap x and y tilt axes in the calculation of the angle. The possibility of adding a fixed angle to the angle determined from the stylus tilt, as suggested earlier, is also an easy and more general fix.

Revision history for this message
Juha Lento (juha-lento) wrote :

Correcting myself, swapping x and y axes does not work, of course. Adding 90 degrees to angle as currently calculated does.

Revision history for this message
Juha Lento (juha-lento) wrote :
  • d1 Edit (1.2 KiB, text/plain)

Looks like there are two issues.

The first is the scaling issue as pointed out by meientau. That is quite clear.

The second is that x and y tilt axes are swapped. I did not check where that originates from. If opening "File->Input devices..." and from there the "hardware" tab, looks like the axis are listed in the order

axis 1: x-coord
axis 2: y-coord
axis 3: pressure
axis 4: y-tilt <--!!!
axis 5: x-tilt <- !!!

Anyways, the attached minimal fix below (thanks meientau) works for me.

Revision history for this message
meientau (jan-schormann) wrote :

@Juha Lento: Thanks for looking at the patch and verifying the idea!
@John Cliff or ~suv: Since we have another vote and even a vote for the patch, and the patch only has a few lines, is it possible to promote the importance and add the patch to the next bugfix release with little bureaucratic overhead?
Thanks everyone and my best seasonal wishes!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.