ぐるぐるリストにちょっと追加。他にもまだまだ読んでるはずです(^^;
にやり。東鳩日記のエピローグの回想シーンは、私の妄想力をフルに発揮して書かれております(^^;; この状況だとやっぱこうだよなーとお約束なのですが、それを書いてみるのもまたたのし:-)
6/3〜6/5 にある WORLDNET/INTEROP98 の展示会に行くかどうか思案中。招待券はボスにもらう予定。 6/3 に FreeBSD の BOF がある そうなので、それにちょい参加してみたいなーってのがあったりするんですねぇ。ついでに 6/7 に BNL3 があるので、それもいきたいなーと(^^;;。こっちが本命だったりして...
問題は寝床ですが、とりあえず部長の家にお世話になってもよいとのこと。かわりに6/6 はお手伝い(^^;
うーむ、どうしようかなぁ。
というわけで、電波の日記念絵(101KB)です。
...最近前にもまして自爆ぎみかも
あ、ちなみに今日は楓ちゃんがらぶりぃです(謎)
ふとこちらを見て思い立ったので、たまには高度な? 話題を(^^; X Window System の描画系についての解説です。入力系はパス。本当はこれにさらにメトリック系の話が加わりますが、それもパス。ちなみに、書いてみた結果、かーなーり長いです。
X Window System においては X11 から 16bit のテキスト描画命令が拡張されており、次の6種類のテキスト描画関数があります。
DrawString/DrawImageString は特定フォントに対する単純な描画を実現するものです。X Protocol の PolyText8/16, ImageText8/16 に対応してます。 16がついているものは、2byte フォントに対応している関数で、引数が char *string でなく、XChar2b *string になります。これらでは同時に単一の文字セットしか扱うことができません
DrawString では文字が GC (Graphics Context)で指定された前景色で描画され DrawImageString のほうはさらに背景が GC に設定された背景色でぬりつぶされます。
GC はサーバに保持される X のリソースで、描画に関する情報(色、マスク、描画の演算モード、その他いろいろ)が格納されています。 X は通信による描画なので、その通信量を減らすためのテクニックです。 GC の ID のみでパラメータ指定するため、同じような描画を行う場合に有利なわけです。
この描画時に指定されるフォントは、GC に指定されたものが利用されます。この指定は次の方法によって行います。
なお、GC に様々な処理を施す場合、XChangeGC で一括に行ったほうが効率は良いですが、XSetFont や他の GC 操作便利関数を同一 GC に対して連続で使った場合には Xlib によって最適化がおこなわれるため、通信の段階では結局同等の効率になるので、あまり気にすることはないでしょう。
DrawText 系の関数では、XTextItem 構造体に対して 文字列/フォント/文字間の距離の組みになったものの配列をわたすことで、フォントを切り替えながらの一括描画が可能になっています。
さて、X11R5 からは Xlib に対して「国際化拡張」が施され「FontSet」の概念が導入されています。これは、現在の locale で用いる character set (複数)別に個別にフォントを指定することが可能になっており、文字セットが混在したマルチバイトエンコーディングな文字列の描画を一回の関数呼び出しで行うことが可能というものです。
次の関数があります
マルチバイト用の mb 系列の関数と、ワイドキャラクター用の wc 系列の関数が存在します。これらの関数は、特に X protocol を拡張することなく、低レベルでは DrawString などを利用して実装されています。これらは、引数に FontSet が必要になります。(DrawText は items の引数内部に指定) GC に設定された フォントの指定は無視されます。
FontSet の生成は XCreateFontSet によって行います。 XCreateFontSet に渡された、フォント名のリスト(カンマで区切る)一式と、 X が保有する locale 別データベースから、現在の locale で使用する文字セット、およびそれぞれの使用するフォントが選択され、FontSet に設定されます。
なお locale データベースは X11R5 では通常 /usr/X11R5/lib/X11/nls/ に、X11R6 では /usr/X11R6/lib/X11/locale/ に存在します。
この FontSet を XmbDrawString に指定し、locale に合致したマルチバイトの文字列を渡すとそれが表示されます。
wc 系列の関数は、内部で一度 wc → mb に変換をおこない、それからマルチバイト系の描画エンジンで描画を行います。このとき用いる wc → mb の変換関数と、OS における wc → mb 変換関数が一致しているなら、次のようなソースコードが正常に動作することになりますが、通常 X は独自の wc <-> mb 変換コードを利用するため、たいていの場合正しく動作しません(T_T)。
wchar_t wctest[] = L"てすと"; XWcDrawString(dpy, win, fs, gc, 0, 0, test, sizeof wctest/ sizeof wctest[0]);
なお、OS のものを利用するように作成する方法を私は実はいまだ把握してません。だれか知ってたら教えて下さい(^^; (ソースをよめという話もある(^^;)
なお、原理的には、-DX_LOCALE をつけた状態の Xlib がある状態で、 locale.h の代りに X11/Xlocale.h を include して、かつ libX11 をリンクして C コンパイラを作成すると(当然 Cコンパイラは wchar_t のための処理(L prefix)をサポートしてないとだめ)、これは正常に動作するはずです。
XToolKit における表示に関連した「国際化」は Xt からの呼び出す locale 関数の指定が可能になった(XtSertLanguageProc)、ことと、リソース XtFontSet が加わった程度です。
Athene Widget は FontSet を利用して大幅に変更が加わっており、リソース international によって従来 Font を使用していた部分が FontSet を用いるように切り替わります。また、TextWidget においては、データのマルチバイト対応のための専用の処理が各種おこなわれるようになっています。XCalender I18N や XFusen などの、X の国際化アプリはこれをうまく利用しています。(でもバグがある... → Xaw の TextWidget) Motif も同様に FontSet で国際化を行っている実装が多いことでしょう。
Gtk における国際化もこれと同様で、内部的に Font と FontSet の両方の操作機構を並列でかかえており、gtk_set_locale を読んだ上で、リソースとして font でなく fontset を用いるとこちらの機構で動作するようです。(これもまだバグがあるようです...)
Arene I18N や XMulti 、Netscape の本文/ソース表示部においては、この FontSet に相当する機構を自前で持っています。これは、現在のサンプル実装にふくまれているものでは、特定 locale での特定文字セットしかあつかえないためで、独自のワイドキャラクターと、mb-wc 変換ルーチンを持ち、低レベル関数を利用した独自の表示機構をくみあげています。
X11R6 から国際化関連はさらに拡張され、出力については Output method と呼ばれる新機構が準備されています。XOpenOM で現在の locale に応じた Output Method を生成したのち、それに対してさまざまな描画の条件を付加した Output Context を XCreateOC を用いて生成可能になっています。
OC (output context) には、描画の際に用いるフォント一式、描画の方向などを指定できます
XOC oc;
oc = XCreateOC(om, XNBaseFontName, "-*-*-*-R-Normal--*-180-100-100-*-*"
, XNOrientation, XOMOrientation_TTB_RTL, NULL);
などとすると、縦書きで、かつ 右から左に描画するための Output Context が生成されるはずです。 (はずです...なのは、私も試したことがないから(^^;;) なお、縦書きの実装は X11R6.3 から入った模様です。
The Xlib output method implementation has been enhanced to support the XOM value drawing direction XOMOrientation_TTB_RTL. Vertical writing information and other locale specific information is read from the file
/%L/XLC_LOCALE where the XLocaleDir configuration option defaults to /usr/X11R6.3/lib/X11/locale. The X[mb|wc]TextEscapement functions now return the text escapement in pixels for the vertical or horizontal direction depending on the XNOrientation XOCValue.
The X[mb|wc]DrawString functions will now render a character string in the vertical or horizontal direction depending on the XNOrientation XOCValue.
Output Context を用いた描画関数はさがしてもみつかりません。が、実は X11R6 の FontSet は OutputContext そのものであり、描画に際しては X[mb|wc]Drae(Image)String の FontSet の部分にこの OC を渡して描画することになります。 FonteSet は Output Context の特殊な形とみなされているわけです。
既存のアプリの表示まわりを「国際化」する時のおさだまりの手順は、まあ、FontSet を利用するのが近道でしょう。とりあえず EUC は普通につかえるようになるはずです。
以上の作業でだいたいいけます。けっこうおおがかりな改造ですね(^^; 問題になりやすいのはフォントの名称で、うめこまれているときなどは、可能ならば、リソース化、外部データ化してユーザが変更できるようにしたほうがよいでしょう。どうしてもできない場合は、適宜 FontSet のロードの部分で日本語のフォント指定をうめこんだりするしかないでしょう。 (そうすると「国際化」にはなってないけど...)
あと、クライアント間通信なども国際化されているので、そのあたりも整合をとったほうが良いでしょう。 (Window Manageer に設定するプロパティの種別など。 XStringStyle(Latin1) -> XTextStyle(CompoundText))
なお、入力を考慮にいれはじめると、 XIM、XIC とのにらめっこになって、作業が一気に面倒になります(^^;;
なお、このあたりの解説については、 Xlib - C Language X Interface X Consortium Standard X Version 11, Release 6.3 の Chapter 13 Locales and Internationalized Text Functions に詳しいです。この章については、太っ腹なことに、 創夢のほうから全訳が公開されてますので、それを読むのが楽かもしれません。 X11R5 時代の FontSet についての解説もちゃんとはいっています。
X11R5 時代の関数の使い方については、書籍「マルチリンガル環境の実現」に実例つきで解説がでています。
入力回りについては、SUN の 公開している 日本語Solaris2.xにおけるXライブラリの国際化機能も非常に参考になります。
少し捕捉しておきますと、「EUC」とかいう時は、それは「エンコーディング方式(encoding method)」です。 ascii とか JISX0208(漢字集合) とかが「文字セット(character set)」になります。ちなみに、ややこしいのですが、HTTP/HTML における "charset" は後者ではなく前者です。
「日本語EUC」は、iso2022 の 8単位符合の拡張表現のひとつで、 JISX0201(jis-roman) または ASCII、JISX0208(漢字)、JISX0201(jis-kana)、 JISX0212(補助漢字)の4つの「文字セット」を固定的にわりあてて用いる「文字エンコーディング方式」なわけです。 jis-roman(or ASCII) を GL (0x21〜0x7E) の領域に、漢字を GR (0xA0〜0xFF) 領域にわりあて、jis-kana と 補助漢字は Single Shift (一文字だけの一時的呼び出し)を用いて GR に呼び出します。ESC シーケンスは使いません。
locale が ja_JP.EUC の時の FontSet には、この4つの(実際はデフォルトでは jisx0212 はコメントアウトされてますが... /usr/X11R6/lib/X11/locale/ja/XLC_LOCALE)の文字集合のためのフォント情報が格納されており、 XmbDrawString に対して日本語EUC のマルチバイトな文字列をあたえてやれば、これらのフォントを適切に切り替えつつ一発で表示してくれるということですね。
Unicode の場合、16bit の文字面をサロゲートや国別コードによる切り替えを行って動作するエンコーディング方式の一つとみなせますので、特にプロトコル拡張は必要ないでしょう。XDraw(Image)String16 で用が足ります。X のサポートするエンコーディング方式が一つふえるだけのことです。 (今 utf が一つはいってます。どの utf かは未調査)
面ごとにフォントをわける必要がでてきますが、あらゆる面のグリフを含むフォントは大きすぎるかと思うので、現実的かと思います。フォント名称としては次のようなかんじになるかと。
-hoge-mincho-medium-r-normal--0-0-0-0-p-iso10646-0 基本面(BMP) -hoge-mincho-medium-r-normal--0-0-0-0-p-iso10646-1 第一面 -hoge-mincho-medium-r-normal--0-0-0-0-p-iso10646-2 第二面 ...
さらに補足〜
そうです。用語の混乱がありますね(^^;; このあたりの混乱をふまえてか、HTML4.0 Specification では わざわざ章を設けて 細かい解説がはいってたりします(^^;一番重要な部分を引用...
The "charset" parameter identifies a character encoding, which is a method of converting a sequence of bytes into a sequence of characters.
Locale 名称 ja_JP.EUC は、言語「ja」、地域「JP」、エンコーディング方式「EUC」ってことです。エンコーディング方式は、まあ「eucJP」のほうが名前としては正確ですね。X ででの正式名称は、ja_JP.eucJP, ja_JP.SJIS, ja_JP.JIS7 だったりします。
だから当然 ja_JP.utf8 ってのもありですし、今後は実装がでてくることでしょう。
そうですねぇ、この本、たしかに Wnn に偏ってるきらいはあります(^^; まあ、この本のメインの内容は、「UNIX 上ででのマルチリンガル環境」がテーマで、2章以降は Wnn, Mule, X Window System の解説がメインになっており、「アプリもふくめた環境」ということでこういう書き方になってるのはちょいしょうがないかもなぁと(^^;
ただまあ、(本当に満足できるものなのか? という点はともかく) OS としての「国際化(I18N)」(not 多言語化(M17N)のサポートについては、 UNIX (X 環境までまあ含まれちゃったりするのですが、X の 国際化モデルは UNIX 由来のシステム = locale がベースですし...) が先進的で、まだ一番進んでいるのは事実だろうと思います。ただし商用 UNIX のみ。
Solaris などに代表される商用 UNIX は、同一のバイナリを、環境変数 LANG 他のみの切り替えのみで、任意の言語で動作させることが可能になっており、メッセージなどは全て切り替わります。
Windows では基本的にWindows そのものの交換が必要であり、 Machintosh でもモジュールの追加およびアプリ側の特別な対応が必要ですね。この点で UNIX は確かに格段に進んでいます。
た・だ・し、この本、その部分の解説がほとんどありません(苦笑)。そのあと「多言語」についての話にさっさとながれてしまってます(^^; ちなみに、多言語の実装については、UNIX の国際化の枠組みに含めて作成することは当然可能ですが、とくに聞いたことがありません (今なら utf のものがはいっているかも)
結局 M17N は UNIX ででもアプリレベルでの実装にとどまっています。こういうアプリは、この本がでた当時ごろまでは、ちゃんとしたものは UNIX 上のものがメインだったというのが背景にあるのでしょう。現在では Mule は Meadow が Win 上ででの多言語環境を実現してますし、 IE や NN は言語切り替え、および utf による多言語環境をまがりなりにもあらゆるプラットフォームで実現しています。
もし、今、あらたにこういう本をつくるのなら、「国際化(I18N)」、「地域化(L10N)」、「多言語化(M17N)」の区別と OS レベル(正確には OS 標準のライブラリレベルかな)でのサポートと、アプリケーションレベルでの実装との区別を明確にわけて論じたものである必要があるかと思います。
みゅ。早く眼がさめた。まだ早いけど学校へ。昨日の日記を見て思うこと。長い(^^;。うーみゅ、調子にのってかなり書いたからなぁ。ついでに前半と後半のギャップのはげしさが素敵(ぉぃ。
早めに帰ってなにをしていたかというと.... 「ONE 〜輝く季節へ〜」 (^^;
結論から。みんな買え。おすすめです。うみゅ、FONT を使ってしまった。少なくとも私は WA よりはるかに好きです。はい。 あ、ここでも萌壊(ほう-かい。ゲームや小説上、または実在の人物に萌え萌えになり、生活に支障をきたすほどの状態になること。<萠壊 とも書く。辞書登録には注意しましょう)してるし(笑)
おととい、ちょっと頭の数日だけプレイしたところでは、「けったいな主人公やな。でもおもろいから承認」だったのですが、進めていくうちに、思ったこと、「……この世界はいったいなんなんだろう?」全体に漂う雰囲気が、なんか、こう、違う。あう、うまく表現できない(^^; 主人公のモノローグや、言葉の節々がさらに謎を深めていく。
で、終盤の展開で、違和感の正体とかが判明。納得。やっぱ全体としてのしかけなんだろうなぁ。毎朝毎朝毎朝繰り返されるほとんど同じ朝とかも。 あるるんの言う通り(リンク変だよ→あ)、世界設定卑怯くさい(^^; けど、承認っす。「To Heart 的表現による雫的世界観」といった印象をもちました。あづみんもたぶん気にいると思うよー。
結局、澪ちゃんとの BAD End (しくしく)ののち、直前から続けて無事 Happy End。うむうむ。
瑠璃子さんみさき先輩、良いっす(^^;
ちゃんづけ選択肢ほしかった(ぉ。みさき先輩と澪ちゃんと主人公の会話部分がなんか、好き。
あ、こちらこそよろしくお願いします(^^)。
ふふふ、スパッツのトラップの餌食が一人...。イサミちゃん属性には、ショート属性も含まれますね!!(笑)
お、復活おめでとうございます。
がはぁ、 もじら-はっかぁず-ML が爆発してる。フォルダわけしてて気づいてなかった(大汗)。あとでゆっくり読もう。 Raptor 待ちなのは私も同感です。つーか、XMulti のほうが今の私にはぢゅーよーだったり(^^;
どういたしまして。さらにちょびっと補足ですが、各種文字集合は、それ単体で文字エンコーディング方式でもあります。 ascii とか iso-8859-1 とかは単体でよく用いますね。
書き忘れ〜。ごーしさん、饅頭茶屋 10000 アクセスおめでとー :-)。これからもよろしくおねがいします〜。楓ちゃんSS、楽しかったです。お約束の記念絵は多分来週あたりになる予定(^^;;
うみゅ、浩子さんで試聴をするってのは正義ですね(笑)
おおっ、作業が早いですね〜。とりあえず表示回りだけでも日本語がでるようになったら喜ぶ人は多そうですね。がんばって下さい
P要素の話が各地で盛んみたいですね。 (ほかにもあったような気がする(^^;)
もともとの混乱の原因は、ほんと初期の P が、BRのように単独なもので、「段落の最後」につけるためのものだったからという点にもありそうな気がします。欧文でも、文脈の途中で箇条書きがでてくるというのはやっぱあるような気がします。 P 要素は実は paragraph ではなく、「一連の文書のひとまとまり」って程度にとらえて使うのが一番幸せなのかも。
一応、そういう観点からの使い方については、 私の過去日記(丁度 fj で話題になったころ)にもちょびっと触れてたりします。
IE で見ているかたはよくわかると思いますが、私のこの日記のページは「CSSとの併用によるオレ要素」の典型的な使用例になっています。日記の毎日を示す diaryday クラス、日記の各項目を示す diarysub クラス、ダメ時空発生用の dame クラス、瑠璃子さんのセリフであることをしめす ruri クラス with SPAN 要素...などなど。ご参考までに。こんなのを全部手でいちいち書いてるとめんどくさいので、当然半自動で処理かけてます。
ちなみに、P要素を全く使わないってのは、HTML 文法的にはおかしいです。 BODY 要素には直接本文ははいりませんから。必ず何らかのブロック系の要素がまずくる必要があります。 DIV でくくっておけば OK :-) あ、 table でレイアウトかまして、P要素を使わないっつーのも TH/TD要素が %flow をもてるので、文法的には正しいです。意味的にはアレっすけど(^^;
がはぁ。寝過ごした(汗)。すみません＞宇井君、穂浪君。まあ、遅れるかもって言っておいたし(汗)
過ぎてしまったものはしょうがないので、ゆっくり出かけることにする。あ、FDD 忘れてる。ということで学校にとりにきて、ついでにこれ書いてたり(^^;
4:00 過ぎまで ONE してました(爆)。そのあとTシャツつくってました(謎)。こりゃ寝過ごすからおきておこうとおもって気が付いたら寝過ごしてました(汗)。
ONE ですが、茜ちゃんシナリオで展開......はぅン。うう、やっぱこのゲーム、反則。茜ちゃん、楽しい & けなげ。ライバル多いとみた＞あるるん。ラスト、またちょい泣きました(T_T)。ああ、もう、内容が書きたくて書きたくてたまらないけど、何かいてもかなりネタバレあんど書いてるとかなり時間かかりそうなので書かない。
シナリオが変(唐突感高し)あんど説明不足というのは、私も思いました。そこは中途のモノローグと雰囲気から想像力を駆使して補いました(^^;。このゲームにはそれをさせる力があると感じたのです。あとたぶんヒロインシナリオに鍵があるのかなぁと想像してたりします。無かったりして(^^;;
雫や痕をしてた時に日記を書いてたら 同じことを言ったのではないかと思います(^^;
はう、つっこみたい日記がたくさんあるけど、(いろいろ楽しい話題が展開してるし) きりがなくなってしまうので、中断。東京からの更新があるかどうかは謎っす。ではでは。
自由にアクセスできる端末があったので、会場で日記かいて、そこからあげてみたりするテスト(笑) 環境がいつもの環境でなくてめんどうなので、日が切れてません。
ゆっくりでて新幹線にのって東京方面へ。東京駅から京葉線にのって幕張メッセのほうへ。会場着は 15:30 すぎ。とりあえずひととおりどんなブースがあるのかなーとざっとみて回ったりする。日経BP のブースで、うちのページ(X-TT)の URLがでているという雑誌を確認してみたり。おお、でてるぞ。
ざっとみて、おりかえしてる途中で宇井君およびその知合いの近藤さんに遭遇(^^;うーむ、この人のなかで再開できるとはおもわなかった。やっぱ、こういう場所で待ち合わせとかするときは、携帯があったら便利なんでしょうねぇ。帰ったら購入を検討することにしようとか思ったのでした。
そのあともいくつかうろうろして、時間が来たので FreeBSD の BOF の会場のほうへいってみる。おお、人がたくさん。どっちかというと、会場内は スーツなみなさんがほとんどなのですが、ここに集まってる人たちはラフな格好の人の割合がやっぱ圧倒的多数でした。
BOF の内容は、FreeBSD USER会の活動内容、プロジェクト、今後についてなど。jp-man、QandA、新デバイスへの対応の話、FreeBSD での IPv6 の話、謎のVIdeo CD などなど、いろいろ興味深い話がきけました。おもしろかったです。帰ったら KAME をいれてみよーっと。
基本的に、どのプロジェクトも、「求む、(心が)若い人」で、新人材不足がやはりあるようです。がりがりプログラムする若い人たちってのはやっぱ減ってるんでしょうねぇ。私あたりが 8bit 機をいじってる最後の世代あたりになるのではないかと思います。
結局終ったのは予定を大幅にオーバーして(^^; 21:00 ごろ。最後の抽選会で、宇井君のつれの近藤さんがデーモン君人形あたりました。いいなー。
そのあと会場のそばで3人で食事をとってから解散。私はばるさんちにれっつらごーです。
ということで浮気部部室に着。とりあえず、ちょい休憩して、魔法使いTai! 鑑賞会とか、ONE 時計組み立てとか(^^; ONE の時計、けっこういいかんじですが、作るとあそべないというジレンマが(^^; とりあえず私滞在中は２枚あるのでのーぷろぶれむ。謎の Tシャツをとりだしてみせてたり。うーむ、ダメ天井がグレードアップしてるぞ(^^;
とりあえずまほたい第2話鑑賞。ばるさんはお仕事でちょい早めに出勤。私はまるまる3日も N+I にいくのはしんどいので、今日はゆっくりすごすことにする。午前中はとりあえずまほたいの小説を4冊一挙に通読、で、「ONE」遊んでたり(^^;;;
ばるさんちのぐれぃとな音楽環境でまっぴるまからする ONE というのもおつなもの〜。昼飯タイムをのぞいて夕方までずーーーーっと遊んでたです。昼でてていない間に、どうやらあづみんから電話があったもよう(^^;
「みゅー」(あうう、名前どわすれ)とみさき先輩。あと七瀬の途中まで。あと謎なキャラの登場を確認。うむ、やっぱ良いです。人のへやで涙してる男がここに一人(^^; ONE のシナリオはかなり非現実的な部分も大きい(んなこと授業中にできるかー (^^; とか)なのですが、それも含めて気に入ってます。なんだかとっても「ゲーム」って感じではある。
To Heart の方はマルチとか先輩とかは「非現実的」ではあってもなんとなくそのやりとりとかはほんとありそうな、リアルなかんじがするのとはちょっと対照的かなぁとか思ったり。こっちはこっちでもちろんすごいし好きです。
あるキャラクターのシナリオに他のキャラクターがけっこう関わってきたりするのもナイスです。
ばるさんが帰ってきて、ちょっとしてから食事へ。イタリア料理のお店でワイン飲みながらちょっとリッチなお食事。おいしかったです。途中私瞬断してたりしたけど(^^ ;
帰ってきてからコンビニでかったでざーとを食べつつ、まほたい3,4 とはみばの1 を鑑賞。ふみゅ、これがあるるんが4桁見たというコンサートかぁ。まほたいなかなか面白いですね。 ばるさんは、私のもってきた某ぽてと先生の単行本を読んで、日記理解度を高めてたり。
朝おきて、食事しながらまほたい5を鑑賞。クライマックスですなぁ。シャワーをあびて、私は N+I のほうへ。会場内をぐるぐるまわって商品をながめたり、プレゼンテーションをみてみたり。コンパニオンのねーちゃんいろんな格好してますねぇ。目が点になったのは、「聖アライドテレシス学園」せーらーふくに短いスカートにルーズソックス。あと看護婦と婦警さんもいたなぁ。どこかは失念。謎だ。
そのあともいくつか ブースでのセミナーとかみてから、ばるさんちに帰還。とりあえず疲れたのでごろごろしてるうちにばるさんも帰還。近くの洋食屋で晩飯。そのあとまほたい最終話を鑑賞〜。おもしろかったです。つくりは丁寧だし、女の子可愛いし、制作者のこだわりがかんじられる逸品ですね。
そのあとはお掃除モード。ばるさんちに明日新しいTVがやってくるのでした。その際ラックとかもぜんぶとっかえということで、いまあるラックからものをだして、ラックはさようなら。作業完了してからちょいちゃっとで打ち合わせとかしてからおやすみなさい。
今日はばるさんちで TV の設置のお手伝い。けっこう早起きするも、なかなか運送屋さんがこない。ねころがってうつらうつらしてると、昼前ごろにとりあえず TV のほうが到着その直後にラックその一が到着。二人でくみあげ作業。
作業完了後めしをくって、しばらくすると ラックその2到着。で、その直後に Hos さん到着。3人で設置作業とか。
いろいろと Hi-vision TV で再生開始。まほたいとか各種ゲームのオープニングとか、ハミバとか(^^;; 綺麗ですねぇ。でもあるるんちはもっと綺麗らしいです。右2で色合い調整とか(笑)
買いものにいっててきとーに晩飯を調達。
深夜あづみん到着。まほたい最終巻を再度鑑賞。そのあと私がシャワーを借りてあびている間にみなさん撃沈。
私は一人で ONE してたり(^^; 全員一応完了しました。ただしまだみてない部分はある模様。七瀬のみまだ絵が未補完。謎シナリオの最後の邂逅はいまだはたせず。どう展開させれば良いのだろう? とりあえず予想はたっているので、あとでためしてみることにするです。
長森シナリオでも結局謎は完全には説明されませんでした。謎シナリオでの解明はどの程度あるのかはまだ不明。ただし、先輩エンドまたは七瀬エンドの終盤での瑞佳との会話、および、長森シナリオのみでのターニングポイントでの転換部での会話にみられる変化などに謎の背後関係は少し示されているので、やっぱこれは、「自分で考えろ」ということなのかしらんと思ったり。
そのあたりを踏まえつつもう一度じっくりあそんでみようと思います。それだけの価値があると私は思うのでした。
ハッピーエンドにいたる分岐がかなりシビアといえばシビアですが、セーブポイントが大量(30個所)にあるのと、各キャラクターのシナリオに分岐してから以降の重要な選択肢をまちがった選択で進むとすぐバッドエンドに突入するので、セーブとロードを数回繰り返して組み合わせをちょっとどちらのが良いか考えればまあ、問題なくハッピーにもっていけるかと思います。ちょっと「攻略」になっちゃうのがなんだかなという感はありますが。
ところで、プレイしてて、ONE の文書ですごく気になったこと。「話し」はやめようよー(T_T)。すごく違和感があります。おくりがなの本則を適応すると「話し」になるかもしれませんが、「はなし」には単独で漢字「話」をあてるのがやっぱ正しい日本語でしょう。「萌え」なんて言葉をつかってる私がいっても説得力がないかも(^^;
まあ私は「萌え」は新語だと思ってますが、「話し」は明らかにサ行五段動詞「話す」の連用形「話し」の誤入力です。「話し」が名詞として登録されてるような変換システムはないと思います。この現象が頻発するものとして、こまぎれで変換かけたときの Wnn と MS-IME が有名ですが、やっぱ後者によるものでしょうね。
そのあといいかげんにねむいのでちょっと睡眠もーど。おやすみなさい。
今日はBNL３の日ということで早起きしてあづみんと会場のほうへ移動。あづみんが知合いのみなさまがたと9時に待ち合わせというとなのでそれにあわせて行動する。とりあえず東京駅で朝飯くって、新幹線の最終の時刻を確認してから浜松駅のほうに移動。
会場に到着。すでに多数の人が歩道をうめそう(jpeg:64K)な状態(^^; ここでかわぴーと sugich さんと BLACK さん他(すみません他のお方のお名前わかりません)に遭遇。サークル入場待ちだとか。ここで Palm Hearts の動作をみせていただく。おおーすごいぞー。
そのあとちょい周囲をうろうろしているうちに、どうやら一般の行列の形成がはじまったもようなので、とりあえずならびませうということで移動。おーはしってるはしってる。かなりひときてますねぇ。同日でもうひとつイベントがあるようで、そちらの行列との差がかなりはげしかったです。
とりあえず、並んだのですが、まだまだ時間がありそうなので、たったままこの日記かいてたりしますまちくたびれたあづみんが馬トレカのソートをはじめたもよう。列が動くのはまださきになりそうです。
時間がきて列が動き始めました。当初列を2列単位でわけて、くじ引きで順に入る列をきめる、みたいなことをしてたのですが、なんか結局途中から前のほうの列から順番にはいるようになった模様。なんだかなぁ。会場に入ったころにはすでに人々ひと(jpeg:64K)。
敗北^H^H無事取得したものたちの一覧。
などなど(^^; 目標物品(Palm Heart, じゃらやの新刊, こまど青、瑞穂のオルゴール)はすべて果たしたのでよしとしませう。とりあえず内容の細かいチェックとかはまた明日〜。
TO HEART のトレカをだしている(株)Tiが次期製品の展示とアンケートとかをしてた。アンケートにこたえたひとにはもれなく非売品の Thanks トレカとやらをプレゼントということでもらったり。
ポスターとビッグサイズタオル(jpeg:64K)とメタルトレカと トレーディングマスコット(jpeg:64K)にピンズ、さらにトレカのレギュラーバージョンだそうな。ポスターとかタオルとかは新規水無月さんの新規書きおろしだそうです。がんばってくださいね〜＞トレカ部のみなさまがた。
いろいろぐるぐるしてさすがに歩きつかれたのでしたのロビーで休憩しつつ日記かいてたり。
そのあと Leaf IRC のめんめんとのオフミに出撃。グループらしきものが会場前にいくつかできてて、どれがどれだかわからない。なんせ直接会ったことがないですからね。で、とりあえずこちらは何の集まりなのでせうと尋ねてみると一発目でどんぴしゃりでした:-)
参加の皆さんは....たくさんいて忘れたので略(^^;
中野町の店に移動して、そちらで宴会モード。とりあえず乾杯して談話しながら食事。なぜか現場にいないエクレアさんの話題でもりあがったり。
そのあとビンゴ大会。賞品の目玉は「ONE」。ほかみなさんからいろいろもちよって賞品がけっこうでてくる。私からは、お手製の「はつねこちゃん」と「すぱっつるりるり」の Tシャツを寄贈(^^;
そのあともいろいろ話題がもりあがりつつ、会はおひらき。ちゃっとで毎晩のようにあってたりするみなさんですが、やっぱ直接会って話すってのは良いですね。そのあとみなさんはカラオケ二次会にれっつらごーとのことで、私はおいとまして帰宅の途へ。と、ここで 真潮さが合流。お世話になってますと挨拶だけしてさようなら。
最後に残念ながら今回は参加できなかった 萩谷さんからのみんなへの可愛いペーパー(初音ちゃん)をもらって幸せにひたりつつ帰る。
ちょうど豊橋にもとまる「ひかり」がきてたのでそれで帰りながら日記作成〜
で、無事豊橋到着して、帰宅して、シャワー浴びて、しばらくごろっとして、学校きて、ニュースとメールがかなりたまってるのにがびーんとなりつつぐるぐるして、日記書いて、あげたとこです。
日記を書いてたら日がかわってしまいました。 6日と7日のぶんがまとまってあがってます。
昨日の日記にいくつか写真を追加。全部でかいまま & 色補正とか特にはしてません。会場の雰囲気はわかるかも。
あ、BNL3 に来られてたのですね。なんだか私と同じもの買ってますね〜。あ、真潮さんも同じものを(^^;。またこんどゆっくりお会いしましょうね＞真潮さ
WWW ででの図形描画の言語は XMLベースのほうで制定がすすんでいるのではないかと思います。とかかいておくと、詳しい方からの日記にポインタがあがるかも(^^; このあたりからいろいろたぐれそうです。
むむむ、XMulti がコンパイルできないですか(汗)。 XMulti はふつーの X アプリとしてくんでますので、 FreeBSD でコンパイルできないってことはないつもりなのですが.... ひょっとして X のプログラミング環境(X322prog.tgz かな)がはいってないとか...ではないですよね。どういうエラーメッセージがでるか示していただけるとさくっと対処可能かと思います。
お、GIMP Ver 1.0 ついにでましたか。あとで私もコンパイルしなおさなくては。 いいんちょのファンクラブですか。いいんちょといえば、 BNL3 でかなり可愛いいいんちょのコスプレの子がいました。どのくらい可愛いかというと、あずみんがこうなるくらい(笑)。肖像権の問題などもあるでしょうから、どうしてもオレも見たいぜぃ!!!という方は以下略。
えっと、私自身の日本語も怪しいので、言いきれなかったりするのですが、「話し」については一応考えがあります。
小学校で「はなし」は「話し」とはおくらず、「話」と書くというように習いました。これについてはおくりがなに関する内閣告示があると記憶してます。 (WWW上に無いかなと思って探したけれど発見できず。こういうのこそおいて欲しい...) 「例外」というやつですね。例外は全部おぼえないといけないので、面倒(^^; まあ、本則だと「話し」で良いということになるとは思います。実際こう主張して「話し」と書いている人がいるという話を聞いたことは私もあります。あ、その旨でてる辞典もあるんですね。
続けて書くというのが「話し言葉」とか「話し方」とか「話しましょう」とかのことをさすのでしたら、それは「話す」の連用形ですね。「し」がぬけると間違いです。
でまあ、とりあえず「話」と習ってますから、自分で手書きで文を書くときは、「話」と書くのがやはり普通でしょう。ところが、コンピュータ上で文書を入力中に、「はなし」を単独で変換すると、一部の変換エンジンでは「話し」が先に候補としてあがってきて、これをなにも考えずに そのままつかっているというのが現状でしょう。これはやはり間違えていると思うのです。
あ、沖さんも私と同じような意見ですね。
「お話しする」ですが、「おはなし(名詞、丁寧語)」は「お話」ですが、後ろに「する」をつけて動詞化するときは、「お話しする」とおくるという、さらに特殊な用法のようです(^^; ちなみに Wnn6 では次のように登録されていました。
「はな」 *話 サ行五段 辞書：基本辞書(R2.06)/120675 「はなし」 *話 サ行(する)&名詞 辞書：基本辞書(R2.06)/85646 「おはなし」 *\tお話\御話 名詞 辞書：基本辞書(R2.06)/85647 *\tお話し\御話し サ行(する) 辞書：基本辞書(R2.06)/85649
「はなしする」だと「話する」、「おはなしする」だと「お話しする」になりますね。うむぅ。
ちょい気づいたこと。Wnn の場合、「はなしする→話しする」とか「はなしがあります→話しがあります」という変換は絶対に無い( 前者は「する」から、後者は「が」から品詞が確実にわかるため) のですが、MS-IME97 の場合「話しする」「話しがあります」が候補としてでてきます(大汗)。もしかして名詞で登録されてるのか?「話し」。しかもデフォルト状態で優先順高そうだし。
「ONE」は文書を読ませるってのがやはり主体だと思いますので、そのあたり気をつかって入力してほしいよなぁとか思ったのでした。
ほかにも、「漢字変換」のせいで、妙に難しい漢字が使われる、また ひらがなでもよさそうなところも漢字になってしまう(「出来る」とか「早速」とか「途端に」とか)ような傾向があるようにおもいます。感覚のバランスの問題なのだとは思いますが、漢字だらけになっていると読みにくいと思います。逆に、熟語の一部が常用漢字でないという理由でもってひらがなになってたりするのは気持わるいですね(^^;
しかし、これほど話題が各地に広がるとは思わなかった....。
んー、 動詞「話す」の活用「話し」は連用形ですよ〜。
未然: 話さ-ない/話そ-う 連用:話し-ます 終止: 話す 連体(終止と同形): 話す-こと 仮定: 話せ-ば 命令: 話せ
名詞化するときにおくりがなの本則を適応するなら「話し」になりますね。「話」は例外であり、慣用的にそう書くことになっているのです。ちなみに「写(し)」や「渡(し)」などは、「し」をつけてもつけなくても良いものに分類されているはずです。「本則ですべておくる」は確かに合理的なのです←あんたどっちの味方やねん(^^;
やはり「間違い」という言葉の重さに差があるみたいですね。
「話」と書くのが、現在広くみとめられた用法であり、手書きではそう書く人のほうが圧倒的に多いと思います。 (本当に統計的に確認をとったわけではありませんが。) それにもかかわらず、かな漢字変換において「話し」とでてきた場合、それを確認もしないでそのまま書いてしまうのは、 私の基準では「間違い」...なのです。私がそう表明することは問題ないと思うのですがいかがでしょうか。一連の議論の途中とかだと、話の腰をおるだけだとは思いますが、私の日記という一歩引いた場所でもありますし。
....ということを昨夜(すでに今朝か)書いて、あげずに帰ってねてきたのですが... ああ、やはりそういうことなのですね。うむむむむ、「(私には)間違っていると思う」「変だと思う」あたりの表現が結局の所無難なのかしらん(よわよわ)。あ、「現在の『国語』では間違いですね」というように基準を明示してもよいのか。「それは間違いでしょう」という言葉に、「私の基準では」が自動的に追加されてうけとられるとは限らないということなんですねぇ。
「『ONE』の 『話し』 は誤変換である」ときめつけてるのはそうですね。本当のところは書いた人に確認をとらないとわからないんですけどね。でも、やっぱ、そうだと思いますよ〜(^^; 一応、この件については、アンケート葉書のすみっこにでも書いてだすことに致します。
ちなみに以前、私、「それは『嘘』です」というのを良く使ってました。「そのページに書いてあることは嘘です」といった使い方ですね。本来「嘘」はたんに事実ではないというだけのことで (「嘘をつく」なら故意のニュアンスがある)、私の感覚でもそうなのですが、ちゃっと上にて「『嘘』っていう言葉はやめてもらえませんか」という申し出があり (一連の話題が終った時点で)、譲れないラインでもないし、無理にトラブルを増やすこともないだろうと思ってそれ以降「嘘」はあまりつかわないようになったのでした。その人の中では、「嘘」という言葉に「故意に」が常にくっついていて、私の語り口に良いイメージをもたなかったようです。みなさまはどう思われますか?(とか書いてみる)
いまさらながら、言葉のつかいかたって難しいですね。
OpenBSDをひさしぶりに current に追従させてる途中〜。んー、最近の大きい目玉は、OSS互換のサウンドインターフェースの追加、システム全体のコンパイルオプションのデフォルトが -O から -O2 になった、IPsec 関連が改良されて、容易に Virtual Private Network できるようになったといったところでしょうか。vpn(8) が追加。 VPN は最近ちょいはやりの、インターネット経由でイントラネットをつなぎませうというやつですな。どこかと実験してみてもおもしろいかも。
あ、それは間違いなく X のプログラム環境がはいってませんね。 FreeBSD なら、/stand/sysinstall を実行して、Configure/Dustribution/Custum/XFree86/Basic/prog をインストールするか、CD の /XF86332/X332prog.tgz あたりを展開すると良いです。tar zxvpf X332prog.tgz -C / といったところでしょうか。
9月に浩子さんのコンサートが例によって渋谷の青山円形劇場であるのですが、そのファンクラブ会員先行チケット予約がとどいてます。うーん、どうしようかなぁ。12月以降にもたぶんコンサートツアーがあるんだよなぁ。お金もかかるしなぁ...
日程は次のとおり。
うーむ、いくのなら、やっぱ Bプログラムの「オールリクエスト」だよなぁ。全部会場からのリクエストで演奏するというすごいやつです。浩子さんの曲、百の単位であるからどれがでるやら。レア物が聞ける可能性も高し。前回にひきつづいてまたあるってことは、どうやら浩子さんも気に入った模様(笑)。
今日はさっさと帰って ONE でもしよう(^^; あと東鳩日記も書くつもり〜。
むぅ、結局昨日は帰ってからぼけーっと鑑定団をみて、ニュースとかみて、そのあと寝てしまったので ONE はせずでした(^^; 書き忘れてたけど 117% には昨日すでになってたりします。
ONE、何を書いてもネタバレになりそうで、なかなかうまい感想がかけないのがもどかしい。 はーすけさんの感想みたいな素敵な感想が書けたらいいなとか思う今日このごろ。 七瀬との会話とか、毎朝のやりとりは私も大好です。朝のパターン、よくぞあれだけたくさんつくったものです(^^)
立ちグラフィックス、てれてれ長森がかなりヒットです。
「雫」や「痕」とかが、プレイするにつれて謎が一つ一つ明かされていき (電波や鬼そのものの謎はあかされませんが、それは「小道具」ってことで) 最後には物語の全容が見えてくるのをみてカタルシスが得られるという作品なのに対し、ONE は謎の輪郭を示すのみで、あとはこちらに深く考えさせるという感じで、両者ともいいよなーと思うのでした。単純に比較はできないですね。
うーむ、やっぱ青山はいったほうが良いですかねぇ(^^; オールリクエスト...いいよなぁ。
MultiByte 文字列での合計横幅の取得ですが XmbTextEscapement が利用できます。これは正確には baseline にそった(縦書きのときは中心軸)、描画原点から次の描画原点までの行(列)送り量(Escapement)を返します。X の Font でいうところの "width" はずばりそれで、XTextWidth の返す値もそうです。追記。なんで XmbTextWidth でないのかというと、Width とはかぎらないからでせう。Xmb/wc 系は実装はともかく、縦書きも可能なものですから。今(X11R6.3)の実装はできるようになってるはず...ためしてみよう。
描画領域(bounding box)そのものの情報が欲しいときは XmbTextExtents を用います。これは XTextExtents に対応します。
ひさびさの更新(^^; あかり萌えに至る日々 -Epilogue-
のこるは 5/12 の最終日。
GPL なソフトを物を利用するには FreeSoft でなければならないということはないでしょう。そういう市販されている Free でないものは実際いろいろありますよ。
私の手許にあるものでは、たとえば PlayStation の開発ツールは binutils, gcc, gdb を流用しており、その部分の Sony での 改変部分も含めたソースコードは GPL のもと公開されていますが、周辺ツールおよびライブラリについては当然ソースは公開されていません。
また、ずばり Palm Pilot 用の J-OS Pro (not Free) は SKK の辞書を利用しており、辞書部分については GPL により改変/再配布可能である旨の記述と SKK のドキュメントおよび GPL がついてます。当然 J-OS 本体のソースは公開されてません。
GPL が適応されるのは、SKK の辞書を改変して新しい辞書をつくる場合とか、SKK の辞書を内蔵したソフトウェアをつくったりする場合のみだと思います。
というわけで、X11R6 から導入された X の新文字描画 API の X11R6.3 における「縦書き拡張」の実験してみたりする。ソースは こちら。コンパイル方法はてきとーにどうぞ。libX11 だけあればいいです。
結論。XmbDrawString は動作。でも XmbTextEscapement と XmbTextExtents が予想したちゃんとした値を返しません。横書きの場合と同じ値が還ってきます。むー。あと英字が一文字ずつ縦になります。これは実装依存ということになるのかな。
というわけで、現状では使い物にならねーということです。はい。早稲田の片岡さんのところのやつ(System I)が、bit の記事で読んだ限りでは X の枠組みのままでつくってあるということだから、この部分の拡張なのかしらんとか思うのですが、公開されてないので予想の域を超えません。うーん、一体いつ公開されるのだろう...
