pen issues of Ipe 7.0.12

Here are the remaining pen bugs and issues all gathered together in this
one spot:


1) Pen does not make dots

The freehand-tool needs small initial movements of at least 2 pixels to
activate strokes. Just touching the screen does not make dots, as is
desirable for the dots over an i or full stops.

The bug always shows, independent of driver and input method (mouse,
external tablet, or tablet-pc). The cause should most likely be found in
the initialization routine of the pen-strokes.

---


2) Pen cursor should be a dot

With the freehand-tool the cursor should be a small dot instead of the
standard mouse-arrow. This is the natural setting for handwriting
because the arrow is visually too distracting during writing. The dot
width and color should be the same than the stroke (line).

If stroke erasing gets implemented, an eraser-cursor should be chosen
for better visual feedback.

For all other drawing functions the arrow-cursor is usually a better
choice and should be left as is or be offered as an option.

---


3) Last stroke always marked red

The red marking of the stroke is distracting during handwriting and
should then be disabled. The pen color should always be the chosen line
color during writing.

The marking of pen strokes is only helpful during stroke erasure, if the
selection tool is chosen.

---


4) menu item 'Fit page width'

Page width is missing in the menu and on the edit toolbar. This setting
is the normal one during handwriting. It should be there with a few
pixels margin on both sides of the paper for visual feedback.

---


5) Status bar, minor haptic issues

There should be a little bit more spacing in the coordinate window for
better separation and visibility of the coordinates. The window and
number positions should be formatted to prevent jumping when the
magnitude changes.

The tool feedback on the status line should stay permanent during
operations as it was before. It now goes away after 1-2sec, which is too
short.

---


Background and feedback issues:



6) Former pen-cursor offset error now gone

The previous versions showed a very annoying pen-cursor offset error of
3-10 pixels between cursor and actual stroke if used with a pen on a
tablet-pc under winXP and Linux, which is now gone. This was apparently
caused by a faulty wacom driver, which returns the cursor position in an
integer screen pixel format and additionally as floating point values.
The floating point values apparently had not been corrected with the
calibration values. This bug did not show, if only integer coordinates
were used by the external programs.

The latest wacom driver seems to have fixed that. It also seems, that
this wacom driver writes calibration data directly to the wacom chip.
This driver works under ms-windows only. It seems that you have to run a
calibration under windows first, to then get the then corrected
coordinates under Linux as well, even with the Linux driver.

I always had calibration issues under Linux, which went away after I ran
the wacom calibration routine under winXP first. The driver might
probably work under wine, if you don't have Ms-win installed (untested).

Just for feedback and to make you aware of the problem, which might show
up again.

See also this message in the Linux-Wacom forum for further info:

http://old.nabble.com/Re%3A-high-resolution-coordinates-td30125281.html#a30126659
Re: high resolution coordinates


----

7) Stroke smoothing

For handwriting some very light smoothing is desirable, because raw
handwriting on a tablet-PC always shows some unavoidable small micro
movements. With some very light smoothing the handwriting looks a lot
cleaner. Checked this under magnification by comparing MS-Journal, which
does this quite good, to other programs, which usually either don't or
are totally overdoing it, which is worse.

Finding the best smoothing algorithm and setting will need some
experimentation and developement and may be a major effort.

A ballistic approach (kinematic smoothing using pen speed and
acceleration as basis adding artificial momentum to the pen) seems to me
as most promising. For speed reasons this must be handled with a very
short algorithm in a few lines of code.

The usual bezier functions are missing the necessary timing information
and most likely will also be computationally too demanding in this case.
They usually smooth out sharp edges far too much, which then leads to an
unnatural handwriting appearance.

Without thorough investigation right now the freehand algorithm should
be left as is, since it is good enough after a little training.

----


8) Stroke eraser

Right now erasing full strokes with the delete or undo function works
well and makes handwriting feasible. My Tablet-PC has a non
driver-remappable ESC-key which I remapped in the lua script to the undo
function. This allows a fairly smooth operation. Two other keys, which
could be remapped, I have set as shift and ctrl modifier keys, which
works well. Full stroke erasing also works well with a small external
Bluetooth Mini-Keyboard.

A real 'killer-feature' would be a freehand eraser working on all shapes
and strokes, which to my knowledge only MS-Journal and MS-OneNote as
mainstream programs currently have, but both of these programs can not
be used for any serious drawing. It is worth however to look at these
for inspiration of how to implement this function in the future.

Under Linux erasing works very well with Xournal, but Xournal does not
have the desirable stroke smoothing and drawing capabilities.

----


9) Speed issues

Handwriting works well, but speed is marginal on slow computers. On my 1
GHz single core Motion Computing LE1600 during normal handwriting the
load goes up to 100%. With rapid handwriting it develops quite some lag,
but no strokes are lost and no other problems except the lag are seen.
Slowing down a little solves the problem. On my 1.8 GHz double core
HP2710p no lag is seen, but it then goes to full speed, which increases
heat and undesirably shortens battery life. Normally it can run with
half speed only (ACPI-setting). So in the future going to a fixed point
binary data and an optimized picture storage format for the Pen-Tool
only should be considered. Since the data handling is central for good
and clean functioning of Ipe, you should probably gather some second
opinions on this matter first.

Ipe input may also be enhanced with voice input commands, which can
control Ipe easily by externally generating the commands as keystrokes.
This can serve as keyboard replacement on portable machines. For Ipe
only a few short commands would be needed. Since voice recognition takes
quite some computing power, speed optimization would be helpful here
too. Ipe would be an excellent core for such use.

Normal drawing puts only very light load on the machines and does not
cause any recognizable speed problems here.

-----

If time allows, it would be nice if you could fix the first 3-4 issues
before the next release. Hopefully it should be quite simple and easily
be done.

Thanks for Ipe and consideration,
Gerhard