みかログ

　改定お疲れ様です～。

　「濁点・半濁点」込みでの文字を定義している「同時打鍵」扱いな配列のなかに、いくつか「濁点・半濁点」を別打ちしている例があるようです。
　「゛゜」を表[step3.html]の中から探した限りでは
--------
NICOLA(Japanist).hmo_kana
NICOLA(J型).hmo_kana
Nicolatter.hmo_kana
TRON.hmo_kana (※半濁点はもともと別打ち)
--------
あたりが該当するようです。
　一方では
--------
NICOLA(ひゅんQ).hmo_kana
飛鳥21-158改(数字除く).hmo_kana
飛鳥21-158改.hmo_kana
飛鳥21-180(数字除く).hmo_kana
飛鳥21-180.hmo_kana
姫踊子草配列CS.hmo_kana
姫踊子草配列六版六案.hmo_kana
--------
にはこの現象は現れていないようです。
　取り急ぎご報告まで。

　すみません……濁点の件、配列定義側で対応してみます。

濁点ですが，ツールがキータイプの候補を選択するときに，打鍵数のみでベストなものを選んでいるのが原因でした．
（同ランクの候補が複数あるときは，適当に選ばれるので，それで結果に違いがでてしまったのかと．．．）

同時打鍵の場合，2ストローク2打より1ストローク2打の方がよいのは明らかですよね．
打鍵数が同じ候補があった場合は，ストローク数の小さい方を選択するようになおしました．

ファイルをアップロードし直しましたので，再度ＤＬしてみてもらえますか？
step3.htmlを見る限りは，うまくいってそうな感じです．

　早速対応いただきありがとうございます！
　こちらでもテストしてみました。
　　NICOLA(Japanist).hmo_kana
　　NICOLA(J型).hmo_kana
　　Nicolatter.hmo_kana
　これら3点はバッチリ問題が解消されました。

　一方で、なぜか
　　TRON.hmo_kana (※半濁点はもともと別打ち)
だけは、手元で解析すると濁音がバラバラに解釈される部分が残っているようです。
　#解析結果全域ではなく、前半にのみ発生するようです。
　邪魔になるかも知れず恐縮ですが、バラけている濁点を【゛】で閉じなおしてみたものを貼ってみます(もしかすると再現性が無いかもしれないですし……)。

a(タ) j(イ) Lq(ヒ) R.(゜) ;(ン) i(ク) Lh【゛】 u(ノ) d(カ) j(イ) Lc(セ) y(キ) h(ヲ) Rh(オ) e(コ) b(ナ) j(イ) z(マ) n(ス)n(ス) i(ク) x(リ) Lg(フ) R.(゜) s(ト) s(ト) k(ウ) r(ハ) l(シ) Lh【゛】 Lv(ユ) k(ウ) c(ニ) d(カ) y(キ) d(カ) Ry(エ) f(テ) m(ツ) d(カ) /(ッ) f(テ) i(ク) a(タ) Lh【゛】 v(サ) j(イ)Lg(フ) i(ク) n(ス) k(ウ) u(ノ) y(キ) Rk(ー) c(ニ) Ld(ュ) k(ウ) x(リ) t(ョ) i(ク) Lt(ホ) k(ウ) Lt(ホ) k(ウ) Rd(ガ) o(ア) x(リ)d(カ) m(ツ) y(キ) Rk(ー) u(ノ) a(タ) j(イ) Lg(フ) R.(゜) n(ス) k(ウ) d(カ) Lh【゛】 d(カ) Rn(ワ) q(ラ) b(ナ) j(イ) r(ハ) Lh【゛】 o(ア) j(イ)e(コ) u(ノ) n(ス) i(ク) x(リ) Lg(フ) R.(゜) s(ト) f(テ) Lh【゛】 r(ハ) f(テ) y(キ) s(ト) k(ウ) c(ニ) k(ウ) Rj(チ) d(カ) a(タ) h(ヲ) Ru(ケ) /(ッ) f(テ) j(イ) l(シ) z(マ) n(ス)e(コ) p(レ) c(ニ) Lf(ヨ) x(リ)Lw(ソ) k(ウ) Re(ゴ) k(ウ) Lq(ヒ) t(ョ) k(ウ) d(カ) c(ニ) o(ア) i(ク) Ry(エ) j(イ) y(キ) t(ョ) k(ウ) h(ヲ) o(ア) a(タ) Ry(エ) w(ル) d(カ) u(ノ) k(ウ) Lc(セ) j(イ) Rd(ガ) o(ア) x(リ) z(マ) n(ス)Lc(セ) j(イ) d(カ) i(ク) b(ナ) d(カ) j(イ) Lc(セ) y(キ) h(ヲ) n(ス) w(ル) Rr(バ) o(ア) j(イ) r(ハ)f(テ) y(キ) Lc(セ) m(ツ) Rf(デ) r(ハ) b(ナ) j(イ) k(ウ) Rj(チ) d(カ) a(タ) r(ハ) f(テ) j(イ) Ly(ギ) Lg(フ) R,(ァ) j(イ) w(ル) d(カ) q(ラ) v(サ) i(ク) Ll(ジ) t(ョ) l(シ) f(テ) d(カ) q(ラ) d(カ) j(イ) Lc(セ) y(キ) l(シ) f(テ) i(ク) Ra(ダ) v(サ) j(イ)

　以上、ご報告まで。

毎回チェックありがとうございます．

調べたところ，そもそも半濁点のみ独立する配列の存在を考慮していませんでした．
キー列に直すロジックを少し改良してみました．
再度試してみていただけますでしょうか．．．
（ほかの解析への影響がちょっと心配(^^;）

　毎度お手数おかけしすみませんです^^;。
　濁点・半濁点絡みの解析はバッチリです。
　他の解析については……(とりあえず解る)AZIK-QWERTY.hmo_kanaと、自作系定義のストロークを追いかけてみましたが、怪しい解析をしている部分はおそらくないかと思います。
　対応いただきありがとうございます！

http://pc7.2ch.net/test/read.cgi/pc/1139243753/251
　上記スレッドより。同指異鍵判定に問題があるようです……そのまま適応してよいかどうかが不明なため、できましたら判定をお願いします。

内容確認しましたが，確かにその通りですね．
現状だと，同指異鍵，ではなく，同列異段，のような判定になってしまっているようです．

作るとき，あえてそうしたような気もしなくもないのですが・・・理由を失念．
ACT系で，縦の動きの少なさを確認したくてそうしたのかもしれないですが，同指異鍵のカウントとしては間違っていますね．

同指異鍵＆同列異段の両方のカウントを乗せる形がよいでしょうかね．．．

　「同列異段」のカウントが目的だったのですね。
　行段系配列では特に「うまく設計すれば確実に改善できる」所だと思いますし、この評価は(特に配列設計する人のために)重要ですね。
　できれば「同指異鍵」も別途カウント対象としていただけると嬉しいです。

hmo_kanaのドキュメントはないのでしょうか...
書き方がわかりません...

To ｱｻﾒ さん

hmo_kanaファイルは，姫踊子草の変換ファイルです．

姫踊子草の説明書の，その他の情報－情報ファイルの書式仕様，
のところに説明がありますので，そちらを参照してください．

姫踊子草は以下の場所から入手できます．http://hp.vector.co.jp/authors/VA011751/software/himeodorikosou/