Generating new KanjiVG SVGs?

[Tom]

Would it be possible to generate additional SVGs?

For example:

The Joyo form 侮 is available but the traditional form 侮 is not.

And the Jinmeiyou form 俠 is unavailable but the traditional form 侠 is.

But the Joyo form 剝 is available and it's traditional form 剥 is too.

Would it be possible to generate SVGs for Kanji such as 侮 and 侠 that aren't already included in the project?

[Ben Bullock]

I don't think there is any objection to requesting additional graphics, although since this is a volunteer project, there is no guarantee that anyone will provide them. The place to go is

https://github.com/KanjiVG/kanjivg/issues

and add your request for the additional graphics.

There are currently 14 open requests for new graphics, the oldest dating from 2015.

The original software used to create the graphics is not available, and I personally do not have software available to create new SVG graphics in the KanjiVG format, so it is not clear how they would be created, or by whom. Perhaps you could try to generate them yourself.

 

[Alexandre Courbot]

I think I remember that inkscape was mentioned as an editor for
creating the glyphs - it certainly can be used to modify existing
ones. But hopefully at some point we could come with a more
specialized piece of software that automatically takes care of the
boilerplate and sanity-checking. Something web-based would be really
nice IMHO.

One project in the back of my mind is providing a base library that
provides an API for loading/manipulating/saving the glyphs in a
consistent manner, maybe in Rust (so web-friendly). Then maybe someone
with UI skills could put a nice UI on top of that.

[Ben Bullock]

On Sunday, 27 March 2022 at 09:31:42 UTC+9 Alexandre Courbot wrote:

I think I remember that inkscape was mentioned as an editor for
creating the glyphs - it certainly can be used to modify existing
ones.

Inkscape damages the image's data. I don't know how to recover from the damage.

 

But hopefully at some point we could come with a more
specialized piece of software that automatically takes care of the
boilerplate and sanity-checking. Something web-based would be really
nice IMHO.

I think that developing such software would be extremely time-consuming. Further, starting out on such a project  assumes that if the software existed, that people would pop out of the woodwork and start contributing a lot of time adding new characters, which they're not doing now. I would not want to do this, because I don't think it would be a good idea to start out on a very time consuming project without any guarantee that anyone was going to use the end product.

> One project in the back of my mind is providing a base library that provides an API for loading/manipulating/saving the glyphs in a consistent manner, maybe in Rust (so web-friendly). Then maybe someone with UI skills could put a nice UI on top of that.

The python scripts in the repository don't seem to be in a good state of repair at the moment, are you sure you have enough time to devote to this?

[Alexandre Courbot]

It's just an idea for now. But I have the feeling that the time spent
improving the tooling would get amortized pretty quickly and make the
project more inviting to potential contributors with the right
knowledge.

[msk...@ansuz.sooke.bc.ca]

On Sun, 27 Mar 2022, Alexandre Courbot wrote:
> It's just an idea for now. But I have the feeling that the time spent
> improving the tooling would get amortized pretty quickly and make the
> project more inviting to potential contributors with the right
> knowledge.

About ten years ago, I said much the same thing. The syntax and semantics
of the KanjiVG files are not well-defined, and I thought (and still think)
the project really needed to not only define the files, but also put a
high priority on having automated tools to verify them.

I'd really like to see a situation of being able to type "make check" and
get a report of which files were well-formed and which ones did not meet
the spec. In the current purely-manual maintenance situation, it's a
problem for anything that tries to extract information from KanjiVG to
actually be able to read the files - because the same fields are used in
different ways in different kanji and it's not even possible to say which
kanji are using those fields correctly and which aren't because there is
nothing written down saying what is the "correct" meaning of the values.

My own IDSgrep package (https://tsukurimashou.osdn.jp/idsgrep.php) is an
example of the kind of thing that could benefit from KanjiVG, but that
suffers because KanjiVG's semantics are not really defined. Its KanjiVG
importer has to do a lot of guessing and patching to extract usably
consistent data from the inconsistent KanjiVG format. The task is further
complicated by the fact that IDSgrep handles kanji as trees of components,
whereas in KanjiVG the first-class entities are strokes, and the mapping
between strokes and components is not simple; but doing that mapping
would be a lot easier if the KanjiVG format were consistent from one
kanji to the next.

I thought that the top priority for being able to even start on having
automated tests, would be to package KanjiVG like a free software package,
with a configure script that would do whatever was necessary to get the
software to work on whatever system was trying to run it, and a Makefile
that would build whatever needed to be built, and run whatever tests
existed.

However, the suggestion of packaging KanjiVG like a software package was
not at all popular. Everyone else who participated in the discussion
except myself not only seemed to think it was not the top priority, but
that it would be an actively bad thing and should not be done at all.
General consensus was that KanjiVG should remain purely a set of data
files, possibly with some scripts on the side but without an automated
framework for running the scripts, and with any validity checking of the
files done only by human intervention. Although I was willing to do most
of the work of implementing the packaging and build system, I wasn't
willing to do it if it would be actively rejected, and nobody else was
volunteering, so that went nowhere.

My life is a lot different now from what it was in 2012 and I'm not in a
position to make such an offer of participation now even if it were to be
accepted. But I'll be interested to see if such ideas have become more
popular.

--
Matthew Skala
msk...@ansuz.sooke.bc.ca People before tribes.
https://ansuz.sooke.bc.ca/