Handwriting models for zh_TW

[Christoph Burgmer]

I'd like to initiate a set of handwriting models for Traditional Chinese.

I blogged about my approach, tell me what you think:

http://cburgmer.nfshost.com/content/bootstrapping-tegaki-handwriting-models-
using-character-decomposition

Christoph

[Mathieu Blondel]

Thanks for putting this together! This is an interesting approach to
generating a new model. I have two concerns.

One is that the Japanese stroke order may differ from the Traditional
Chinese stroke order. So when you assemble character components from
Japanese Kanji, the resulting character may have the wrong stroke
order from the Traditional Chinese viewpoint.

The other concern I have is that I wonder if there may not be some
(rare) cases when the concatenated stroke order of the components
taken separately and the overall character stroke order may not be
different. I don't have any example in mind to assert this and I could
probably be wrong though.

Anyway, I think it's better to have this data, even with mistakes,
than nothing at all.

Mathieu

[Christoph Burgmer]

Am Mittwoch, 7. Oktober 2009 schrieb Mathieu Blondel:
> Thanks for putting this together! This is an interesting approach to
> generating a new model. I have two concerns.
>
> One is that the Japanese stroke order may differ from the Traditional
> Chinese stroke order. So when you assemble character components from
> Japanese Kanji, the resulting character may have the wrong stroke
> order from the Traditional Chinese viewpoint.

Yes. But even for Simplified components we might see a different stroke order.
One goal in cjklib is to register glyphs, i.e. visual forms of characters. The
library then selects those glyphs attached to the current locale. So for
example 王 will have two entries, one attached to Traditional and Simplified
Chinese (horizontal-horizontal-falling-horizontal), one to Japanese (h-f-h-h).
Once this data gets extended, it will come at no cost for the solution here.

> The other concern I have is that I wonder if there may not be some
> (rare) cases when the concatenated stroke order of the components
> taken separately and the overall character stroke order may not be
> different. I don't have any example in mind to assert this and I could
> probably be wrong though.

There are characters that could be considered being merged from two
components, where an adjunct stroke got omitted. The policy here is, that
those components are put in two disjoint entries where the second component is
unknown. Like 出 could be considered being to 山, with the middle falling stroke
merged. This then goes into ⿱山？ and ⿱？山.
And for decomposition structures ⿻ and ⿴ no stroke order assumtion is made.

> Anyway, I think it's better to have this data, even with mistakes,
> than nothing at all.

Well, the good news is, that while contributing characters for the
bootstrapping process, no work is being wasted, as they can later always
server as a single character entries in a non-bootstrapped solution. Out-
domain components aside here.

I'll probably take care of the missing decomposition data in the next few
days. Will anybody be interested in creating the missing handwriting data?
Hope to boil that down to ~200 characters.

More test data would be interesting, too.

-Christoph