2002年3月分。
篆書バナー鋭意作成中。……にも関わらず一昨日には『ロード・オブ・ザ・リング』を見に行ったりしてました。
ところでこのような英語の読みからつけられた邦題というのは少々悩みどころで、「冠詞がつくかつかないか」「複数形のsがつくかつかないか」により様々なバリエーションが想像されてしまいます。例えば:
……等々。
チケットを注文するときになってふとそんなことを考えてしまい、御蔭で舌がもつれてしまいました。『指輪物語』でもいいと思うのです。
(2002年3月5日)
多くのサイト制作者が、HTML文書の末尾に安易にaddress要素や注意書、ナヴィゲーションバーの類を記述してゐる。
だが、屡々、文書の構造上、變なところにそれらの記述が出現してゐる事になつてしまつてゐる場合がある。
以下略。(闇黒日記 3月3日より)
Almost ISO-HTMLにおけるDIV1〜DIV6要素は「見出しレベルの跳び越しの禁止」をプログラムでもチェックできるようにするための概念であり、要は見出しレベルが順番に現れていればいいわけで、文書構造を考えるときには「DIVn要素がどの範囲まで及ぶ」ということまで考える必要はないのではないでしょうか。
……てなことを考える自分は当分ISO-HTMLを使うのに相応しくないのかも知れません。
(2002年3月5日)
W3C HTML と ISO/JIS HTML では、文書構造という言葉自体が示すものが明確に違うため、ISO/JIS HTML な理論を無理に W3C HTML に適用する必要はないのです。
やや分かりにくい書きかたをしてしまいましたが、ISO-HTML(JIS-HTML)の話をW3CのHTMLに適用しようというのではなく、あくまでISO-HTML(JIS-HTML)の中での話のつもりでした。
具体的には、次のような構成のHTML文書があったとして、
<H1>H1</H1> <H2>H2</H2> <P>P</P> <H3>H3</H3> <P>P</P> <H2>H2</H2> <P>P</P> <ADDRESS>ADDRESS</ADDRESS>
ISO-HTMLとして文法をチェックする際、次のようにDIVn要素が補われた文書が想定されるかと思います。
<H1>H1</H1> <DIV1> <H2>H2</H2> <DIV2> <P>P</P> <H3>H3</H3> <DIV3> <P>P</P> </DIV3> </DIV2> <H2>H2</H2> <DIV2> <P>P</P> <ADDRESS>ADDRESS</ADDRESS> </DIV2> </DIV1>
しかし、このDIVn要素というのは、「見出しレベルの跳び越しがないかどうかをプログラムでチェックするための、便宜上のもの」か、それとも「HTML文書を記述する際に、著者が当然想定しておくべき文書構造までをも示すもの」なのか、というところで疑問を持ちました。
3月3日の闇黒日記では後者を採っているようでしたが、JIS-HTMLの利用者ガイドを読むと、DIVn要素については見出し順序の検証に関連しての記述しかないようなので、前者なのではないかな、と考えて先日の文を書いた次第です。
<ADDRESS>要素は,文書又は文書の主要部分の作成者又は発信元を示す。JIS X 4156は,一般的なマーク付けのためにこの要素型を使用するのは非推奨とし,<BLOCKQUOTE>, <BODY>, <DIV>, <FIELDSET>, <FORM>及び<OBJECT>の各要素の内容の中でだけ出現することを要求する。
と、利用者ガイドのADDRESS要素の説明にはありますが、これをそのまま受け取れば、BODY要素内に書かれたADDRESS要素は、どの位置にあっても文書作成者を示すものとして、文書の他の部分とは独立した構造をもつものと言えそうな気がします。
しかしDTDに従うならADDRESS要素はBODY要素直下には記述できず、DIV、FORM、FIELDSET、OBJECT要素内にしか記述できないわけで、そこのところがやはり謎であります。
↑というのはJIS-HTML規格書の附属書Bを確認しつつ書いたのですが、本家のISO/IEC 15445:2000(E) ISO-HTMLを見ると、もはやFORM要素内にもADDRESS要素は記述できなくなっているようでありました。しかしDTDの読みに自信がないので、どなたか確認頂けると有難いです。
追記: FORM要素内にADDRESS要素は記述できなくなったことはISO/IEC 15445:2000 (ISO-html)の書式についてにおいて既に指摘済みでした。
(2002年3月8日)
今日はよい報せがありました。愛用のMacが故障したためインターネットからの撤退を余儀なくされていた紺詠志さんが、9箇月の沈黙を経てようやく復帰を果たしたとのこと。めでたい。
氏はネットにおいては短編小説の書き手として活躍し、自分も大いに尊敬していた存在でありました。ウェブサイト『シコウ回路』はまだ復帰したての装いですが、そのうち小説作品も掲載されていくことと期待してます。
とりあえず、現在ネットで読める紺詠志作品をQBOOKSの1000字小説からピックアップしてみたり。お薦めを絞るのは難しいですが、『サーカス』『蛇の目の咲く町』は小説バトルのチャンピオンになってます。
(2002年3月13日)
普段、自分がHTMLを書くときは秀丸で書いて、ローカル環境に導入したAnother HTML-lintでチェックしています。このチェックをする時に、いちいちブラウザからgatewayを通さずに、編集しながら直接チェックできないかと考え、以下のような秀丸マクロを書いてみました。
$htmllint="C:\\htmllint\\htmllint";
$temp="C:\\WINDOWS\\TEMP\\htmllint\.txt";
$filename=filename2;
if ($filename=="") {
message "ファイルを保存して下さい";
endmacro;
}
title "HTML-lintでチェック中…";
run "perl "+$htmllint+" "+$filename+" >"+$temp;
openfile $temp;
title 0;
エラーがあるかないか程度のチェックには、手っ取り早くてよい感じです。
(2002年3月25日、加筆2002年8月13日)
昨日ようやくサーバ移転完了。
前の前に使っていたサーバは時々つながらなくなることがよくあり、やむなくホスティングサービスが用意してくれた代替サーバにしばらくの間移っていました。しかし技術的なことをするのにやや不自由な面があったため、今月一杯で契約が切れるのをきっかけにまた別のサービスに移ることにしたのでした。
「移る」といっても、以前から使用しているプロバイダのホスティングサービスであり、以前は当サイトもここのスペースにあった訳で、実のところ一周回って戻ってきたといった感じであります。
移るついでに、主要なページのスタイルシート読み込みlinkタグ部分をSSIで読み込むようにしました。これで代替スタイルシートも手軽に追加できるようになりまして、早速以前のスタイルが代替スタイルシートとして加わっています。
以前のスタイルで見ていたら、こちらの方がすっきりしてるように思えてきたので、こっちを優先スタイルにしてみました。
あと、IE3、IE4、NN3、NN4、w3m、Lynxはスタイルシート読み込みlinkタグを読み込まないように変更。
(2002年3月25日)
何かの日記の3月28日分「字体弄り」で述べられている「突込み
」は、たぶん自分が出したメールのことでしょう。メールの中からつっこみにあたる部分を以下に抜粋してみます。
『字体弄りの変遷』のページ中で文字参照を使用されてますが、
自分の環境では多くの文字が「・」のような表示になっています。UnicodeのE000〜F8FF(十進では57344〜63743)のコードは
Private Use Area(外字用の領域)であるので、
この範囲の文字参照の表示はフォント依存になると思われます。どのフォントを使うと正しく見えるのか……も気になるところですが、
字体を視覚的に示す方法であれば、画像を使うなどした方が
より多くの環境で読めるものとなるかと思いますが、いかがでしょう。
補足すると、petroniusさん作の字体弄りの変遷のページでは""のような外字領域の文字参照が数多く使われています。この文字参照は外字なので、特定のフォントでないと著者の意図通りの表示にはなりません。そのようなフォントに依存した表示よりは、画像を使うなどした方がよいのでは……というつっこみでした。
さらに補足を。例えば「乒」(Unicodeでは20050(十進)、4e52(十六進))の字は、Windows98のMS 明朝(北村の環境)では表示されず、Arial Unicode MSでは表示されます。この文字を表わすために"乒"や"乒"などの文字参照を使うことは、一見「フォント依存の表示方法」であるようにも見えます。
しかしこの場合はむしろ、Windows98のMS 明朝がUnicodeに未対応であることが問題となります。HTML文書における文字集合はISO10646(Unicode2.0と等価)を使用すると定められているので、"乒"の文字参照を使うことには問題ありません。またUnicodeにおいて20050(十六進で4e52)のコードは「兵から右下の丶をぬいた形の文字」と、特定の文字であることが規定されています。なのでこのコードを用いた乒という文字参照は、たとえあるフォントで表示されなくとも、コードから文字の特定は可能であり、データとしても意味のあるものと言えます。
それでは""の文字参照はどうでしょうか。petroniusさんはこれを「二点之繞 + 兔」の字として使用されているようですが、そのコードと文字を結びつけるのは特定のフォントでしかありません。Unicodeにおける57993のコードは先にも述べたとおり外字用の領域(Private Use Area)であり、いかなる特定の文字とも定められていません。同じ外字セットを共有する環境下ならともかく、広く公開するためのデータ(HTML文書)としては、57993のコードは意味を持たないと思われます。
……というわけで、(メールでは省略してましたが)単に表示の問題だけでなく文書データとしても問題があることを踏まえた上でのつっこみだったのですが、いかがでしょうか。>petroniusさん
以下、引用は「字体弄り」から。
此れは敢へて意図してあの表示を行つたものだ。漢字の字体弄りの馬鹿馬鹿しさを体感して貰ふのが裏の意図である。
「漢字の字体弄りの馬鹿馬鹿しさを体感して貰ふ
」、というのはむしろ表の意図と受け取っていました。それはともかく、なぜ「敢へて意図してあの表示を行つた
」のか、よく分からないままでいます。
あのコードで表示できるフォントが慥かにある。あるのだが、見た処で、「こんな事をしてゐるなんて」と云ふ風に思ふのが落ちだらう。
「こんな事をしてゐるなんて
」、と読者に思ってもらうことは、その前の文からするとまさしくpetroniusさんの意図するところと思うのですが、敢えてあのような表示を行うのはその意図を妨げることになるのではないでしょうか。
ところで、「何かの日記」はURLがそのうち変動してしまうのが、引用する者としてはつらいところです。「変動URL・IDあり」なページよりも「固定URL・IDなし」なページの方が、個人的には有難かったりするのです。
(2002年3月30日)
難読漢字のハンドルネームどんなのがある? スレッド経由の国字を見て思わず震えた。これは怖いぞ。一回も見たことない漢字なのに漢字っぽく見えるのが怖いし明朝体のヒゲも怖いし意味不明っぽい読み方も怖い。どぶかっちりって何だお前。怖すぎるぞおい。
さらなる怖さを味わうために、和製漢字の辞典をお薦めしましょう。また、今昔文字鏡の「どぶかっちり」フォントはさらに信じがたい字形になっており、こちらもさらなる怖さを味わえるかと思います。
そういえば「どぶかっちり」については今まで字のみの知識で由来などを知らなかったので、ついでに探してみる。能楽見たよのページより、狂言『
そのうち二人は、川にぶつかります。そこで、渡るべき浅瀬を探すために、菊市に石を投げさせます。 深いところは「ドンブリ、ズブズブ」といい、浅いところは「ドンブリ、カッチリ」と音がします。 (これがどぶかっちりというの題名の由来)
ところで「どんぶり」は、もともと井戸の中に石を投げたときの擬音語だったはずなのだが、それがなぜ器の名称になったのだろう。謎です。
他にも{井<石}で「どんぶと」とか、{井<木}で「ざんぶと」とか。
(2002年3月30日)
「何かの日記」3月31日、「re: 字体弄り」に対してより。
ご指摘を拝見させて貰つた範囲内で言へば、北村さんはどうも「 unicode の外字領域を使用して表示させるのは良くないから、画像でちやんと見られるやうにして呉れ」と云ふ事を言つてゐるんだと思ひます。
画像の使用はひとつの案としてすすめただけで、そんな命令口調で言っているつもりはないです。それはともかく、「unicode の外字領域を使用して表示させるのは良くない
」ことを指摘しています。
ですが、あの場合さう云ふ事では無く、此れは「裏の意図」として一部の文字が見えないと云ふ効果を利用してゐます。詰り、「「人名用漢字許容字体表」が、文字コードの例示字体を無視 して作成されたが為に、こんなに表示できない文字があるんだよ」と云ふ内容であり、又、「こんな些細な違ひで別の字体に区別されてゐるんだよ」と云ふ内容を言ひたいからあのやうにしてゐるのです。当時、ちやんと体系的に物事を考へて事に当つてゐればこのやうな事にはならなかつた筈です。
petroniusさんの「裏の意図」はここを読んで漸くわかったのですが、果たして現在の字体弄りの変遷のページで、その「裏の意図」が読む人に伝わるでしょうか。
「2000年6月8日以降に更新されたMS ゴシック・MS 明朝」を表示に使っている人であれば、単に「日本国内での字体の移り変りを示したもの
」として読むでしょう。文字化けはしてないので、「裏の意図」には気づきもしないと思います。
また、それ以外のフォントを使っている人にとっては、外字の文字参照部分は文字化けして見えることでしょう。が、文字化けから「裏の意図」を読み取れる人はいるでしょうか。多くの人は文字化けに出会ったら単に読めないものとみなして読みとばしてしまうだけような気がします。文字化けの原因が外字領域の文字参照であると分かった自分も、「re: 字体弄り」に対してを読むまではそんな裏の意図があるとは思いもしませんでした。しかもこの場合は字の比較が一部できなくなるので「表の意図」を伝えるのにも十分ではありません。
そのことから考えてみると、画像を使えば、フォントとは関わりなくより多くの環境で字体の比較が可能になるし、しかも「人名用漢字許容字体表が文字コードの例示字体を無視して作成されたが為に、画像でしか表示できない文字がこんなにあるんだよ」という意味をも含めることができるので一石二鳥、という気もしますが、いかがでしょう。
意図は別にしても、HTML文書として問題があると思います。
大体、外字領域のコードでしか表現できない字体が、戸籍法施行規則に規定されてゐる事、其れ自体がをかしいんぢやないですか。私はさう思ふよ。
先にも述べたとおり、外字領域のコードはいかなる特定の文字とも定められていません。外字領域のコードで何か特定の文字を表現できると考えること自体、よくないことではないでしょうか。
ウェブでよく見かける例にたとえれば、Windows環境で読めるからという理由で「○の中に1」の文字(0x8740)をShift_JISの文書にそのまま使うことと似た誤りをおかしていると思います。「○の中に1」の記号はUnicodeにはあるので&9312;と文字参照を使えば(またはUTF-8などの文字コードを使えば)よいですが、外字領域のコードは元から何の字とも対応していないのでさらに問題です。同じ外字セットを共有する環境下ならともかく、広くウェブで公開する文書としては適当でないと思います。
petroniusさんは半角カナについて、やりたいのなら、unicode の実体参照で指定なさい
、と以前述べてましたが、「Windowsで半角カナや○つき数字をそのまま書いても、同じWindows環境では見られるのだから、その限りでは文書データとしても問題ない」とお考えでしょうか。
他にも、JIS漢字には「包摂」というルールがあるので細かい字体差は包摂の範囲内とみなされるのでは、とか、縁の旧字(緣)や温の旧字(溫)はUnicodeにある字(32227,28331)なのになぜ57995,57997のコードを使うのか、ということが思い浮かんだのですが、詳しい言及は略します。特に、文字コードにはあまり詳しくないので……。
以上、書いてはみたもののさほど自信があるわけではないので、自分の記述に誤りがありましたら指摘頂けると有難いです。
(2002年3月31日)
最近「向ヶ丘遊園」で検索してくる人がちらほらいたことから「そういえば閉園するんだった」とすんでのところで思い出し、3月31日の最終日に向ヶ丘遊園へ行きました。
ついでに写真を幾つか撮影。
遊具施設もさることながら、花や植木など植物も数多くあり、子供が遊ぶだけでなく大人がのんびりするのにもよさそうな場所でありました。やはり閉園が惜しまれます。
おまけ:
囲いの中などではなく、園内の人が通るところで乗り放題な感じで置いてありました。自分もちょっと乗ってみたくもありましたが……(やや後悔)。
(2002年3月31日)