[PATCH] KanjiVG support
Roger Braun
i finally managed to finish the KanjiVG support for tegaki-convert.
You can now do "tegaki-convert -a kanjivg-latest.xml". This uses the
actual KanjiVG xml files, not the xml-less version from Tagaini Jisho
that my ruby tool used. Conversion takes a long time (30min+) so be
prepared to wait. Opening the resulting file in tegaki-train also
takes a while.
Some kanji in KVG have a stroke element with no path attached, which
seems to be an error in the KanjiVG data, so don't be surprised if
these kanji don't recognize well:
Missing path in <stroke> element: 瓧
Missing path in <stroke> element: 瓩
Missing path in <stroke> element: 瓮
Missing path in <stroke> element: 瓰
Missing path in <stroke> element: 瓱
Missing path in <stroke> element: 瓲
Missing path in <stroke> element: 瓷
Missing path in <stroke> element: 瓸
Missing path in <stroke> element: 甃
Missing path in <stroke> element: 甄
Missing path in <stroke> element: 甅
Missing path in <stroke> element: 甌
Missing path in <stroke> element: 甍
Missing path in <stroke> element: 甎
Missing path in <stroke> element: 甑
Missing path in <stroke> element: 甓
Missing path in <stroke> element: 甕
Missing path in <stroke> element: 艘
Missing path in <stroke> element: 苡
Missing path in <stroke> element: 蕋
Missing path in <stroke> element: 諛
Missing path in <stroke> element: 鐫
Missing path in <stroke> element: 魑
Missing path in <stroke> element: 黐
I hope this is useful. You can pull from
http://github.com/rogerbraun/Project-Tegaki.
Next goal: Making tegaki run on my android phone ;-)
--
Roger Braun
http://yononaka.de
roger...@student.uni-tuebingen.de
Mathieu Blondel
> i finally managed to finish the KanjiVG support for tegaki-convert.
> You can now do "tegaki-convert -a kanjivg-latest.xml".
Great! Thanks! Is pyparsing really indispensable? You use it to parse
the SVG paths, is that correct? Isn't it possible to parse them by
hand or by regexp?
> This uses the
> actual KanjiVG xml files, not the xml-less version from Tagaini Jisho
> that my ruby tool used. Conversion takes a long time (30min+) so be
> prepared to wait. Opening the resulting file in tegaki-train also
> takes a while.
This is because currently characters collections are completely loaded
in memory... Instead, we should create some kind of index when the
file is opened and retrieve characters on demand, I guess.
> Some kanji in KVG have a stroke element with no path attached, which
> seems to be an error in the KanjiVG data, so don't be surprised if
> these kanji don't recognize well:
Fortunately, the KanjiVG maintainer is subscribed to this group ;-)
> I hope this is useful. You can pull from
> http://github.com/rogerbraun/Project-Tegaki.
>
> Next goal: Making tegaki run on my android phone ;-)
Unfortunately, an Iphone or Android port of Tegaki is likely to
require a lot of work, although I've never programed for any of them.
Ideally, we would want to have Python running directly on the phone.
For the Iphone, it does seem possible to embed Python in an
Objective-C program. For Android, I don't know.
The GUI is a big problem too. I think we can forget about GTK running
on any of them. Actually, although I have always used GTK, I now
consider Qt a better framework for cross-platform development. Windows
support in GTK is quite good but Mac OS X support leaves much to be
desired. Mac OS X support in Qt is much better. There's a project to
get Qt running on the Iphone (http://www.qt-iphone.com/) and hopefully
there will be one for Android too in the future. Qt is also going to
be used for Nokia phones and smartphones. That's why I want a
tegaki-pyqt branch, in addition to tegaki-pygtk.
BTW, if we get native Cocoa interface, will that work on the Iphone too?
Currently the easiest way I came up with to get Tegaki ported to the
Iphone or Android is to write a small daemon/server in Python, that
uses tegaki-python. The interface would be the browser.
(HTML+CSS+Javascript)... The daemon would run directly on the phone
and would communicate with the interface in JSON.
Mathieu
Alexandre Courbot
>> i finally managed to finish the KanjiVG support for tegaki-convert.
>> You can now do "tegaki-convert -a kanjivg-latest.xml".
>
> Great! Thanks! Is pyparsing really indispensable? You use it to parse
> the SVG paths, is that correct? Isn't it possible to parse them by
> hand or by regexp?
Actually KanjiVG has a small Python library that allows easy loading
and parsing of the format. Once the Git repo is made public (still
need to clean some things up), feel free to use it.
>> Some kanji in KVG have a stroke element with no path attached, which
>> seems to be an error in the KanjiVG data, so don't be surprised if
>> these kanji don't recognize well:
>
> Fortunately, the KanjiVG maintainer is subscribed to this group ;-)
... and he is following Tegaki closely. ;) Actually I am aware of
these ones, I just need to find the time to go and fix them... or wait
until someone who needs them badly does it before.
> The GUI is a big problem too. I think we can forget about GTK running
> on any of them. Actually, although I have always used GTK, I now
> consider Qt a better framework for cross-platform development. Windows
> support in GTK is quite good but Mac OS X support leaves much to be
> desired. Mac OS X support in Qt is much better. There's a project to
> get Qt running on the Iphone (http://www.qt-iphone.com/) and hopefully
> there will be one for Android too in the future. Qt is also going to
> be used for Nokia phones and smartphones. That's why I want a
> tegaki-pyqt branch, in addition to tegaki-pygtk.
I can only give my testimony about how great I think Qt is for
cross-platform development (and development itself). Moreover its
future as an embedded toolkit seems bright.
ALex.
Mathieu Blondel
>> Great! Thanks! Is pyparsing really indispensable? You use it to parse
>> the SVG paths, is that correct? Isn't it possible to parse them by
>> hand or by regexp?
>
> Actually KanjiVG has a small Python library that allows easy loading
> and parsing of the format. Once the Git repo is made public (still
> need to clean some things up), feel free to use it.
It's more than just loading the file. The SVG paths must also be
converted to series of (x,y) points.
Mathieu
Christoph Burgmer
> I can only give my testimony about how great I think Qt is for
> cross-platform development (and development itself). Moreover its
> future as an embedded toolkit seems bright.
I wrote a Qt widget in Python for Tomoe some time ago and later extended it
for Tegaki. It's not the cleanest implementation, but if someone's interested
in providing the same functionality from pygtk for Qt, maybe my work can give
some hints how to procede. [1]
I'm interested in having proper Qt support in Tegaki, so ping me if anyone of
you wants to start on this.
- Christoph
[1]
http://code.google.com/p/eclectus/source/browse/trunk/tomoeqt/handwritingwidget.py
Roger Braun
On Tue, Nov 3, 2009 at 4:17 AM, Mathieu Blondel <mat...@mblondel.org> wrote:
> Great! Thanks! Is pyparsing really indispensable? You use it to parse
> the SVG paths, is that correct? Isn't it possible to parse them by
> hand or by regexp?
Well, I could try to come up with a solution for parsing it "by hand",
but I don't really see a reason for it. Pyparsing seems to be the
perfect tool for the job and makes the code very easy to understand.
The added requirement for pyparsing also only affects developers who
probably can be expected to be able to install a small library. If
another SVG element is added to KanjiVG in the future (which I sort of
expect: Circles are in the source files, but not in the generated XML.
Take a look at the strokepaths for "!", "?" or just "."), the change
is really easy and clear.
If you absolutely can not stand having pyparsing in your tree I will
look into it, but the last time I tried to parse it by hand (see my
ruby version) it was somewhat messy.
>
>> Some kanji in KVG have a stroke element with no path attached, which
>> seems to be an error in the KanjiVG data, so don't be surprised if
>> these kanji don't recognize well:
>
> Fortunately, the KanjiVG maintainer is subscribed to this group ;-)
>
Hello Alexandre! I saw what you did today ;-)
>> I hope this is useful. You can pull from
>> http://github.com/rogerbraun/Project-Tegaki.
>>
>> Next goal: Making tegaki run on my android phone ;-)
>
> Unfortunately, an Iphone or Android port of Tegaki is likely to
> require a lot of work, although I've never programed for any of them.
> Ideally, we would want to have Python running directly on the phone.
> For the Iphone, it does seem possible to embed Python in an
> Objective-C program. For Android, I don't know.
Take a look at ASE:
http://www.talkandroid.com/1225-android-scripting-environment/
You can run C or C++ Code on the Android (via the Android NDK), so
porting Zinnia should be possible, but I don't think that it is really
possible to port tegaki-recognize or anything like that. You would
need a new GUI, especially as it shoud probably be integrated as an
IME on Android.
>
> Currently the easiest way I came up with to get Tegaki ported to the
> Iphone or Android is to write a small daemon/server in Python, that
> uses tegaki-python. The interface would be the browser.
> (HTML+CSS+Javascript)... The daemon would run directly on the phone
> and would communicate with the interface in JSON.
Would be possible, but would not be very IME-like.
Some more rather unrelated thoughts:
- I installed Ubuntu 9.10 today and noticed that SCIM is now replaced
with iBus. I think SCIM is going to be deprecated, so maybe we should
switch.
- Tegaki seems to be the only free kanji handwriting recognition
software there is for Mac OS X. I think you should stress this fact
more.
- Would it be a good thing to add a switch to tegaki-recognize that
makes you send your writings to a database (preferably tegaki-db) for
later use? This would give us real world data on how people actually
write the kanji they want.
Alexandre Courbot
>>> seems to be an error in the KanjiVG data, so don't be surprised if
>>> these kanji don't recognize well:
>>
>> Fortunately, the KanjiVG maintainer is subscribed to this group ;-)
>>
>
> Hello Alexandre! I saw what you did today ;-)
8O
No! You have no proof it was me behind these bushes. And anyway, what
were you doing there too?
... oh, or maybe you are talking about this: http://gitorious.org/kanjivg
So yes, I have finally written a filter that makes clean and
consistent SVG files out of the garbage that graphical editors
produce, so the Git repository for KanjiVG is finally up. It is still
a little bit raw but the next step is to complete it with other
scripts that check for inconsistencies and reveal potential errors.
The variants that Matthieu asked for are also there, although they
probably have more mistakes that the non-variant files. There is a
short README file, but please don't hesitate to ask me if something is
unclear.
Of course, fixes are also welcome.
Alex.
Mathieu Blondel
> I'm interested in having proper Qt support in Tegaki, so ping me if anyone of
> you wants to start on this.
I've never used Qt nor PyQt so I think you're more apt than me for the
job. I will try to help and learn the framework in the process though.
In tegaki-pygtk, so far we have a canvas, a character table, the
recognizer widgets, the icon view and the renderers. The renderers can
transform a character into an image. The iconview is for displaying
lists of characters as icons and needs the renderers. It's only used
in tegaki-train so far. The character table is for displaying
candidates. In GTK, there was no suitable native widget for this but
maybe in Qt there is. Ideally, the widgets in tegaki-pygtk and tegaki-
pyqt should have the same public APIs (like get_writing(), set_writing
() in the canvas).
I think we should focus on the minimum to get tegaki-recognize running
first. tegaki-train can wait. tegaki-recognizer can be changed to be
able to use both tegaki-pygtk and tegaki-pyqt, for example by catching
ImportError. Command line options could also be provided for people
who have both installed (--gtk or --qt).
@Robert:
> If you absolutely can not stand having pyparsing in your tree I will
> look into it, but the last time I tried to parse it by hand (see my
> ruby version) it was somewhat messy.
> I installed Ubuntu 9.10 today and noticed that SCIM is now replaced
> with iBus. I think SCIM is going to be deprecated, so maybe we should
> switch.
group. For someone who knows the ibus API, I'm sure it's a matter of 1
hour or 2. And ibus is python-based too.
> Tegaki seems to be the only free kanji handwriting recognition
> software there is for Mac OS X. I think you should stress this fact
> more.
which is not ideal and we don't have universal binaries yet.
> Would it be a good thing to add a switch to tegaki-recognize that
> makes you send your writings to a database (preferably tegaki-db) for
> later use? This would give us real world data on how people actually
> write the kanji they want.
characters written with tegaki, it would be a pity not to use them.
But we definitely need users' permission.
By the way, do you know Anki? (http://ichi2.net/anki/) I'm using it
from time to time.
Its source is split into the backend (libanki) and frontend (ankiqt).
I wonder if we could write a frontend (or just a plugin?) that would
use handwriting as a way to answer questions. That would also be a
great source of character samples. Anki is written in Python too.
@Alex:
> So yes, I have finally written a filter that makes clean and
> consistent SVG files out of the garbage that graphical editors
> produce, so the Git repository for KanjiVG is finally up.
Mathieu
Christoph Burgmer
> @Christoph
>
> > I'm interested in having proper Qt support in Tegaki, so ping me if
> > anyone of you wants to start on this.
>
> Feel free to start a tegaki-pyqt folder in master when you got time.
> I've never used Qt nor PyQt so I think you're more apt than me for the
> job. I will try to help and learn the framework in the process though.
Time, eh? :)
I believe something similar to tegaki-recognize might be nice to for Qt.
Tegaki-train works, and is only needed by few people, so why bother going the
full way (my personal view).
> In tegaki-pygtk, so far we have a canvas, a character table, the
> recognizer widgets, the icon view and the renderers. The renderers can
> transform a character into an image. The iconview is for displaying
> lists of characters as icons and needs the renderers. It's only used
> in tegaki-train so far. The character table is for displaying
> candidates. In GTK, there was no suitable native widget for this but
> maybe in Qt there is. Ideally, the widgets in tegaki-pygtk and tegaki-
> pyqt should have the same public APIs (like get_writing(), set_writing
> () in the canvas).
I'd focus on a QGraphicsView renderer first and provide a recognition widget. I
basically have that in Eclectus already, only that I'd like to move that to
Tegaki in a proper form.
I'd might tackle this myself, but honestly, my TODO list currently is pretty
long.
We'll see.
-Christoph