冬コミ用にまるちのバージョンアップ作業。とりあえず、フォント処理を、旧版の Pixel ベースから Point ベースに変更。これで Netscape と同様の動作になったはず。続いて現在決めうちになっている、フォント名称の設定をリソースでできるようにするための変更開始...う、もとの設計が変だから直しにくい。うーみゅちゃんとくみなおそう....
ほか実装の予定としては、 charset 指定処理を追加 (現在 iso-2022 系のみ。Shift_JIS、UTF、単純な 1byte/2byte 系ぐらいはいれないとね...)して、簡易 HTTP エンジンを搭載(実用性はたぶん皆無...)。
おーい、まるちー。このページ表示してあと、簡易メッセージ機能とか、アラーム機能とか、biff 機能とか
ま:はいっ。これでいいですかー
ま: いぬさん、いぬさん、どうしたですかーこんなところですかね。さて、どこまでできることやら。あ、画像のローダにバグあったんだった。つぶさなきゃ....
BIFF: わんわん!
ま: あ、お手紙ですかー。ありがとうございますー
ふははは。結局帰ってから風呂はいらずにねちまったっすよ＞苺各位。
がおとといと昨日と今日とでびみょーに違うのに気付いた人はいるのだろうか? Radio-Wave -> Electric-Wave -> Radio-Wave と変わったのと、現在形 -> 過去完了形、あと Nowaday's -> Nowadays 。になりました。昨日のチャット中での考察の結果です(^^;。英語にくわしー人いたら、これで良いかどうかおしえてください(汗)
とりあえずね。
ほい、遅々としてるですけどとりあえず進んでます(^^; やっぱこれからは「ヲレぶらうざ」を自前でつくる時代でしょう(ぉ。あ、苺計画は、まだぽしゃってないつもりです(汗 ただしX用ですけど(^^;;; まるちの隠し機能部分(たんに完成してないだけともいう)の仕様書が変更中らしい....
粉砕バットが分かる学生ですか。うむ、これからは貴重になってくるんでしょうねぇ(笑)
うーむ、どうしても BSD は Linux には そういう点 で負けてしまいますよねぇ。
NFS の遅さ..ですか。パラメータの変更で改善されたような気が.... 確か Linux の NFS のデフォルトのread/writeのバッファのサイズが小さいので、他のOSと混在するときはサイズをあわせてやらないといけない ...とかいう話が昔うちの学内ニュースに上がってたような気がする...。あ、あったあった。引用..某真鍋さん曰く...
Linux と BSD で NFS を使うならば、read/write のバッファサイズ をあせて下さい。Liux はデフォルトが 1024 になっていますが、 BSD は 8192 です。 # Linux と BSD の比較でよくやるミス: # # 1) バッファサイズの異なる NFS の性能を比較してしまう # 2) 同期ファイルシステムと非同期ファイルシステムの性能を比較してしまうだそうです。
ちなみに部長、日記の各項目の URL 変です(^^;; 9712U じゃなくて 9712M ですよね?
某ニュースグループで弟発見との報告...げ、ほんとだ。とりあえずみょーなことは書いてないようだな。うーむ。
あ、朝気付かなかったや。 なんかクロスケーブルつくったり、空いてるアドレス聞いてきたりしてた のはこのため だったのね(注意:死ぬほど遅いので暇なときにどうぞ)。うむ、たぶん世界で唯一でしょう。X68Kでこんなことしてるのは(笑)
どういたしまして。うーん、NFS の性能比較ですか....どうなんでしょ。 Linux ほとんどつかってないし、性能比較したことないのでわからないです(^^; ちなみに、うちの研究室は NFS 全然使ってないっす。みんな個人マシン運営。別室のほうではつかってますが、サーバ 古い sparc だし。私ほとんどつかってないし
の インストールですか....
現在の disklabel そのままにするんだったら、 OpenBSD/sparc のインストールディスクをつかって、インストールできるような気がするっす(笑) ftp するファイルの指定で NetBSD/sparc のを指定...
OpenBSD/sparc と NetBSD/sparc のディスクラベルの互換性はすでに無いような気が...OpenBSD では、16パーティションに拡張されてます。 NetBSD のほうは使ってないので知りません(汗) ただ、古い SunOS のディスクラベルに対する上位互換性はもってるはずなのでそれでなんとかなるかなーと。
ちなみに、OpenBSD の CD がほしーという話は現在のところゼロ。まあ当たり前か(^^; このページみてる人少ないはずだし。
昨日のみあみぃ君の httpd for X68k をみて あるるん☆が感動してました(^^;;で、話題は Neptune-Xへ。
さすが X68k ですね。既存のNICをベースにカードをつくるとはナイスアイディアですねぇ。大量生産してる人もいるですかー。残念、募集終わってますな(^^;。あるるん☆が聞いてみてあげてもいいよとかいってくれましたが、回路図とかみたところ、私のレベルの電子工作の腕があれば十分作れますね。コミケ以降、製作を考えましょう＞三上君
とりあえずフォント周りの改装は完了。リソース指定できるようにはまだなってないですけど、そのためのデータの外部からの指定の口はつくりました。charset/font名称/ベースpoint サイズによる指定です。 Netscape Navigator と同じですね。
で、とりあえず今日はエンコード処理周りの整理と機能追加。代表的な ISO-2022 系(含む EUC)と、Shift_JIS に対応。次は UTF と各 ISO 1bute/2byte 系の処理の追加ですね。今は無視してる META タグの charset 指定のパースも追加しないと.... あああ、やること多し(^^;; もうすぐ日がかわるな....
UTF-8 実装完了。さて次は UTF-7 だねぇとか思って、仕様(RFC1642)をちゃんとみる....。げ、Base64 いるの? うーむ、めんどいなぁ。気力がとぎれたので、後回し決定(^^;;
とりあえず今晩はプログラムはここまで。続きはお昼からっすな。次は通信部分つくりましょう。あと、既にパーサの中身けっこう忘れてるからソース読み直さないと(汗
の続き〜
タイムリーにも fj.net.infosystems.www.authoring で話題がでてまして、けんとさん がフォローされてる & 週明けにさらにふぉろーされるそうなので、それを見れば良いという話もありますが、とりあえず(^^;
なお、かなり長くなりました。これは実は私自身の覚え書きなのですが、 cclub メンバーにはこのくらい知っていてほしいです。はい。
さて、WWW における文字コードということですが、ここでは HTML 文書 (Content-type: text/html)に関しての話ということになりますね。
HTML は、SGML のサブセットです。SGML では汎用的な処理を行うために、SGMLインスタンス中 において使用する文字とその種別を SGML宣言中で定義しておくことが必要です。パーサはこれをもとに DTD を解釈して実際の処理を行うことになります。
SGML は 固定長の文字コードが前提です。複数の文字セットを利用する場合は、それぞれを BASESET として指定し、DESCSET (SGML が実際に利用する文字セット)からそれらにマッピングすることになります。
というわけで、実は、ISO-2022、EUC、Shift_JIS などの多バイトのコード系にはそのままでは SGML ではあつかうことができません。 1byte(8bit)のパーサの場合は、なんらかの細工をして無理やり通すことになりますし、 (Linuxdoc-SGMLで採用してる sgmls-j はこれ。EUC が ascii と 重ならないことを利用)、 2byte(16bit)以上のパーサなら、入出力時にマッピングを行うということになるでしょう (SP(16bit)は、これにより UCS-2 や Shift-JIS, EUC をちゃんとサポートしている)
HTML においては使用する文字セットは、ISO-10646 すなわち、 UCS ということになっています。
RFC1866 HTML 2.0 よりHTML2.0では、iso-8859-1を含み、ISO-10646と一致する適合するというよくわからん表現です。 HTML 4.0 では、明快です。
* Its document character set includes [ISO-8859-1] and agrees with [ISO-10646]; that is, each code position listed in 13, "The HTML Coded Character Set" is included, and each code position in the document character set is mapped to the same character as [ISO-10646] designates for that code position.
HTML4.0 W3C reccomendedHTML2.0 の SGML宣言では ISO 646:1983 IRV (まあASCIIですね)と iso-8859-1 しか宣言されていませんでした(^^;;;
5.1 The Document Character Set より
The ASCII character set is not sufficient for a global information system such as the Web, so HTML uses the much more complete character set called the Universal Character Set (UCS), defined in [ISO10646]. This standard defines a repertoire of thousands of characters used by communities all over the world.
CHARSET
BASESET "ISO 646:1983//CHARSET
International Reference Version
(IRV)//ESC 2/5 4/0"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
BASESET "ISO Registration Number 100//CHARSET
ECMA-94 Right Part of
Latin Alphabet Nr. 1//ESC 2/13 4/1"
DESCSET 128 32 UNUSED
160 96 32
HTML 4.0 では、明確に UCS4 が指定されています。
CHARSET
BASESET "ISO Registration Number 177//CHARSET
ISO/IEC 10646-1:1993 UCS-4 with
implementation level 3//ESC 2/5 2/15 4/6"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 55136 160
55296 2048 UNUSED -- SURROGATES --
57344 1056768 57344
Unicode-2.0 のサロゲートの部分(言語切り替えとか)は無視してます。まあ当然ですね。これでは、0x00000000 - 0x0010ffff までマッピングしてるようですね
さてさて、では EUC や Shift_JIS や、はたまた iso-2022 などは使えないのか? というと、そういうことはありません。これらは単なる「文字セット」ではありません。通信のための、「文字コードのエンコーディング方式」なのです。
HTML では、この通信でのエンコーディングは IANA に登録されているようなものを任意に使用できるということになっています。つまり、文書自体は、EUC や Shitf_JIS や、はたまた JISX0201 や JIS X0208 だけなどで書いてもいっこうにかまわないということになります。 (実際 UCS4 そのもので記述することはないでしょう。UTF-8 などを使います。)
HTML2.0 の RFC では、これについては "NOTE:" として簡単にふれるだけであり、また内容も結構意味不明なのですが、HTML4.0 の規格書では、 これに関してまるまる節をとり(5.2)、その原理や、指定の方法などにいたるまで、詳しく解説してあります。
さて、いったんまとめてみましょう。
これから、「WWW ページで、いわゆる「半角カナ」を用いる」といったようなことは、規格上は、全く問題ないことがわかるでしょう。いわゆる「半角カナ」に相当するコードは UCS-4 に含まれています。通信の際には、 Shift_JIS、EUC-JP、JIS_X0212 などのいわゆる「半角カナ」(jisx0212の右半分) を含むエンコード方式を利用することになります。
note: これは、「半角カナ」は将来的に(Shift_JISから)削除される予定だし、コードの重複であって好ましくないから使うべきでない、という話とは完全に別問題です。ご注意を。(ちなみに、私自身は、「半角カナ」の使用は勧めません。むしろつかわなくするほうが良いと思います)
ブラウザの実装に関して、次の点をみたす必要があることになるでしょう
ちなみに、IE は、エンコードの指定を無視かましてくれます。もじらは、エンコードによって表示できる文字が限定されてしまってます。なおこのあたりについては、 ちょっと前 に考察してます。
さて、これで HTML の文字コード関連は、全部問題解決かというと、そういうわけにはいきません。仕組みとしては、すっきりしており、これで良いのですが、最大の問題点、特にわれわれ東アジア圏の人間にとっての最大の問題は、「UCS-4を文字セットとする」という点にあります。
UCS-4 は 4byte の非常に巨大な文字セットで、これだけあればあらゆる文字をあつかえそうな気がしますが、その実体は、かの悪名高き「Unicode」です。ぶっちゃけた話、文字がたりません。なお、Unicode の問題点については、 太田昌孝せんせの著書が簡潔かつ、的確にまとまっていて良いです。
実は、HTML4.0 はこの Unicode の問題のしりぬぐいをした形になってたりします。 LANG 属性です。中国漢字、日本漢字、台湾漢字を混在するにはこれを使えということのようです。 (SGML宣言では、Unicode の「surrogates」は使わないようになってます。というか、SGMLではあつかえないですな) テキスト文中に明示的に言語を指定させて、パーサに言語の状態をもたせるというのは、はっきりいって本末転倒でしょう。
追記:ついでに、この言語切り替えをおこなったとしても、Unicode では将来 JIS に追加される予定の漢字も含めて、使用される可能性のある漢字全てを表現することは結局不可能です。
結局のところ、これが完全にすっきり解決するためには、「UCS-4」をもっとまともに設計しなおすということしかないでしょう。UCS-4 はそのほとんどの領域が「未定義」のままのこっています。この部分が当初の UCS-4 の計画通り、ちゃんと(真にあらゆる文字セットを含む形で) 決まればOKですな。 (このような不自然な文字セットのうまれた背景は、加藤さんのページ、 「ほら貝」 の 文字コード問題早わかり ４ ユニコード篇に詳しいです)
というわけで、XMulti の実装においては、内部コードにあえて UCS-4 そのものは用いず、独自の 32bit コードを利用しています。ただし、UCS-4 を完全に含むようにしてあるので、実用上問題が生じることはありません。 UCS-4 は、4byte ですが、実際には、31bit しか用いないので、その「裏」をiso-2022系用のマッピング用に用いています。これにより、「同じ文字」の重複コード化が大量に発生します。現在のところ、表示上は問題がないため、ほかってます(^^;; まじめに対策するには、「文字コードのデータベース化」をして、どの文字とどの文字が、実は同じ文字であるとか、異体字であるとか、形が近いから検索上同じとみなす、とかの処理が必須になってくることでしょう。
これにより、HTML のパースは、完全固定長な文字コードで行うことができ、非常に単純に処理できています。これが本来の SGML の目指しているところだと思います。
なお、今後も通信、およびファイルとしては、既存のエンコーディングが「外部コード」として用いられていくことでしょう。アプリケーションの「内部コード」は、ぶっちゃけた話、各アプリで違ってもさほど問題にはならないことと思います。
とはいえ、なんらかの「内部コード」の統一規格があると、便利なことにかわりはありません。ファイルの入出力とか、画面への描画などですべてのアプリで同じライブラリがつかるということになりますからね。
理想的状況は、UCS4 と、ISO-C の wchar_t と X Window System の内部 wchar が、全て同じコードで、かつ、あらゆる文字を含んだ状態ってことになりますかね。これが実現していたら、XMulti の表示エンジンや、入出力周りをわざわざ全部組む必要がないのに(^^;;;;; (あ、もちろん究極の理想は、wchar_t でなく、char がこれになることですが、そこまでは求めません(^^;;;)
準理想状況は、これをうまくあつかう、よくできた API などが一式提供されるといったところでしょうか。
とどこおってます(^^;;
を昼からちょいみてました。うーむ。とりあえずがんばれ(^^;;
にひさびさにいってきます。何をみるかはまだ未定そろそろ内線がかかってくるはず.....
研究室の B4 のめんめんの卒論の発表練習につきあう。うーむ、これが最終(いや、ほんとはも一つ前が最終のはずだった)のだが、まだあと何回かはしないといけないですなぁ。あと3日か。がんばれー
現在進行中.... 通信部分をつくるはずだったのですが、html パーサを読み返してるとどうも気に入らないので、作りなおしはじめてしまう(汗タグの親子関係の判定が適当なのをなおして、もっとまともなパーサになる予定。ブロックなタグと、ラインなタグを明確に分離。スタイルシートへの布石もくみこみ中....
今日の夕方、ポケモンをみてたおこさまたちが、あいついでけいれんを起こして病院にかつぎこまれたというニュース。光過敏によるてんかん症状ってことになるのかな? うーむ、このあといったいどうなるのだろう...。子供むけの人気番組、しかもいま一番の稼ぎネタでこういう事件がおこるとは世の中なにがおこるかわからないものですねぇ。
マルチとたわむれる。 19:40 分現在、HTML パーサ部がばらばらになって散らばってます(汗
ま: カラダが動かないですー。ううっ。本当になおるんですかー(;_;) ご: 大丈夫だって。ちゃんとなおしてやるから、泣くなって(^^;;; なでなでなで ま: あっ.... (ぽー)
ぐるぐるリストをちょと修正。ついにあのページにつないでしまった(笑)
みあみぃ君、今日はみかけてないけど、もしかして 昨日かえったっきり 家でたおれてるのかしら(汗)。
うーむ、 あるるんの日記がみえない。最近どうしたんだろう? > kurusugawa.org 重い。 部長も今日は書いてないみたいだし。
ま〜れぃちゃん、やっぱ 浮気の才能あるよ。くすくす。
なんかいろんな日記でぴかちゅう話題になってますな。
日記者の流行語。うみゅ。「ガビーン」がトップをつっぱしってますなぁ。とりあえず、「〜部」と「電波」に投票。
<p>タグの話。(もとの話はこちら) p タグは、自分が入れ子になることが無く、閉じタグが無くても処理できる (内部に含まれることのないタグがでてきた時点でタグ閉じとみなせる)ので、 DTD 中で 閉じタグが省略可能と明記されてます。
<!ELEMENT P - O (%inline;)* -- paragraph -->
^ これ
SGML の OMITTAG の機能です。同種のものとしては、DT, DD, LI, TR, TH, TD,
OPTION などがあります。(あと HTML4.0(draft)では THEAD, TFOOT, COLGROUP ってのも新設されてるですな)
スタイルシートが普及すれば、<p> の正しい使い方が普及するかしら? 正しくつかわないと。ちゃんとでないですからねー。基本は、段落の前に <p> あとに </p> ただし、閉じタグ </p> は省略可能。私はたいてい閉じタグを書いてません。
ただ、閉じタグあるなしで場合によってはレイアウトかわるのよね＞もじらくん(汗) ちゃんとつくれー。IE はどうなるか知りません(^^;
あ、あるるんの日記見えた......ご愁傷さまです..
ひさしぶりにプレイ。ようやくエンディング〜ちなみに、最強は耕一とマルチ(笑)。最後、実質この二人でボス倒しました(^^;; 今度は瑠璃子さんのレベルをあげよう....
うまってなかった CG も、To Heart のメンバーのものであろうと想像がついてたので、組み合わせを何回か変えてみて無事全部捕獲完了。そうか、基本コンセプトは、「ハイスペック・ハイコンパクト・ローコスト」か。開発テーマは「お手伝いする娘」うみゅ、よきかな、よきかな。
しかし、マルチ、あの技は....(汗)
Heart By Heart 難いっす(涙)
今日も開発はつづく...
ご: よし、まるち、改装がおわったぞ!
ま: よかったですー(^^)
ご: 組み上げ完了。起動してみよう... 全接続 ON...
ま: ぴー Segmentation Fault ですー(;_;)
ご: がはぁ。... gdb 起動だぁ
.......
ご: よし、なんとか表示できるようになったぞ。あとは各タグのパラメータを
調整すればOKだな。さ、メニューを閉じて..
ま: ぴー また Segmentation Fault ですー(T_T)
ご: ガビーン。えいい、とりあえず昼飯だー昼飯ぃ。
ま: うううっ
が近いっすな。後ろのほうで「野郎共のくりすますぱーちー」の計画がしめやかに行われてるです。はい。
もう夜ですなぁ。
ご: さ、まるち、今度こそできたぞ。 ま: は、はいっ。今度こそだいじょうぶですよね? ご: さあ、起動だぁ。 ま: .....ちゃんと表示できますー。うれしいですー(^^) ご: ふう。長かったなぁ。あ、まだ服きちゃだめだよ ま: え、どうしてですか? ご: 今度は通信機能つけるから。 ま: 私、セリオさんみたいになれるんですか? すごいですー。衛星ですかー。どきどき ご: いや、そこまではさすがに(^^;;;
タグの親子関係をちゃんとチェックするようにしました。 (つーことはいままでしてなかったってことっすね(汗)) タグの論理構造分離を明確にしたので、タグ単位のスタイル指定への布石にとなってます。ちなみに、文法の完全なチェック (タグの順序、個数などのチェック)はしてません(汗)。BODY のあとに HEAD が登場できます(^^;;;
table はパースするけど処理はなし(^^;; ブロック構造としててきとーに並ぶです。これだけは、配置の計算に専用の処理がいるんだよなー.... たぶん実装としては、フラグたてておいて、閉じタグまでパース結果をためて、それから、一気に処理することになる予感。
研究室に物をとりにいったら、みんなでビデオ観賞会なんかしてる〜。おもわず見てしまったっすよ(^^;; うーむ。やっぱ古いアニメですね。つっこみいれながら見るのがまたたのし。おもしろかったです。はい
HTML 4.0 が W3C Recommendation になりました。
Appendix A: Changes between HTML 3.2 and HTML 4.0 より HTML 3.2 との違いは、だいたい次のとおりです。詳しくは仕様書のほうを参照してくださいませ。
次のタグ要素が新設されてます。
ABBR, ACRONYM, BDO, BUTTON, COLGROUP, DEL, FIELDSET, FRAME, FRAMESET, IFRAME, INS, LABEL, LEGEND, NOFRAMES, NOSCRIPT, OBJECT, OPTGROUP, PARAM, SPAN, TBODY, TFOOT, THEAD, and Q.
以下のタグは Deprecated です。
APPLET, BASEFONT, CENTER, DIR, FONT, ISINDEX, MENU, S, STRIKE, and U.
スタイルファイルの導入にともなう処置でしょう。S は、INS/DEL を使えとのことのようです。
以下のタグは obsolute です
LISTING, PLAINTEXT, and XMPかわりに PRE をつかえとのことです。
META や LINK のメタ定義を解説する profile をつけれるようになりました
id 属性によって、どんなタグでもリンク先アンカーになります
テーブルが大幅に拡張されてます。 COLGROUP 要素の追加や、各種属性の追加など詳細略
フォームががたくさん改良されてます。 LABEL, FIELDSET, LEGEND, BUTTON, OPTGROUP などの要素。 accesskey, disabled, readonly などの属性
スタイルシートが導入されました
フレームが導入されました
多くの要素で event 属性によるスクリプトの起動が可能です。 (マウスのクリックとかいろいろ)
RFC2070 から国際化の機能がとりこまれてます。違いは次のとおり
今日は B4 の発表の日でした。わたしゃプログラムとかしてて見にいかなかったのですが、みなさんとりあえずいろいろこけてた模様(^^;; お疲れさまー
研究室の忘年会が駅前の某お店でありました。料理がでてくるのが遅い(--;;; みんなでぶちぶち文句いいながら食ってました。今日は一次会で退散。学校にきてこれを書いてるっす。さ、プログラムしよう(汗)
忘年会の前にちょっと時間があったので、駅前の本屋(精分館)によってみたのですが....げ、コミケカタログがけっこうつんである....。同人誌のコーナーが前より広くなってるし....なんか趣味系のコーナー絶対広くなってるよぉ。あ、リーフのアンソロジーコミック発見。とりあえず金ないからいいや ....内容どうなんでしょうねぇ
JWWWC ですか。うーむ、私もボスにたのんで、Internet Week くっついていって、みにいこうかと思ってたのですが、結局いきませんでした(^^;; やっぱいけばよかったかも。
あさだたくやさん、こんな漢字だったんだ(^^;; 仕事が変わったってのは聞いたのですが、W3C にいったんですねー。あさたくさんが Leaf にはまったのは、 某鬼塚さんのせいです(^^;
国際化の未来ですか....。エンコーディング指定は必須ってのは当然ですね。 Unicode 3.0 やっぱ、マルチバイトなんですね....Unicode の意義はどこにいったのでしょう(^^; iso-2022 系の動きはないのでしょうか(^^;; XML ですか。よく知りません(^^;;。ドキュメントのたぐいも読んでない(^^; 必要な人には必要と思いますが、一般までの普及はどうでしょうねぇ。
ちなみに、うちのボスは、「数式〜」って嘆いてます(^^; MathML ってのもあるそうですが、どうなってるのかよくわからない(^^;;
fj からの Unicode 関連情報。 Unicode との コード変換とか、ユーザ定義文字の利用に関してのドキュメント 。Opengroup の CDE/Motif 関連のドキュメントです。
私、あのあかり、かなりお気に入りだったりするです(^^;;; 犬ちっく? いいじゃないですかぁ。ころがりながら読むのがナイス(^^;。志保もナイスですけどね。琴音ちゃん? カットがあれば十分でしょ(^^;;
FiveStar Stories の Episode Guide が発売されてるはずなので、駅前精文館にれっつらごー。お、山積みになってますな。購入承認。
Characters とか クロニクル とかまで集めてるディープな人にとっては内容的には特に新しいというほどのものではないです。でも図表とか人物相関図とかが非常にわかりやすいので、買って損はないでしょう。いくつか描き下ろしもありますし。エストかわいー(^^)
とりあえずFSSの全体がよくわからんという人用の「地図」として便利ですな。単行本しかもってないとか、よんだけどよくわからんという人や、これから読んでみようという人におすすめです。
で、なぜか、ここにリーフアンソロジーコミックとアリスの館456 があるんだな(^^; 全部で散財税込み 9576 yen(^^;;;;
アンソロジーはまだ封があいてません。アリスのほうもゲームはしばらく封印でしょう(^^;; 館、けっこうよさげなかんじです。リセットぉ〜
うむ。ついに最終局面ですな。お、ボルフォッグとペンチノン、芽生える友情(笑) なるほど、スタリオンのにーちゃんはたしかにマイクの原形なのか(^^; おお、親父はどうなるんだ? 来週もたのしみー