You might like to know about IDSgrep, which just released its first
version, 0.1:
http://sourceforge.jp/projects/tsukurimashou/releases/?package_id=12853
This is a search program for an extended version of Unicode Ideographic
Description Sequence syntax. It does powerful queries on the structures
and content of kanji - for instance, you can say "find kanji that contain
心 (heart) at the bottom, and 木 (tree) anywhere in the top," and it'll
return 恷, 想, 愁, and 懋. This was created as a tool for use in
development of my Tsukurimashou font package, and one of the dictionaries
it can search is extracted from Tsukurimashou; however, it is also comes
with a script for converting the KanjiVG database into its own format for
searching.
--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/
I have added your program to the links list. Maybe you would like to
elaborate a little bit more on what it does, as there is no
screenshots visible as far as I have seen.
Alex.
> --
> You received this message because you are subscribed to the "KanjiVG" group.
> For options and unsubscribing, visit this group at
> http://groups.google.com/group/kanjivg
Here's a screenshot:
http://sourceforge.jp/projects/tsukurimashou/images?id=2999
This is a command-line utility in the spirit of grep. It doesn't come
with a graphical interface, and to use it effectively one must already
have a kanji keyboard input method and some skill at using that.
Unicode defines some special characters (the "Ideographic Description
Characters," IDCs), and a syntax for using them to form descriptions
("Ideographic Desription Sequences," IDSes) of kanji (or other Han-script)
characters in terms of their breakdown into smaller parts. It's a simple
prefix notation. Many readers probably won't be able to see this properly
because not many fonts include the IDCs, but Unicode's IDS for the
character 萌 looks like "⿱艹⿰日月". These are intended by Unicode to be
used for describing characters that otherwise wouldn't have code points,
as part of efforts to solve the gaiji problem. However, it's perfectly
possible to use them for describing the structure of characters that do
have their own code points.
IDSgrep performs matching on IDSes. It extends the syntax a little, to
include wildcards, ASCII aliases for the hard-to-type IDC characters,
mark-up of sub-trees that may have code point equivalents of their
own, and Boolean query operators. To search the database you give it a
matching pattern that looks like an IDS with possibly some special
matching commands attached - just as with grep you search a file by giving
it a matching pattern that looks like the thing you're looking for with
possibly some special matching commands attached.
For instance, you could search for 萌 by searching for "...[lr]日月" -
that means "all characters that include, anywhere in the character, 日
next to 月." Such a query would match 萌, but also 明 and 盟.
Exactly why someone would want to do this may be a little hard to explain.
It's certainly not for everybody, or for every application; if one just
wants to find the meaning of a particular unknown character, it's probably
easier to use multi-radical search, dictionary codes, handwriting
recognition, and so on. But in my font project I often want to find
*kinds* of characters rather than a *specific* character - for instance,
if I'm considering creating a subroutine that places 日 next to 月, I want
to know if I'll be able to use that subroutine in many glyphs, so I want
to look at a list of all characters that contain that structure. I
similarly often want to make such queries against the code I've already
written (which necessitates something for which I can easily create my own
dictionaries instead of just using a ready-made one).
It seems like this kind of structured query might be useful to other
people too, hence rolling it up into a package. Something similar could
possibly be achieved using existing general-purpose XML query languages
directly against KanjiVG's XML, or against XML in similar format that I
might generate myself from my own code, but such tools seem like they
would be much less convenient to use. I wanted something with the
user-friendliness of grep - which sounds like a joke, but isn't.
Web log posting about the background here:
http://ansuz.sooke.bc.ca/entry/228
Complete details of the syntax are in the package's documentation.