というわけで, ひと夏越しの作戦も終了となりました.
アーヴ文字の TrueType 形式フォントを作られているかた, 超漢字用フォントも
一緒に配布していただけませんでしょうか ?
連絡をいただければ, わたしのほうで変換 ( TrueType 形式の部分はそのままで,
コードの配置等の情報を付加したものとなります) はおこないます.
どうかよろしくお願いします.
ほかには,
超漢字用・文字変換小物
でアーヴ語のアース表記 <=> ラテンアルファベット表記の実験とかしてみたい
ところですが, しばらくお休みします.
上記は文字収録センターによる頁です. これ以外にTRON 文字コードにアースを割り振ろう !の頁にもいくつか関連資料があります.
TRON 文字収録センターで配られている、 フォント登録用実身を使うのが簡単です.
以下の内容は, TTF フォントから登録用実身を生成する方法を述べたのもで,
収録センターで配布していただけるとかそういうことがまったくわからなかった
時点で作った物です.
少々ですが, 失敗した場合の危険がまったくないとは言い切れない手順なので,
説明を見てうまくできるか, 自信がないかたにはおすすめできません.
この頁は, TRON 文字コードにアースを割り振ろう !に荷担している「きしもと」による,
主に技術的な解説を主たる目的とした頁です.
え〜 「技術資料」というお言葉を頂いてしまいましたが (^^; 一応技術資料なんですけども,
どっちかというと HowTo 的な内容なので, 正確な仕様とかは正規の仕様書とかの資料を
参考にしてください m(__)m
アースが生んだ正義はマグマー (ばき) ← 関係ありません
そのうち, 階層的に上のほうの頁での解説を充実させるつもりなのですが, いつになるやら
わかりませんので, 簡単なまとめを書いておきます.
わかってるひとは適宜読み飛ばしてください.
ハヤカワ文庫 JA にてシリーズ化されているスペースオペラ小説「星界シリーズ」中の, 架空の未来世界における星間種族「アーヴ」の言語「アーヴ語」の表記に使用される文字が 「アーヴ文字」で, アルファベットによる代用表記, および, 音 (おん) のカタカナ表記が, それぞれ "ath" (アース) となります.
原作小説の冊子中では, 附録として格変化と単位系の簡単な解説が代用表記で
示されているのみですが, 著者によって言語体系が構築されており, ファンブック等に
詳細な解説が載っています.
また, アニメ化の際に, フォントがデザインされたり, アーヴ語によるナレーションという
演出がなされたりしました.
劇中にも (さらにコミック化されましたが, その画の中にも) 文字が書かれています.
もっと詳しいことは, TRON 文字コードにアースを割り振ろう ! の頁, および同頁からのリンク先などを参照してください.
和音倫理委員会、すなわちコード・コード委員会 ―― 「脱走と追跡のサンバ」より
そのうち, 別のほうの頁での解説を充実させるつもりなのですが, いつになるやら
わかりませんので, 簡単なまとめを書いておきます.
わかってるひとは適宜読み飛ばしてください.
Toudai ni ita koRONi tsukutta operating system ―― 「電脳都市」より
"TRON" (とろん) は "The Real-time Operating system Nucleus"
の acronym です.
坂村健プロジェクト・リーダによってはじめられた, コンピュータ・アーキテクチュアを
システムの全体にわたって構築しよう, というプロジェクトが「TRON プロジェクト」で,
その成果であるアーキテクチュアを一般に指して「TRON」といいます.
TRON プロジェクトは, 人間の身のまわりのあらゆる「モノ」にコンピュータが組み込まれ,
それらが協調する「超機能分散環境」 (ちょっと前にちょっと流行した言葉では
「ユビキタス・コンピューティング」, プロジェクト・リーダがよく使う言葉では
「どこでもコンピュータ」) を最終目標にしており, 一般に使われるよりも広い
範囲を「アーキテクチュア」に含ませています (ヒューマン・マシン・インタフェース (HMI) など) .
TRON のその他のことに関するもっと詳しいことは, TRON 文字コードにアースを割り振ろう ! の頁, および同頁からのリンク先などを参照してください.
上記のように TRON プロジェクトでは「コンピュータがつながること」を重要視します. そこで, 情報交換のためのアーキテクチュアが独立して定義されています. それが, 「TAD」(たど・たっど : TRON Application Databus) です.
コンピュータのあいだの情報のやりとりは, 一般に「ビット」のやりとりです.
しかし, やりとりをおこなうすべてのコンピュータが「ビット」の「意味を理解」
できなければ, その情報は無意味といえます.
このことに関して, TRON が何を問題としているか, 例で説明します.
例えば, 俗に「BMP ファイル」と呼ばれる Microsoft Windows (及び OS/2) のビットマップ ファイルは, 先頭が "BM" というバイト列ではじまります. 単純に逆を考えれば, 先頭が "BM" で始まれば BMP ファイルである, と言えそうですが, もしかしたらテキストファイルの 先頭が偶然"BM"というバイト列ではじまっているのかもしれない, とも考えられます.
BMP ファイルの場合, 他の要素から推測することも可能でしょうが, どっちみちそれは 「推測」すなわち当てずっぽうでしかなく, 推論による帰結ではありません.
この例における問題の起源をたどるならば, ファイルを単なる「バイトのかたまり」と見倣した Unix に
行き着きます. Unix では, システムはファイルの中身に関与しない, という方針によって,
システムの単純化に成功しました. そのかわり, 一部の例外を除いて, ファイルの中身を
把握するのは利用者の責任とされたわけです (注 : ファイル名にピリオド (".") を
セパレータとして適切な拡張子を付けることが慣習となっている. また近年では
アプリケーションソフトウェアのプログラムがよきにはからってくれるので,
利用者の負担がさほど大きいわけではない)
また, Microsoft Windows では, ファイルの中身に関与しないのは MS-DOS が CP/M および Unix から
引き継いだ伝統ですが, MS-DOS 時代のファイル名の形式のなごり (こちらの先祖をたどると,
CP/M に, さらには Unix 以外のミニコン OS や汎用機の OS に行き着く) である, ファイル名の
「3 文字の拡張子」の部分に責任を負わせています.
「OS がファイルの中身に責任を持つような」システムでは, 中身が何であるかによって強制的に
拡張子が付く, というようなものもあります.
(Macintosh では, ファイルに対して, タイプとクリエータという情報が保持され, さらにデータフォークと リソースフォークという 2 種類のデータ保存領域が用意されている (さらにコメントも最近は付けることが できるらしい ?). このうち, データフォークに本体が入り, 他の部分の情報で中身が識別される, という 仕掛けになっている)
TAD は, 「あらゆる情報を載せるための, バイト (オクテット) の並びについての
アーキテクチュアを規定する」ことで, 「ファイルの中身」について, 「どんな種類の情報も
同じ枠組に従って扱うことができるように」作られています.
逆に言うと, TAD に従ったソフトウェアは, TAD に従ったファイル (バイト列) であれば必ず
扱うことができる (全てを完全に解釈することはできないかもしれないが) ということです.
(Macintosh との比較で見た場合, TAD はデータそのものを規定しているという面で, ファイルの 中身についてより強く規定しているといえる. また, Macintosh のシステムとの比較としてみた場合, ファイルシステムに依存していないといえるであろう (相対的な話であって, TAD が全くベースとなる システムに依存しない, ということではない))
TAD データを構成する最小の要素は「セグメント」と呼ばれるもので. バイト列中のバイトの,
1 個以上のかたまりです.
TAD の構造の詳細について興味があれば, 別コンテンツ「TAD
パーザを書こう」が参考になるやもしれません.
さて, TAD の中において, 「文字」の情報に直接関係するのは, 「固定長セグメント」と呼ばれる セグメントです (この名前は現状ではあまり正確ではありません. 面の変更 (後述) のためのコードが 任意の長さになりうるためです. 「可変長セグメント」が, セグメントの長さが明示されるのに対し, 長さが明示されない (暗黙のうちに長さが決定する) セグメント, という感じでしょうか)
この「固定長セグメント」を, コードとして見る場合「TRON コード」と呼びます.
やっと, 本題にたどりつきました.
TAD において文字の情報を表現するためのコードで, 現状では「文字」ではなく「グリフ」に
コードを振っています.
0x21 〜 0x7E, 0x80 〜 0xFD の範囲のバイト 2 個 (2 バイト) で 1 個のグリフをあらわし, 1 個面に
48400 個入ります. 面の切替えは 0xFE 0x?? (?? = 21 〜 3F) というコードによって, 第 1 面から
第 31 面までを切り替えます. この 31 個面は, 「スクリプト面」, すなわち「グリフ」が納められる
面であるとされています. (全部で 1500400 個ぶんあることになります)
将来的には処理系に「文字属層」が整備され, コード 0xFE 0x40 〜 0xFE 0x7F で切り替えられる
面には「言語面」として「文字」が入る, ということになっているようです.
(2001 Oct 29 訂正) 0xFE 0x40 〜 0xFE 0x7F は「言語切替えコード」であって、「面」を
切り替えるのではないようである。よって「言語面」というものが存在するわけではないようだ.
(TRONWARE Vol.50 を再読しました)
また, それ以降の 0xFE 0x80 〜 0xFE 0xFD は一応予約になっているようです.
さらに面が必要な場合は 0xFE 0xFE 0x?? というように 0xFE の繰り返しが延びることになっています.
スクリプト面について, 先に説明した 31 個面が仮にあふれたとしても, 仕様上は割り当てを無限に拡張できるように
なっているということです.
現在の処理系の実装では, 0xFE が 128 個まで延びるまでは対応できるようになっているようです. (B-right/V 仕様書 (これは, 製品 B-right/V (実装) についての仕様書であって, BTRON3 (アーキテクチュア) の 仕様書ではないことに注意) 3.1 tlang.h について と 3.3 wtstring.h について の記述を参照, 仕様書の記述は準 TAD を前提にしているので注意) ただし, そんなに長くなると実身名とかには事実上使えません (ファイルシステム中の固定長の領域に入り切らないため. 詳細は略します) が.
とにかく, TRON コードはこのような枠組によって, あらゆる文字 (現状ではグリフ) をコードに割り振ることに なっています.
アースを使用したデータを「アースである」とはっきりわかるかたちでのこすことが できるようになります. また, 検索, 入力のための辞書 (カタカナ表記→アース), アース配列キーボード定義などもできます.
なにはともあれ, フォントを用意して登録すれば, B-right/V (超漢字) で, アースが
使えるようになります.
現状では, フォント名についての登録機関などがないので, フォント名やフォントの
選択についてはそれぞれの環境に依存することになってしまいますが, 少なくとも
文字の対応については相互にデータをやりとりしても正しく見えるはずです.
(フォントが登録されていなければちゃんと「とーふ」になります)
某斗論黒頁の某底哀日記にて
このあとキーボードマッピングとかも用意する予定。
と書かれてしまったので補機もとい補記.
超漢字 2 以降の B-right/V (R2.5xx 以降) には, 「世界文字入力」という機能があり, 『世界文字入力』小物か, あるいはキー操作 (抑制可能) によって, さまざまな 言語に対する「入力モジュール」を選択できるようになっています (OS の機能ではなく ソフトウェア製品「超漢字」としての付加部分相当かもしれません) .
入力モジュールの選択によって, キー配列, テキスト入力プリミティブ (いわゆる
「日本語入力フロント[エンド]プロセッサ」とか「インプットメソッド」とかのようなもの) の挙動,
入力変換辞書 (ローマ字→かな, のような),
文節変換辞書 (いわゆるかな漢字変換, のような) などを一貫して切り替えられるようになっています.
キー配列以降の, 入力を変換する部分の仕組みを「TransGryph (トランスグリフ) 」 と呼ぶようです.
(超漢字 2 以降を持っていたら, オンラインマニュアル (『取扱説明書』小物) の,
目次→基本項目→アクセサリー→世界文字入力→言語モジュールをつくる→基本概念 あたりを見てみてください)
(注 : 便宜上「キー配列」という表現を使っていますが, 厳密には『キー配列変更』小物で変更できる「キー配列」
とは別のものです)
幸い, アースの表記は非常に単純なので, キー配列さえ定義すれば, TransGryph はふつうの
「英語モード」 (キー配列がそのまま入力される) に準じたもので済みます.
実際に, ナインライブス配列のフォントの割当位置を qwerty 配列キーボードに対応させた
キー配列と, 入力モジュールを試作して某処でデモもおこないました.
(試作では, 大文字と小文字で位置を入れ換えました)
現在, プロジェクト内部で, まずラテンアルファベットによるアース表記に準拠したものの 試作評価をしています.
配列もちゃんと独自に定義しようという声が聞こえてきておりますが...
やるの ? 頻度調査 ? 誰が (^^; ?
考察の結果, 以下のような配列が必要かと考えています (これはプロジェクトとは
別の個人的な試案です)
なお「論理配置」とは, 既存のラテンアルファベット配列に入力法マップすることを,
「物理配置」とはキーにアースを割り振ることを意味します.
「夏」の臨海副都心で妙なものを (こんなの と一緒に)
見た記憶のあるかたはいますでしょうか ?
あそこに居たのがわたくしめでございます.
登録に際し, 排列を決定するにあたって問題となったのが, 文字の上に付く横棒や 2 つの点は「構造」か否か, ということでした (「構造」とは, ひらがなやかたかなに付く濁点や 半濁点のようなものを指します) . 結論としては, 「構造ではない」ということになりました (詳細は後日別項にて)
. . . . . .
koganei.zip
「収録センター」に送ったフォントの中身 (TTF のみ) です.
超漢字に直接登録することはできませんのでご注意ください.
アーヴ語の世界 (Sidryac Borgh=Racair Mauch さん)
言語学的にはたぶん最も詳しいアーヴ語の頁