方言を変換できるというインプットメソッドを使ってみる。わさ言葉は南部弁でがんす。・・・全滅。まず「わ(私)」から引っかかる。一人称でこけるようでは駄目。鼻濁音とかはどう書けばいいのだろう。
どこかに書いた気がしますが、JIS X 0208では基本的な挨拶である「未呀」は表示できても、「ｫ好(Lei hou)」は表示できません。「未呀」にしても「ｫ食♯(口偏に左)飯未呀？(Lei sik zho faan mei a?)」の形になれば表示できません。
JIS2004では？意外と北京語は(微少な文字の相違はともかく)表示できるのですが、広東語の表示には結構足りないようです。その多くは口偏の字なのです。上のzhoが例。他にも口偏に個とか。
しかし、JIS X 0213の目的は日本語文字の交換に使うことですから、こんなことはどうでもいいことなのでしょうね。なら、変体がながないのは何故？
南部弁とか広東語を書いてみて、生きている言葉を考えたり。
たとえばエスペラントは今でも普及しようとしている人がいますけど、結局死んでしまいました。これは多分文法的に例外を認めないその立場とわかりやすいという幻想でしょう。私はそういう言葉に魅力を感じません。ただ、堅苦しいだけ。 一方、広東語なんて例外がやたらと多い、しかも独立した言語として認められていない言葉です。香港系広東語はピジンと化していますし(「Li唔liky呀?」なんていい例)、文法構造の例外は腐るほど。漢語系(北京語との相違は日本語と韓国語のそれと同じぐらい大きいから、方言とする立場は支持できない)では比較的正書法が確立している方ですが、私たちの日本語(それが本当に共通語であるかどうかはともかく)がそうであるように、使っている連中はそんなこと意識していない。やたらと生き生きした言葉だから面白い。
南部弁はというと・・・お寒い限り。なぜか知りませんが、奥羽越列藩同盟を真っ先に裏切った連中(津軽、秋田)の方がしっかり使っているような気がします。それでも標準語使っていると称する東北出身の教官たちも、もちろん私も、よくよく聞けばかなり訛りがあるのですけどね。
も聞かれたけど知らない。私はあくまで紙に書いてからそれを入力するという手段を使っているから。ただ単純に文字の大きさについて聞かれたなら、平成書体がそうであるように小さいサイズでは漢字と同程度に(かすかに小さいくらいがいい)、大きいサイズでは漢字より小さく設計すればいいといえるのですが(したがって16ドットでは入力の段階で仮名の大きさは紙の上より大きくする)、設計方法なんてどうしたらいいか。
まずレタリングの勉強はお勧めしない(かならずしも必要ではない)。ディスプレイタイプの勉強にはいいかもしれないが、この技法をそのまま本文書体へ適用すると文字がやたらと目立つ・読みにくくなる結果となることが多い。ある程度の書体への理解が必要ですが。
たとえば本文用明朝系タイポスがあるが、今から見るとかえって読みにくいという人が多い(漢字と仮名が区別しにくい)。たしかに新書体の普及・発展という面では評価するが、あの方法が日本語の明朝系本文用書体の設計技法として最適であったかどうかは良くわからない(私は否定的である)。この書体についてはゴシック系の方が受け入れやすいようだ。
むしろ本文として読まれることを前提とした書道やペン字の本がいいかもしれないが、これらは意外と個性を重視するものである。したがってあまりにそれに走ると明朝なり、ゴシックなりの方向とから外れてしまう。たとえば石井宋朝(LS)や石井教科書体の旧版がその典型的な例である。
私はここで謄写版の教本をお勧めする。謄写版(ガリ版)はすでに廃れてしまったが、その字は本文として読むことが前提となっている。謄写版のやすりの溝はちょうどビットマップフォントのドットに相当するから、謄写版の沿溝製版の技法・考え方はビットマップフォントの設計に適していると私は思う。
について聞かれたが、私には理論的に説明できない。たぶん16ドット以下のサイズをしばらくやれば良くわかるかもしれないので、そうした方がいい。私は何だかんだで二万字ぐらい書いたけど良くわからない。ずいぶん感覚的なものである。困ったことに。
24ドット(から32ドットあたりがアウトラインとビットマップフォントの境であると思う)で線幅1ドットであれば、ほとんどの場合は省略する必要はない。しかし省略する必要はないと言っても、字形の歪みが著しければ(作者の美意識にそぐわなければ)一部を省略してバランスをとるということはよく行われる。
一方、それよりも小さいサイズになると省略を良く行う。これはたいていバウンディングボックス(描画領域)の縦方向の解像度(ドット)がないことで、横画が引けなくなるためである(漢字はたいてい縦画は横画より少ないので、横方向はあまり問題とはならない・・・8ドットでは「かなり」問題となったが)。実際、横線の引ける本数は電光掲示板表示用のようにドット間が離れていることを期待できる場合は縦の解像度に一致させることはできる(線引きしなくてよい)が、紙やコンピュータディスプレイ用のような場合は縦の解像度の半分になってしまう。
したがって省略を行うが、一般に必要以上の省略をすると読めなくなるか、違和感を持たれてしまう。点画省略は可読性を下げる原因となるから、ほどほどの所で止めるべきである。
さて省略の方法であるが、わたしは部分の優先度を考える。具体的な例としては「書」を挙げる。こいつらは横棒が一つくらい多くても気づかないものである。漢字を省略する場合、
例外として、私が「合画」と呼んでいるものもある。これは画の中で優先度が変化するものをその優先度が低い部分で別の画といっしょにする方法である。たとえば、「書」では「日」の真上の横棒を見ると両端では優先度は高いが、中心部ではそうではない。また「日」の中でも上部の優先度は比較的低い(が上下の空白がなければ誰も「日」と認めない)。したがって「日」の上部と真上の横棒を一つの画としてしまうことができる(が16ドットではそこまではないのでそうしていない)。
また、昔使っていた技法であるが「貝」など含む字の省略手法として、優先度の低い「目」の中央の二画を途中であわせるという方法がある。たしか富士通(モトヤ製)やEPSONではそういう手法を用いていたはずである。
出水ゴシック体-M 16ドットフォント(IZMG16-N)ですが、ドットサイズまで明記することを希望します。というのは内部的に他のサイズを作成しているためです。最低でも出水ゴシック16と呼んでください。えらく困ります。
また、OSASK用に提供されているものは1バイト部が聖人さんによるもの(今のIZMG16-Nは本来Izumi-Universと組み合わせるように設計している)ですから、くれぐれも「出水ゴシックの半角部分」などと言わないでください。現状ではFONTX2/bdf/OSASK版のすべてで不正確きわまりない表現です(私がTTF版を公開することがあればそうではないでしょうが)。
というのを考えたり。たとえば麻薬フォントは東芝由来(東芝のが何由来とかはあえて述べない)ですし、NagaraフォントはNEC(PC-9801 ROM+jming16)由来です。こいつらは誰のものなんでしょうか?
このような商用からという明らかな問題があるものでなくとも、JIS X 9051/9052(jiskan16/24)由来であるとか、橘フォント(k14)由来であるとかいうものはいくらでもあるのです。どこから別物であるかというのは疑問です。明確な解釈はないのでしょうか。
とりあえず、各フリーフォントの由来の調べもの。ここで先月書いた理由で芦屋は除外。
を大学から入手。恐ろしい大学です。とはいいつつ自分にとって親指シフト以外のキーボードなんて使う機会がない(あえてあるとすれば英語環境で、ということになる)ので動作確認程度の扱いしかされていません。悪いキーボードではないのですが。
思い付いた使用例。JIS_A01キーボードドライバ併用でWebBoyを使うとき(おい)。ちなみにこのキーボードをJIS_A01なり、IBM PC DOS 7.xのキーボードドライバと組み合わせて使う場合、普通の旧JIS(新JISは廃止されましたが・・・)として認識されるため、キートップの表示と入力が一致しません。ですが、WebBoyはJIS_A01のキー入れ替えを殺してくれる(DOSに降りたら『半分』元に戻る)のでWebBoy上では普通に使えるという、そういうわけ。
での親指シフトキーボードエミュレーションの話の続き。モバイルギアでの親指シフトキーボードエミュレータである親指ぴゅん for MobileGear(OKPM)ですが、当然のことながらUnishellでは使えません。常駐させたままUnishellを起動するとハングアップします。
あと、「う」キーをよく取りこぼすという問題があるみたいです。私の入力が速いというわけではないと思いますが(『う』は左中段小指のキーなのでちゃんと押していないのかもしれない)、ローマ字では取りこぼしはないようなので多分OKPMの問題でしょう。
余談。よく取りこぼすので壊れはじめたと思って(2時間で実験レポートを書き上げるという極限状態だったので、無理ないと思っていた)、TOWNSで入力しはじめると辞書が足りないわけでして。これは科学用語をMobileGearに入れてTOWNSは別用途に使っているため。かといってFMV-KB211(on Win)だとなあ。
旁が莫の字の修正が不完全のよう。『ム』は改良の余地あり。『原』は前の方がよかったか？原の白の部分の優先度は比較的高いから、このままでいいと思う。
以前公開した方がよいかと書いた木原さんの蕨12であるが、改定BSDライセンスの扱いが問題なので(著作権が認められていない、名称どうこうなど)、FONTX2版の公開を諦める。仕方ないので組み合わせの方法を書く。
について。多分改良版を出すと思う。受験時期にいいかげんに作ったという事実があるので、高専の字が特にいいかげん。曲線であるべき部分が直線で結んである、動作しないOSがあるなど。少し前に高専に出したので、広まる前に片づけないとまずい。
現所属のシンボルをTrueTypeで作成する予定。作成が必要な理由はあおしまさんのMETAFONTがAkiuの閉鎖により入手できないためと、品質および他環境での利用のため。ちなみに、東北大学のシンボルには工学部の学生が作ったものと北斗七星とがあるがどちらも正式に承認されたものではない(が、いずれも公式なものとして扱われている)。また、SKKのも必要か? 来年に新しいシンボルを作るらしいのでその時期か。
を公開。今回は作業の都合上(面倒だっただけという)、FONTX2形式のフォント単体を圧縮しただけでドキュメントやスクリーンショット、JIS2000版やbdf版を用意しなかった。今回の更新では仮名の改良と相当数の漢字の改良をしている。
DR DOS/VのようなDOS/V環境で106キーボードを使って親指シフト入力する方法として、ホーテンス・エンドウさんの親指ぴゅんfor DOS/V(OKPV)が知られていますが、このソフトではキー入力に対して相当する文字が(所謂)半角かなで出力されます。そのためOAKVのような半角かなでの入力を認めない、つまり「3」を入力したとき「あ」となるFEPでは使えませんでした(富士通の親指シフトキーボード、FMV-KB211などではそういう出力をする)。
OKPV以外のキーボードエミュレータとしては、KNOCKとNICOLATIというものがあります。このうち、KNOCKはハードウェアの改造が必要(もともと101英語キーボードでの使用が目的)で実験していません。
もう一方のNICOLATIは出力がローマ字で出力するため、OAKVなどでは問題なく動作します。(OKPVでは半角カナで出力するため、OAKVでは漢字変換できなかった)しかしシェアウェア(1500円)。IBMSKK/MKKやWebBoyやMS-Win3.xで動作しません。
OKPVのソースのかなのテーブルを書替えれば半角かなの問題はなくなるので、シェアウェアの意味がないような。(ただし、OKPVでもWebBoyやMS-Win3.xでは使えない)
あと、InterTop用の親指シフトキーボードのドライバは動作しませんでした。
私が使っているDOSモバ(MobileGear MC-K1)ですが、私自身が親指シフト使いであるためあまり使っていませんでした。ホーテンス・エンドウさんの親指ぴゅんのDOS/V版(OKPV)では106キーボードとして認識されないためMac同様変則的な入力形態になります。実は専用のキーボートエミュレータが存在します(親指ぴゅんのMobileGear版: OKPM)。がNiftyのFNECMCにしかないようです。
すみません。私自身はM式・快速式を使っていません(いつも言っているように親指シフトです)。しかも森田正典氏の他の方式との比較はほとんど信用していません。それはキーボードの習熟は学習方法に依存し、個人差が大きいからです(単純に方法について考察せずにある印刷会社の平均の実績を掲げるのは科学的ではない)。
また、M式の打鍵省略による快速化はあくまでソフトウェアの問題であり、それを含めて比較することは不適切です(あえていうならNTT-SKY、きゅうりやDvorakキーボードのようなローマ字系の入力手段で、そのような省打鍵技術を導入したらどうなるか？とか、親指シフトでJapanistのようなInput Methodで省打鍵するのではどちらが優位か？とか)。T/TUT-Code(豊橋技術科学大学)のような無連想方式との比較はどうか？そこまで来るともはや価値観の問題でしょう。
配置もそう。手のデータまで取ってL、M、Sの三サイズを用意したTRONキーボードに親指シフトなりM式の配列を実装したらどうか？とか。私は物理(キー配置)・打鍵(人の負担)・処理(機械の負担)のレイヤーで考えないと適切な評価はできないと思います。
閑話休題。快速式というのはM式(森田式)キーボードのサブセットの一つで、NEC文豪シリーズの標準入力方法の一つです。右手に子音、左手に母音が配置されていて左右交互打鍵しやすく考えています。類似の方法としてNTT-SKYがありますが、左手中段がNTSKYと母音と子音が快速式・M式と反対になっています。
DOS/Vでの実現方法として私は森川治さんのKey4cを使用しました。キー設定は以下の通り。
; 現在のキー変換の様子
; キーボード 機能
init
A <= E
B <= V
C <= .
D <= I
E <= J
F <= A
G <= O
H <= K
I <= R
J <= S
K <= T
L <= N
M <= Z
N <= G
O <= W
P <= P
Q <= Q
R <= F
S <= U
T <= C
U <= Y
V <= X
W <= L
X <= ;
Y <= M
Z <= /
. <= ,
, <= D
/ <= B
; <= H
この方法の問題は鳳のようなキー配列にシビアな多段シフト方式での文字入力が困難であることがあげられます(仮想鍵盤と実在キーの位置がずれて全く使えない)。また、IBM WebBoyでは動作しませんでした(MS-Windowsでも動かない)。また、この配列は本来の配列と異なり「x」キーに「;」を割り当てている(本来は「・」)といった違いがあります。
SKYはこの方法では難しいと思います。この場合鳳のようなキーカスタマイズ機能がある、かな漢字変換FEPのテーブルを書き換えることで処理できそうですが、実験していません。