秀丸エディタにおいて、［その他］->［ファイルタイプ別の設定］で「OK」、「キャンセル」の他に「保存しないで更新」ボタンがある。
これをどのような時に使うのか、何度も忘れてしまうので書き留めておく。
簡単に言えば、「保存しないで更新」をすると、その設定は今開いているファイルに適用されるが、そのファイルを閉じれば（ファイル自体は上書き保存しても）、そのファイルタイプ別の設定は保存されない。つまり、元のファイルタイプ別の設定は書き替えられずに済む。
面白い（と思った）のは、ファイルタイプ別の設定はファイルの拡張子ごとに登録するが、例えば現在開いているファイルの拡張子が「.txt」であれば、「.txt」の拡張子のファイルにどの設定を適用するのかを決めるのだが、ドロップダウンリストにあるどの設定を編集して「保存しないで更新」しても、現在開いているファイルにその設定が適用され、もう一度［ファイルタイプ別の設定］を開いてみると、その設定はドロップダウンリストの「（一時的な設定）」に現れる。
そして、下の「OK」ボタンだった所が「強制的に保存」／「名前を付けて保存」ボタンに変化している。「強制的に保存」を選ぶと、この一時的な設定が現在開いているファイルの拡張子に関連付けられた設定として保存される。「名前を付けて保存」を選ぶと、一時的な設定が新たな設定として保存されて現在開いているファイルの拡張子に関連付けられる（元々関連付けられていた設定は書き替えられずに残るが拡張子との関連付けが解除される）。設定を保存したくない時は、「キャンセル」または「保存しないで更新」をクリックすればよい（「保存しないで更新」を選んでもその設定は一時的な設定のままだから）。
シフトJIS では、第3水準・第4水準の漢字を扱えないのか？ 番外編(2)－EUC-JP－
この一連の投稿の発端となった疑問は、「シフトJIS では、第3水準・第4水準の漢字を扱えないのか？」なので、EUC-JP の話はまさに番外編であるが、「嚬」という第3水準漢字を秀丸エディタの［表示］->［文字コード表示］で見た時、Shift-JIS は該当するコード無しだったが、EUC は 0x8FB6E4（0x は16進数の意味）だった。エンコードの種類を日本語（EUC）にして保存することも出来る。ということは、EUC-JP は第3水準・第4水準を扱えるのだろうか？
EUC-JP は、文字集合として、ASCII、JIS X 0201 のカナ部分、JIS X 0208、JIS X 0212 を使う文字コードである。
結論から言うと、JIS X 0208 は第2水準までであるし、JIS X 0212 には第何水準という概念がないので、EUC-JP で「嚬」を扱えるのは、EUC-JP が第3水準の文字を扱えるからではなくて、「嚬」が JIS X 0212 に収録されているからである。
しかし、ここまで書いたので、EUC-JP がどのように ASCII、JIS X 0201 のカナ部分、JIS X 0208、JIS X 0212 を符号化しているのか見てみたい。
EUC-JP は、G0 にASCII、G1 にJIS X 0208、G2 にJIS X 0201 のカナ部分、G3 にJIS X 0212 を指示しておき、G0 を GL に、G1 を GR に呼び出しておいて、SS2 と SS3 でそれぞれ1文字分の間だけ G2 とG3 を GR に呼び出す文字コードなんだそうである。
G何たらや、SS2、SS3 については説明が必要であろう。これには歴史的経緯があるらしく、これについて詳しく書かれている文献は、今は絶版になっている『インターネット時代の文字コード』（共立出版、2002年）があるのだが、私の情報源もこの書物なので、これについて書くとなるとほとんどこの本からの引用になってしまう。ついては、なるべく簡潔に今ある姿を書いてみたいと思う。
G何たらの元祖の G0 は、ASCII を元にした ISO 646 の印刷可能文字が配置されている、16進数で21～7Eの94文字分の枠である。ここにエスケープシーケンスを使って様々な文字コードを指示するのが、ISO 2022 の基本アイデアだった。
G1 ～ G3 は、G0 のようなものと考えて良いが、20～7Fまでの96文字分が使えるらしい。G1 ～ G3 それぞれに、様々な文字コードを呼び出すためのエスケープシーケンスが存在する。
GL は20～7Fまで、GR はA0～FFまでのの96文字分の枠で、G0 ～ G3 を GL や GR に呼び出すための機構が多数存在する。それも、呼び出しっぱなしにしたり、1文字分だけ呼び出したりだ。そして、どうやら G0 は GL には呼び出せるが、GR には呼び出せないらしい。
この説明でも、正確性を犠牲にしたかもしれない。それほど、ISO 2022 は複雑である。
さて、EUC-JP は、最初から G0 に ASCII、G1 にJIS X 0208、G2 にJIS X 0201 のカナ部分、G3 にJIS X 0212 が指示されているものとしているので、エスケープシーケンスは使わない。（因みに、通称 JIS コードと呼ばれるものは、ISO-2022-JP のことで、これはエスケープシーケンスを使って文字コードを切り替えている。）G0 の ASCII は GL に、G1 の JIS X 0208 は GR に呼び出されているものとする。その上で、SS2（バイト列では8E）を使うと、1文字分だけ G2 の JIS X 0201 のカナ部分が GR に呼び出され、SS3（バイト列では8F）を使うと、1文字分だけ G3 の JIS X 0212 が GR に呼び出される。
具体例で見ることにする。
21～7Eは ASCII である。（制御文字については、各自で規格書を読んでほしい。）例えば、「A」は EUC-JP で 0x41 だ。
そして、8Eも8Fも出て来ない時のA1～FEは2バイトで JIS X 0208 である（GR はA0とFFも使えるが、この場合は使わない）。例えば、45区93点の「理」は、区の45に0xA0（0xA1から始まるので）を10進数に直した160を足して205、これを16進数に直した0xCDが1バイト目、点の93に160を足した253を16進数に直した0xFDが2バイト目。よって、EUC-JP で 0xCDFD だ。
8Eが出て来た時は、これは SS2 なので、その次のバイトはA1～FEに JIS X 0201 のカナ部分が来る。よって「ｱ」（半角カタカナ）は EUC-JP で 0x8EB1 だ。
8F（SS3）が出て来た時は、その次の2バイトはA1～FEを使って JIS X 0212 を表現する。JIS X 0212 の22区68点に存在する「嚬」は、区の22に0xA0を10進数に直した160を足した182を16進数に直して0xB6が2バイト目、点の68に160を足した228を16進数に直した0xE4が3バイト目であり、EUC-JP で 0x8FB6E4 という結果が得られる。
繰り返しになるが、「嚬」が EUC-JP で表すことが出来るのは、この文字が JIS X 0212 に収録されているからである。
例えば、JIS X 0213 の2面4区50点に存在するが JIS X 0212 には存在しない「嚲」は、EUC-JP では表現できない。
InDesign における漢数字、約物、漢数字の間のアキ
ある時、InDesign の組版で「五、六年」などの表現の「、」の後が少し詰まっていることに気付いた。
最初は、文字組アキ量設定の問題なのかと思って、設定を変えてみたりしたのだが、影響なしだった。
これは、連数字処理がオンになっていると、数字の間の「、」を桁を区切るカンマ（,）のように認識してしまってアキを詰めるという現象だった。明らかに日本語の「五、六年」とか「二、三人」という表現は、数字の桁を区切るカンマとは違うのだが。Indesign がそのように出来ているのだから仕方がない。
この現象を回避するためには、連数字処理をオフにすれば良いだけである。
段落を選択して、段落パネルメニューの［連数字処理（欧文数字を除く）］のチェックを外すか、段落スタイルを適用している場合は、段落スタイルの編集から［日本語文字組版］ -> ［連数字処理（欧文数字を除く）］のチェックを外す。
尚、［連数字処理（欧文数字を除く）］のチェックを外しても、欧文数字の連数字処理はされるので、このチェックは外すことの方が多いのではないだろうか。
この件は、インターネットで「InDesign 連数字処理」で検索すると複数報告されているので、InDesign 使いの間では割とよく知られた現象なのかもしれないが、漢数字、約物、漢数字の間のアキの問題が連数字処理に起因していることに気付くまで少し時間を要したので、ここに書き留めておく。
ワールド
はじプロで作るゲームの舞台となるワールドについて。
ワールドは3Dである。2Dのゲームを作りたい時も、ワールド自体は3Dなので、ゲーム画面ノードンを使って横から見たり上から見たり、フリースライドれんけつノードンを使ってモノが移動できる座標を制限したりすることによって2Dっぽくする。
ワールドノードンを呼び出さなくても、ワールドは存在する。ただし、ワールドノードンを使うと、ワールドのかたち、みため、ライトなどを指定できる。
ワールドには、おおきさとは別に端がある。その端は、X、Y、Z座標の-409.6メートルから409.6メートルである。どういうことかと言うと、例えばワールドのかたちをユカに指定して、そのおおきさを上限のX、Z座標それぞれ200メートルに指定しても、その外も存在するということである。
モノがワールドの外にはみ出した場合、そのモノは消滅する。よって、操作したいモノがワールドの端より外に行ってしまった場合、そこでゲームが動かせなくなることもある。これを防ぐためには、そのモノに位置センサーノードンを付けて、その値が一定を超えた場合にリトライノードンやゲームおわるノードンを使って、その膠着状態を回避することができる。
実際、私が最初に作って公開したゲームでは、モノがワールドの外にはみ出した場合の対策を施していないので、飛行機がワールドの端を超えてしまった場合、操作できなくなってしまう。
その後公開した別のゲームでは、車に位置センサーを付けて、Y座標の値がある一定値よりも小さくなった時、つまりワールドのユカから落ちた時にゲームをリトライする仕組みにしている。
はじプロ
私はプログラマの端くれであるが、本格的なゲームを作ったことはなかったので、Nintendo Switch の『ナビつき！ つくってわかる はじめてゲームプログラミング』（略して「はじプロ」）でゲームを作ってみた。
これは、自分のプログラミング能力の向上と、はじプロ自体のポテンシャルを確かめる両方の意味合いでやってみた。
結論から言うと、はじプロでもそれなりのゲームを作ることは出来たと思うが、やや独特な部分もあったので、忘れないうちに書き残しておきたい。
先ずプログラミングの仕方であるが、プログラミング言語を使って行うのではなくて、「ノードン」を使ってヴィジュアルに行う。このノードンというものは、オブジェクト指向のクラスみたいなものと考えて良いかもしれない。ノードンとノードンをワイヤーでつないで、シグナルを送ったり、物理的に連結したりする。そして、ユーザーによる入力や何らかの条件が一致した時にノードンがシグナルをファイヤして別のノードンがそれを受け取るので、イベント駆動型と言って良いだろう。
今回は、これくらいにして、次回からはもう少し個別の話題について書いていきたいと思う。
シフトJIS では、第3水準・第4水準の漢字を扱えないのか？ 番外編(1)－JIS X 0213 が第1面に追加した非漢字を何と呼ぶか？－
2000年版の JIS X 0213 は、JIS X 0208 で規定されていた6879文字に4344文字加えて、計11223文字を規定している。JIS X 0208 に比べて増えた文字は、第1面に1908文字、第2面に2436文字である。
第2面の2436文字は全て第4水準漢字である。第1面に追加した1908文字については、漢字以外も含まれる。具体的には、丸付き数字などである。これらの文字は、第何水準と呼んだら良いのだろうか？
JIS X 0213 の規格書を読んでみると、この規格の定義する「漢字集合」は、「この規格で規定する図形文字集合の全体」（4. c)）であり、「漢字集合中の図形文字の種類」は「特殊文字、数字、数字に準じるもの、ラテン文字、拡張ラテン文字、平仮名、片仮名、ギリシア文字、キリール文字、漢字、囲み文字、けい線素片及び互換用文字とする。」（6.5.2）と書いてある。
その上で、6.5.2項の j)「漢字」のところを読んでみると、「JIS X 0208 の第1水準漢字集合2965文字及び第2水準漢字集合3390文字の計6355文字並びに第3水準漢字集合1249文字及び第4水準漢字集合2436文字」とあるので、第n水準漢字集合と言った場合、「漢字集合」の中でも特に漢字（つまり、特殊文字、数字、数字に準じるもの、ラテン文字、拡張ラテン文字、平仮名、片仮名、ギリシア文字、キリール文字、囲み文字、けい線素片及び互換用文字は含まない）を指していることがわかった。
よって、JIS X 0213 が第1面に追加した1908文字の内、1249文字は第3水準漢字だが、残りの659文字に関しては第3水準漢字と呼ばない。
ここで改めて、この規格の冒頭「1. 適用範囲」を読むと、「この規格は、第4水準漢字集合を除く8787文字からなる符号化漢字集合と第4水準漢字集合の2436文字からなる符号化漢字集合との二つの符号化漢字集合を規定する」とある。第1水準漢字集合2965文字と第2水準漢字集合3390文字、第3水準漢字集合1249文字を合計すると7604文字なので、「第4水準漢字集合を除く8787文字からなる符号化漢字集合」と言う場合の漢字集合は、狭義の漢字集合ではなくて、JIS X 0208 の6879文字とJIS X 0213 が第1面に追加した1908文字、つまり狭義の漢字以外も含めた第1面に存在する全ての文字を指している。
更に、3.2.1項には、「この規格の実装水準3に対して適合性を主張する場合、この規格で規定する文字のうち第4水準漢字集合を除く8787文字のすべてを実装し」と書いてあるので、JIS X 0213 が第1面に追加した1908文字の中の1249文字の第3水準漢字以外の659文字も「実装水準3」に含まれることになる。よって、JIS X 0213 が第1面に追加した非漢字を「第3水準」と呼んで良さそうである。
