Life is beautiful

neu.Note+ 向けに曲線のスムージングのアルゴリズムを開発中。特に文字の場合、オリジナルの字形を崩さずにどこまで自動できれいなスムージングをかけられるかが勝負になる。

左の図で、一番左のものがオリジナル。iPad上に指で書いたものだが、手書き特有の「よれ」が見れる。それぞれのストロークは３０〜４０個のベジェ曲線から構成されている。

これに開発中のアルゴリズムを適用したものが真ん中のもの。隣接するベジェ曲線を組み合わせることにより、ベジェ曲線の数を減らしたもの。あまり減らしすぎると字形が崩れるので、そのバランスが難しい。結果としては、それぞれのストロークに含まれるベジェ曲線は６〜１３個に減っている。「よれ」がなくなり、かなりきれいになった。

これをさらに手動で最適化したものが一番右のもの。各ストロークに含まれるベジェ曲線は３〜９だ。ここまで来ると、「達筆」と呼べる。

この場合、アプリを作っていて悩ましいのは、「どのくらいのスムージングをかけるべきか」と「どのタイミングでかけるべきか」。もちろん、ユーザーにとってもベストなのは「私が期待している通りのスムージングを自動でかける」なのだが、人によって、また、書いているものによっても「最適なスムージング」が異なるために簡単な話ではない。

一つの方法としては、スムージングをオプションとして提供した上で、ユーザー自身にさまざまなパラメターを設定させて自由にカスタマイズできるようにすること。この手のことをするとパワー・ユーザーは喜ぶのだが、アプリとしての複雑度が増して、普通の人たちにとって使いにくくなったりするので要注意である。

そのあたりの微調整を、プロトタイプを作っては壊し、作っては壊し、という過程を経ながら作り込んで行くのが私の開発スタイルだ。「仕様書をきちんと書いて、それを実装する」という開発スタイルが私の肌に合わないのは、こういった試行錯誤のプロセスそのものがもの作りの過程で必須だと私が感じているからである。

ちなみに、こんな作業をしながら思い出したのが、小学校の習字の授業で、先生が「思い切って書く事が何よりも大切」と繰り返し言っていたこと。思い切って書いた方が、ベジェ曲線の数が少ない、つまり「よれ」の少ないスムーズなストロークが書けるのだ。ということは、逆に、どのくらい少ないベジェ曲線で描かれたストロークが近似できるかを計算することで、「達筆度」を客観的に測定することが可能なのかも知れない。