[tegaki] Tablet support?
ulim
first of all thanks a lot for Tegaki, it's just what I have been
looking for!
After some struggling I finally got it working yesterday(just
submitted the live/git ebuild to gentoo as well). Afterwards I went to
Akihabara(Electronic town in Tokyo) and bought myself a pen tablet.
I'm a Japanese learner and used (until now) ibus-anthy as input
method. I'm hoping to replace that with ibus-tegaki in order to gain
more kanji-writing practice. The first issue I faced was of course the
absence of some hiragana and katakana characters. However, I
eventually found the thread that mentioned tegaki-train and it seems
that works fine (maybe a notice on the website about this would be
good).
Now in order to improve typing or I should say writing speed I believe
some tablet support would be nice, e.g.
1. Hotkeys for important buttons like undo/change model/send chars,
ideally mapped to the stylus or tablet buttons.
2. restrict movement of the stylus to the tegaki window so that
characters can be written anywhere on the tablet. As a result the size
of the tegaki window on the screen could be made much much smaller.
Maybe a separate "tablet-mode" could be introduced?
I'm wondering, has anyone else already thought about all of this? Or
even started on some implementation? I had a look at some sample code
for retrieving events from the tablet, that seems very easy to do. In
order to limit the stylus to the tegaki window one would probably have
to remove it as regular pointer in X and then manually draw a mouse
cursor(not sure if that's needed though).
Thanks,
Uli
--
You received this message because you are subscribed to the Google Groups "Tegaki Handwriting Recognition Project" group.
To post to this group, send email to tegak...@googlegroups.com.
To unsubscribe from this group, send email to tegaki-hwr+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tegaki-hwr?hl=en.
Mathieu Blondel
Hello,
On May 18, 9:41 pm, ulim <a.spo...@gmail.com> wrote:
> After some struggling I finally got it working yesterday(just
> submitted the live/git ebuild to gentoo as well). Afterwards I went to
> Akihabara(Electronic town in Tokyo) and bought myself a pen tablet.
> I'm a Japanese learner and used (until now) ibus-anthy as input
> method. I'm hoping to replace that with ibus-tegaki in order to gain
> more kanji-writing practice. The first issue I faced was of course the
> absence of some hiragana and katakana characters. However, I
> eventually found the thread that mentioned tegaki-train and it seems
> that works fine (maybe a notice on the website about this would be
> good).
limited because of lack of data. If a few people on this group agree
to contribute their handwriting, we can easily build a writer-
independent model though. I will prepare the list of characters to
write later.
For now, like you said, you can use tegaki-train to build your own
model.
> Now in order to improve typing or I should say writing speed I believe
> some tablet support would be nice, e.g.
>
> 1. Hotkeys for important buttons like undo/change model/send chars,
> ideally mapped to the stylus or tablet buttons.
> 2. restrict movement of the stylus to the tegaki window so that
> characters can be written anywhere on the tablet. As a result the size
> of the tegaki window on the screen could be made much much smaller.
> Maybe a separate "tablet-mode" could be introduced?
>
> I'm wondering, has anyone else already thought about all of this? Or
> even started on some implementation? I had a look at some sample code
> for retrieving events from the tablet, that seems very easy to do. In
> order to limit the stylus to the tegaki window one would probably have
> to remove it as regular pointer in X and then manually draw a mouse
> cursor(not sure if that's needed though).
Tegaki. I don't own a tablet myself so I can't help on this. If you
can program, your help is welcome !
Recently, I found myself wanting to write entire sentences with Tegaki
too and the lack of hiragana was a problem. Another key feature that
would help with inputting entire sentences would be to not only
consider the character probabilities individually but also the
character transition probabilities. I mentioned it in this thread:
http://groups.google.com/group/tegaki-hwr/browse_thread/thread/84c3c06a3339a1cd/200a724943c06f0b?lnk=gst&q=language+model#200a724943c06f0b
Mathieu
ulim
On May 18, 10:49 pm, Mathieu Blondel <mblon...@gmail.com> wrote:
> For now, like you said, you can use tegaki-train to build your own
> model.
Could you give me a hint on how to combine the handwriting-ja model
with my hiragana/katakana model so that I don't have to switch between
models anymore? I'm guessing I'd have to use tegaki-convert but I'm
not sure how.
> As far as I know, there has been no work on using a tablet with
> Tegaki. I don't own a tablet myself so I can't help on this. If you
> can program, your help is welcome !
I have implemented a new tegaki UI especially for use with a tablet.
Works with a mouse as well though, I called it tegakiOSD.
You can check it out here via: git clone http://github.com/ulim/tegakiOSD.git
If you like you can integrate it into your project.
I think it's quite useful, maybe I should make a short video as well.
I also added some kanjidic support, i.e. when you commit a character
it shows some info from kanjidic.
Unfortunately, I had to write a small C extension for the tablet
support, it seems the gtk XInput support is not sufficient.
Especially, it seems to be impossible to catch events from an
extension device while the core pointer(=mouse) is not over the
window.
However, for me the whole point is that I can write with the pen
without switching tasks/touching the mouse. Works quite fine with the
extension though.
> Recently, I found myself wanting to write entire sentences with Tegaki
> too and the lack of hiragana was a problem. Another key feature that
> would help with inputting entire sentences would be to not only
> consider the character probabilities individually but also the
> character transition probabilities. I mentioned it in this thread:
For japanese one could easily use the EDICT dictionary in order to
find likely Kanji combinations. It should be something similar as
what's used on mobile phones, i.e. where you get a suggestions after
entering a few characters. Maybe it would be worth checking out that
code, e.g. simeji for Android.
Uli
Roger Braun
> Hi again,
>
> On May 18, 10:49 pm, Mathieu Blondel <mblon...@gmail.com> wrote:
>> For now, like you said, you can use tegaki-train to build your own
>> model.
>
> Could you give me a hint on how to combine the handwriting-ja model
> with my hiragana/katakana model so that I don't have to switch between
> models anymore? I'm guessing I'd have to use tegaki-convert but I'm
> not sure how.
Essentially you can use tegaki-build to make a new model, you can see
how it is done in the tegaki-models folder. It's pretty much like
this: You create meta file for your model and the you run
"tegaki-build [sources] [engine] [metafile]", and you can use more
than one source, i.e. "tegaki-build -t tomoe-data.xml -a
kanjivg-data.xml zinnia japanese_mix.meta" would make a zinnia model
from both tomoe and kanjivg data (provided you have the files in the
same folder).
You could also try the (zinnia) model I use for
http://rokuhara.japanologie.kultur.uni-tuebingen.de:7777/test.html. It
is based on KanjiVG which contains kana.
>
>> As far as I know, there has been no work on using a tablet with
>> Tegaki. I don't own a tablet myself so I can't help on this. If you
>> can program, your help is welcome !
>
> I have implemented a new tegaki UI especially for use with a tablet.
> Works with a mouse as well though, I called it tegakiOSD.
> You can check it out here via: git clone http://github.com/ulim/tegakiOSD.git
> If you like you can integrate it into your project.
This is a great idea, but it segfaults for me.
--
Roger Braun
http://rbraun.net
roger...@student.uni-tuebingen.de
ulim
On May 28, 5:03 am, Roger Braun <roger.br...@student.uni-tuebingen.de>
wrote:
> > Hi again,
>
> > On May 18, 10:49 pm, Mathieu Blondel <mblon...@gmail.com> wrote:
> >> For now, like you said, you can use tegaki-train to build your own
> >> model.
>
> > Could you give me a hint on how to combine the handwriting-ja model
> > with my hiragana/katakana model so that I don't have to switch between
> > models anymore? I'm guessing I'd have to use tegaki-convert but I'm
> > not sure how.
>
> Essentially you can use tegaki-build to make a new model, you can see
> how it is done in the tegaki-models folder. It's pretty much like
> this: You create meta file for your model and the you run
> "tegaki-build [sources] [engine] [metafile]", and you can use more
> than one source, i.e. "tegaki-build -t tomoe-data.xml -a
> kanjivg-data.xml zinnia japanese_mix.meta" would make a zinnia model
> from both tomoe and kanjivg data (provided you have the files in the
> same folder).
have the "-a" option so I fetched your repo, installed pyparsing-1.5.2
and ran
PYTHONPATH=~/<git-repo>/tegaki-tools/src python ~/src/tegaki/Project-
Tegaki/tegaki-tools/src/tegaki-build -a kanjivg-20100513.xml zinnia
handwriting-ja-vg.meta
Unfortunately, I get pages of "Something went wrong..." messages right
from the start, probably for every character?
> You could also try the (zinnia) model I use forhttp://rokuhara.japanologie.kultur.uni-tuebingen.de:7777/test.html. It
firewalled).
Used another machine to download the file and the model seems to work
very well, thank you!
> >> As far as I know, there has been no work on using a tablet with
> >> Tegaki. I don't own a tablet myself so I can't help on this. If you
> >> can program, your help is welcome !
>
> > I have implemented a new tegaki UI especially for use with a tablet.
> > Works with a mouse as well though, I called it tegakiOSD.
>
> This is a great idea, but it segfaults for me.
backtrace? I updated the makefile to include debug symbols so if you
have gdb installed something like this should do the trick:
git pull && make clean gdb && make gdb
Then enter "run","bt",copy&paste,"quit"
Since the segfault is likely to be in the XInput/Tablet code you can
also disable that and try just with the mouse first.
To disable the one-liner patch below should work.
Thanks,
Uli
diff --git a/xinputextdev.c b/xinputextdev.c
index 5ff14a4..c802fd4 100644
--- a/xinputextdev.c
+++ b/xinputextdev.c
@@ -331,6 +331,7 @@ static PyMethodDef XInputExtDevMethods[] = {
PyMODINIT_FUNC initxinputextdev(void)
{
+ (void) Py_InitModule("xinputextdev",
XInputExtDevMethods);return;
/* Parallel access from here and python/gtk */
XInitThreads();
Mathieu Blondel
On Fri, May 28, 2010 at 4:04 AM, ulim <a.sp...@gmail.com> wrote:
> I have implemented a new tegaki UI especially for use with a tablet.
> Works with a mouse as well though, I called it tegakiOSD.
> You can check it out here via: git clone http://github.com/ulim/tegakiOSD.git
> If you like you can integrate it into your project.
> I think it's quite useful, maybe I should make a short video as well.
> I also added some kanjidic support, i.e. when you commit a character
> it shows some info from kanjidic.
> Unfortunately, I had to write a small C extension for the tablet
> support, it seems the gtk XInput support is not sufficient.
> Especially, it seems to be impossible to catch events from an
> extension device while the core pointer(=mouse) is not over the
> window.
> However, for me the whole point is that I can write with the pen
> without switching tasks/touching the mouse. Works quite fine with the
> extension though.
That sounds cool! Since you used OSD, this can become a good
alternative client for Tegaki.
I tried it but I got a segfault too. I attach the output at the end of
my email but tell me if you need more feedback. I'm looking forward to
seeing it working.
>> Recently, I found myself wanting to write entire sentences with Tegaki
>> too and the lack of hiragana was a problem. Another key feature that
>> would help with inputting entire sentences would be to not only
>> consider the character probabilities individually but also the
>> character transition probabilities. I mentioned it in this thread:
>
> For japanese one could easily use the EDICT dictionary in order to
> find likely Kanji combinations. It should be something similar as
> what's used on mobile phones, i.e. where you get a suggestions after
> entering a few characters. Maybe it would be worth checking out that
> code, e.g. simeji for Android.
Yes using a dictionary is another way to do it, although the character
candidates re-ranking is probably less straightforward than if you use
character transition probabilities (bigrams). Using bigrams can also
handle entire sentences while with a dictionary, you'd probably need
to detect word boundaries.
Mathieu
---
$ make gdb
CFLAGS="-Wall -g" python setup.py build
running build
running build_ext
building 'xinputextdev' extension
creating build
creating build/temp.linux-x86_64-2.6
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -Wall -g -fPIC -I/usr/include/pygtk-2.0
-I/usr/include/glib-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include
-I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/include/atk-1.0
-I/usr/include/python2.6 -c xinputextdev.c -o
build/temp.linux-x86_64-2.6/xinputextdev.o
In file included from /usr/include/gtk-2.0/gtk/gtk.h:233,
from /usr/include/pygtk-2.0/pygtk/pygtk.h:8,
from xinputextdev.c:24:
/usr/include/gtk-2.0/gtk/gtkitemfactory.h:47: warning: function
declaration isn’t a prototype
creating build/lib.linux-x86_64-2.6
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wall -g
build/temp.linux-x86_64-2.6/xinputextdev.o -lgtk-x11-2.0 -lX11 -lXi
-lXtst -o build/lib.linux-x86_64-2.6/xinputextdev.so
PYTHONPATH="build/lib.linux-x86_64-2.6" gdb --args python tegakiosd.py
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/python tegakiosd.py
[Thread debugging using libthread_db enabled]
Device: Virtual core pointer
Device: Virtual core keyboard
Device: Virtual core XTEST pointer
Device: Virtual core XTEST keyboard
Device: Power Button
Device: Power Button
Device: USB Optical Mouse
Device: Dell Dell USB Entry Keyboard
Device: Macintosh mouse button emulation
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaacd63c4 in pthread_mutex_lock () from /lib/libpthread.so.0
Mathieu Blondel
> my email but tell me if you need more feedback. I'm looking forward to
> seeing it working.
Forgot the backtrace.
Mathieu
(gdb) bt
#0 0x00002aaaaacd63c4 in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0x00002aaaaf9b6e47 in XrmQGetResource () from /usr/lib/libX11.so.6
#2 0x00002aaaaf995a10 in XGetDefault () from /usr/lib/libX11.so.6
#3 0x00002aaaaee25ea3 in ?? () from /usr/lib/libcairo.so.2
#4 0x00002aaaaee26188 in ?? () from /usr/lib/libcairo.so.2
#5 0x00002aaaaee268ec in ?? () from /usr/lib/libcairo.so.2
#6 0x00002aaaaee2701f in cairo_xlib_surface_create () from
/usr/lib/libcairo.so.2
#7 0x00002aaaae04f6da in gdk_window_begin_paint_region () from
/usr/lib/libgdk-x11-2.0.so.0
#8 0x00002aaaadb298bb in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#9 0x00002aaaae0538ea in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#10 0x00002aaaae05037b in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#11 0x00002aaaae0521f1 in gdk_window_process_all_updates () from
/usr/lib/libgdk-x11-2.0.so.0
#12 0x00002aaaae052259 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#13 0x00002aaaae02ed56 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#14 0x00002aaaaca3c8c2 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#15 0x00002aaaaca40748 in ?? () from /lib/libglib-2.0.so.0
#16 0x00002aaaaca40c55 in g_main_loop_run () from /lib/libglib-2.0.so.0
#17 0x00002aaaadb29af7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#18 0x00002aaaad6d7622 in ?? () from
/usr/lib/pymodules/python2.6/gtk-2.0/gtk/_gtk.so
#19 0x00000000004a7d98 in PyEval_EvalFrameEx ()
#20 0x00000000004a9671 in PyEval_EvalCodeEx ()
#21 0x00000000004a9742 in PyEval_EvalCode ()
#22 0x00000000004c9a0e in PyRun_FileExFlags ()
#23 0x00000000004c9c24 in PyRun_SimpleFileExFlags ()
#24 0x000000000041a7ff in Py_Main ()
#25 0x00002aaaabd8bc4d in __libc_start_main () from /lib/libc.so.6
#26 0x00000000004199f9 in _start ()
Mathieu Blondel
> Since the segfault is likely to be in the XInput/Tablet code you can
> also disable that and try just with the mouse first.
> To disable the one-liner patch below should work.
For the record, this works for me when I disable XInput/Tablet with
the patch you provided. (I don't have a tablet so maybe a check must
be done somewhere)
For displaying candidates, I'd rather reserve some space at the bottom
and display candidates there. Currently, it may be a bit difficult to
read since the handwritten character and the candidates sometimes
overlap.
Did you implement some way to show/hide the drawing area already?
A way to switch recognizer would be nice too.
Anyway, thanks for coding this !
Mathieu
ulim
On May 28, 5:08 pm, Mathieu Blondel <math...@mblondel.org> wrote:
> > Since the segfault is likely to be in the XInput/Tablet code you can
> > also disable that and try just with the mouse first.
> > To disable the one-liner patch below should work.
>
> For the record, this works for me when I disable XInput/Tablet with
> the patch you provided. (I don't have a tablet so maybe a check must
> be done somewhere)
problem is that my code activates threading with a call to
XInitThreads(). There are many bug reports about this function. It
works fine on my machine but you probably have different gtk/xlib
versions. Could you check? I have gtk 2.18.7 and libX11 1.2.2.
To verify this, could you move the single line from my patch down to
immediately after the XInitThreads() statement? Should it crash again
I'm fairly certain that's the problem. In that case, you could try
removing both the line from the patch and the XInitThreads() call and
see if that works. It might ;-)
> For displaying candidates, I'd rather reserve some space at the bottom
> and display candidates there. Currently, it may be a bit difficult to
> read since the handwritten character and the candidates sometimes
> overlap.
color would be enough for distinction. I could also make the color a
bit darker. It becomes bright automatically once you hold down the
mouse/tablet button.
> Did you implement some way to show/hide the drawing area already?
tablet and the code catches that and displays the window. On a
proximity out event it hides the window after a few seconds(5?). Since
there is no such thing with a mouse there's currently no way to hide
the window. An option might be to make the window completely
transparent and once you move over it with the mouse to show the
contents.
By the way, a nice feature for tablet users would be to make the
window "untouchable" with the mouse, i.e. route clicks through to
underlying windows...I read somewhere that there is support in X for
this (used in "rounded widgets" IIRC).
Oh did you see the kanjidic support? I think it's a nice touch to show
some details after writing a kanji, currently nr. of strokes/meanings/
readings/school grade. You just need to have the kanjidic file at the
DEFAULT_KANJIDIC_PATH in the platforms encoding (e.g. I converted it
to utf8 with iconv).
> A way to switch recognizer would be nice too.
empty and you will be able to choose between models. There's also a
point to activate window decorations (useful for moving the window).
> Anyway, thanks for coding this !
Japanese mail "by hand" from now on.
By the way, I'm thinking about adding some way to save the written
Characters. That way I could for example give "handwritten" homework
to my teacher. Also, it might be nice to see some "progress" if one
looks at the handwriting samples after a month or so. Might also be
nice to detect frequent mistakes. I guess there is already some code
to save a Writing object to a file?
Thanks,
Uli
Mathieu Blondel
> Since the segfault happens in X11 locking code my guess is that the
> problem is that my code activates threading with a call to
> XInitThreads(). There are many bug reports about this function. It
> works fine on my machine but you probably have different gtk/xlib
> versions. Could you check? I have gtk 2.18.7 and libX11 1.2.2.
gtk 2.20.0
libX11 1.3.2
> To verify this, could you move the single line from my patch down to
> immediately after the XInitThreads() statement? Should it crash again
> I'm fairly certain that's the problem.
Indeed, it crashes there.
>> Did you implement some way to show/hide the drawing area already?
>
> Yes. My tablet emits a "proximity" event when the pen comes near the
> tablet and the code catches that and displays the window. On a
> proximity out event it hides the window after a few seconds(5?). Since
> there is no such thing with a mouse there's currently no way to hide
> the window. An option might be to make the window completely
> transparent and once you move over it with the mouse to show the
> contents.
I'm fine with creating a separate OSD client but what was the reason
for not doing it in tegaki-recognize directly? Can't the drawing area
on the tablet be mapped to correspond to the drawing zone in
tegaki-recognize?
> Oh did you see the kanjidic support? I think it's a nice touch to show
> some details after writing a kanji, currently nr. of strokes/meanings/
> readings/school grade. You just need to have the kanjidic file at the
> DEFAULT_KANJIDIC_PATH in the platforms encoding (e.g. I converted it
> to utf8 with iconv).
Yes but I'm a bit undecided on this. If you follow the UNIX way of
thinking, Tegaki shouldn't do any dictionary functionality.
Conversely, dictionaries shouldn't do any handwriting recognition,
unless they need tight integration. Tegaki should be used through
ibus-tegaki for this.
> Thank you for coding Tegaki! ;-) I'm looking forward to writing all my
> Japanese mail "by hand" from now on.
I think we aren't quite there yet ;-) The current recognizers can be
greatly improved and the character-transition thing will greatly
improve the ease of use. In particular, rather than choosing
characters one at a time, we should be able to write all characters
first, hope that the recognized sentence is correct, if not choose in
a list of candidate sentences and optionally fix individual character
mistakes.
> By the way, I'm thinking about adding some way to save the written
> Characters. That way I could for example give "handwritten" homework
> to my teacher. Also, it might be nice to see some "progress" if one
> looks at the handwriting samples after a month or so. Might also be
> nice to detect frequent mistakes. I guess there is already some code
> to save a Writing object to a file?
You can import/export Character objects in XML. There's also some code
to export Writing objects to images (PNG, PDF, SVG, animated GIF,
etc). There's tegakigdk.renderers in tegaki-pygtk and tegaki-render in
tegaki-tools.
Mathieu
Roger Braun
>> some details after writing a kanji, currently nr. of strokes/meanings/
>> readings/school grade. You just need to have the kanjidic file at the
>> DEFAULT_KANJIDIC_PATH in the platforms encoding (e.g. I converted it
>> to utf8 with iconv).
>
> Yes but I'm a bit undecided on this. If you follow the UNIX way of
> thinking, Tegaki shouldn't do any dictionary functionality.
> Conversely, dictionaries shouldn't do any handwriting recognition,
> unless they need tight integration. Tegaki should be used through
> ibus-tegaki for this.
This is not completely related, but I think that you could boost
recognition rates by simple favoring kanji candidates that have right
stroke number. Most of the time I get wrong candidates in the first
slot it is something that looks similar but has different number of
strokes.
Completely unrelated: It would be nice to have an implementation of
the Kanjipad algorithm as an engine for Tegaki.
Mathieu Blondel
<roger...@student.uni-tuebingen.de> wrote:
> This is not completely related, but I think that you could boost
> recognition rates by simple favoring kanji candidates that have right
> stroke number. Most of the time I get wrong candidates in the first
> slot it is something that looks similar but has different number of
> strokes.
In Wagomu, I use a window size: the search is limited to the
characters that have +- n strokes than the input character. You can
change the value in the meta file. In Zinnia, Benoit Cerrina seems to
be working on that lately, with the aim of improving recognition
speed.
> Completely unrelated: It would be nice to have an implementation of
> the Kanjipad algorithm as an engine for Tegaki.
Agreed.
Mathieu
ulim
> > Since the segfault happens in X11 locking code my guess is that the
> > problem is that my code activates threading with a call to
> > XInitThreads(). There are many bug reports about this function. It
> > works fine on my machine but you probably have different gtk/xlib
> > versions. Could you check? I have gtk 2.18.7 and libX11 1.2.2.
>
> gtk 2.20.0
> libX11 1.3.2
> > To verify this, could you move the single line from my patch down to
> > immediately after the XInitThreads() statement? Should it crash again
> > I'm fairly certain that's the problem.
>
> Indeed, it crashes there.
seems that works fine.
> >> Did you implement some way to show/hide the drawing area already?
>
> > Yes. My tablet emits a "proximity" event when the pen comes near the
> > tablet and the code catches that and displays the window. On a
> > proximity out event it hides the window after a few seconds(5?). Since
> > there is no such thing with a mouse there's currently no way to hide
> > the window. An option might be to make the window completely
> > transparent and once you move over it with the mouse to show the
> > contents.
>
> I'm fine with creating a separate OSD client but what was the reason
> for not doing it in tegaki-recognize directly? Can't the drawing area
> on the tablet be mapped to correspond to the drawing zone in
> tegaki-recognize?
First of all, I wanted a solution that I can control entirely with the
tablet without having to touch the mouse and which I can just keep
running all the time and which allows me to quickly enter characters
one after the other.
Therefore no wasting of screen-estate, no buttons, transparency to
keep as much visible as possible, just a space for drawing, fast
candidate choice.
In fact, I did start out with tegaki-recognize and mapped half of the
tablet to the left side and the other half to the right side. However,
when I considered to make some UI adjustments I realized that most of
the tegaki-recognize code is in fact UI and that there wouldn't be
much left once I started to make all these changes. In retrospective
I'd say that's true, the UI couldn't be more different. For instance,
tegakiOSD is entirely drawn with cairo, no gtk widgets at all.
However, I guess it depends both on the purpose and personal
preference which kind of UI one wants to use. I can see if I can dig
up the tablet-enhanced tegaki-recognize version if you like.
> > Oh did you see the kanjidic support? I think it's a nice touch to show
> > some details after writing a kanji, currently nr. of strokes/meanings/
> > readings/school grade. You just need to have the kanjidic file at the
> > DEFAULT_KANJIDIC_PATH in the platforms encoding (e.g. I converted it
> > to utf8 with iconv).
>
> Yes but I'm a bit undecided on this. If you follow the UNIX way of
> thinking, Tegaki shouldn't do any dictionary functionality.
> Conversely, dictionaries shouldn't do any handwriting recognition,
> unless they need tight integration. Tegaki should be used through
> ibus-tegaki for this.
it's a very nice functionality to see some information while writing.
It sort of comes for "free".
Workflow one:
I'm writing a mail and I'd like to see some info about the kanji. I'd
have to switch to some dictionary/web browser, write the kanji a
second time(first time in the mail), press enter, read, switch back to
mail writing.
Workflow two:
Just write your mail, look at the info if you're interested, continue
writing if you're not. Couldn't be simpler.
I think that justifies having that functionality in tegaki. An
alternative might be integration with a dictionary application, i.e.
send all commited chars from tegaki to dictX and let it display the
info.
Concerning the UNIX paradigm it would make sense to have a python lib
for parsing kanjidic.
I'm sure there is something like it, I just haven't spent any time on
it yet, some shell magic did the trick for me for now.
In fact, I don't think it can get any more UNIX-like than the current
sed/tr/grep magic I used to parse kanjidic ;-)
> > Thank you for coding Tegaki! ;-) I'm looking forward to writing all my
> > Japanese mail "by hand" from now on.
>
> I think we aren't quite there yet ;-) The current recognizers can be
> greatly improved and the character-transition thing will greatly
> improve the ease of use. In particular, rather than choosing
> characters one at a time, we should be able to write all characters
> first, hope that the recognized sentence is correct, if not choose in
> a list of candidate sentences and optionally fix individual character
> mistakes.
good and what I write is mostly the first candidate. Even if not with
tegakiOSD I can quickly choose other candidates if it's not.
However, I'm of course myself kinda slow because the language is new
to me, therefore I can probably tolerate more problems with
recognition.
Concerning the tolerance on the number of strokes it would probably be
optimal for me to set that to 0, that way I don't get wrong habits.
However, it would of course be nice if one could just write one
character after the other and worry about recognition afterwards. I
realize that's already possible in tegaki-recognize. For tegakiOSD one
could think of a "page" mechanism, i.e. moving the pen to the left
could result in "scrolling" backwards. Another option might be to
allow one to write several characters to the entire tablet surface and
afterwards try to identify individual characters. That would probably
need some serious implementation work though I think ;-)
> > By the way, I'm thinking about adding some way to save the written
> > Characters. That way I could for example give "handwritten" homework
> > to my teacher. Also, it might be nice to see some "progress" if one
> > looks at the handwriting samples after a month or so. Might also be
> > nice to detect frequent mistakes. I guess there is already some code
> > to save a Writing object to a file?
>
> You can import/export Character objects in XML. There's also some code
> to export Writing objects to images (PNG, PDF, SVG, animated GIF,
> etc). There's tegakigdk.renderers in tegaki-pygtk and tegaki-render in
> tegaki-tools.
Mathieu Blondel
> In fact, I did start out with tegaki-recognize and mapped half of the
> tablet to the left side and the other half to the right side. However,
> when I considered to make some UI adjustments I realized that most of
> the tegaki-recognize code is in fact UI and that there wouldn't be
> much left once I started to make all these changes. In retrospective
> I'd say that's true, the UI couldn't be more different. For instance,
> tegakiOSD is entirely drawn with cairo, no gtk widgets at all.
I would rather map the entire tablet to only one drawing area and find
some way to switch to the other drawing area when the current
character is completed. I was thinking that you could use the
proximity event to hide/show the tegaki-recognize window. But I'm
realizing that the main issue is how to select candidates directly
from the tablet. It will be difficult to select more than one
character at a time.
Does your code works with any tablet?
Mathieu
ulim
On May 29, 11:32 pm, Mathieu Blondel <math...@mblondel.org> wrote:
> > In fact, I did start out with tegaki-recognize and mapped half of the
> > tablet to the left side and the other half to the right side. However,
> > when I considered to make some UI adjustments I realized that most of
> > the tegaki-recognize code is in fact UI and that there wouldn't be
> > much left once I started to make all these changes. In retrospective
> > I'd say that's true, the UI couldn't be more different. For instance,
> > tegakiOSD is entirely drawn with cairo, no gtk widgets at all.
>
> I would rather map the entire tablet to only one drawing area and find
> some way to switch to the other drawing area when the current
> character is completed.
The most natural way to get to the next character with a tablet would
probably be to start writing further right. It's probably hard to
detect that on the first stroke but after a few strokes one could see
that there is no overlap between the last x strokes and the y strokes
before.
> I was thinking that you could use the
> proximity event to hide/show the tegaki-recognize window.
> But I'm
> realizing that the main issue is how to select candidates directly
> from the tablet. It will be difficult to select more than one
> character at a time.
could instead have a "selection" mode after entering an entire
sequence where one would go through all written characters and confirm/
select one after the other.
Or maybe one could just click on an already completed character with
some button in order to select a candidate. That's probably the way to
go.
> Does your code works with any tablet?
relying on two buttons on the pen right now, I don't know if all
tablets have that.
Uli