From: Takuya Asada <asada@icsd6.tj.chiba-u.ac.jp>
Real-Date: Mon, 31 Jul 1995 20:45:33 +0900
Subject: [infotalk,05116] Re: Mosaic inline Color
Message-Id: <199507311146.UAA06295@plover.icsd6.tj.chiba-u.ac.jp>

あさだなのです。既に菊池さんがちゃんとお書きになっていますが… ^^;

菊地＠高知大さん>
> 実際には、gzip の方が圧縮率が高いのと、Patent の問題が
> あって、Independent JPEG Group でも扱っていません。

結局、全然使われていないみたいだし、本とかでもあまり解説されて
いないので、私もそれくらいしか知らないです。

# イランことを書いて、ごめんなさいです。

> ＃PNG もいいけど、Progressive mode JPEG を使おうよ。

Free のものでプログレできるものって、ありましたっけ？

あさだ たくや

From: adachi.shin@icsh.cae.ntt.jp
Real-Date: Mon, 31 Jul 95 18:21:26 JST
Subject: [infotalk,05115] IBM WSs in Malaysia
Message-Id: <9507310921.AA20734@picasso.icsh.cae.ntt.jp>

皆様

  足立＠NTT です。  しょうもない質問が一点あるのですが、ご存知の
方がいらっしゃればお教え下さい。
  知人から、「マレーシアでIBM WSを購入する方法」について聞かれました。
現地のIBM WSの販売代理店を日本IBM の方にでもお問い合わせすればよさそう
だというのはわかりますが、小生、RS等のIBM WSを使ったこともないので、
いったい日本IBM のどこのどういう部署に相談すればいいのかわかりません。

＃それ以前に、ここでこういうご相談をすることが妥当かどうかもわからない
＃ですが。  (すみません)

そこで、もしご存知の方がいらっしゃれば、私へのダイレクトメールでも
結構ですので、ご教示いただけないでしょうか？  宜しくお願いします。

足立 真一 
adachi.shin@icsh.cae.ntt.jp

From: Hiroshi WATANABE/渡辺浩史 <watanabe@eindsman.tsh.cae.ntt.jp>
Real-Date: Mon, 31 Jul 1995 18:17:30 +0900
Subject: [infotalk,05114] Re: Mosaic inline Color 
Message-Id: <9507310917.AA08401@creaa.eindsman.tsh.cae.ntt.jp>

渡辺＠NTTです。

In message <9507310717.AA08760@akagai.asahi-kasei.co.jp> 
	"Masa (Masahiko Takahashi)" <taka@akagai.asahi-kasei.co.jp> writes:
>> 
>> 高橋＠LSI・情報技術研究所と申します。
>> 素人便乗質問ですが,
>> 
>> >>>>> On Mon, 31 Jul 95 16:07:05 +0900,
>> >>>>>>Hiroshi WATANABE/渡辺浩史  <watanabe@eindsman.tsh.cae.ntt.jp> said:
>> 
>> Hiroshi> これって圧縮はできるのですが、単に DCT をかけて符号化するだけ
>> Hiroshi> のような気がしますが。私の理解では JPEG は DCT をかけて人間の
>> Hiroshi> 目に余り刺激を与えない（ちょっといい方が変かな）高周波領域の 
>> Hiroshi> bit 数を落として(Q値というもので操作する?)圧縮するというもの
>> Hiroshi> で、bit 情報自体を壊してしまうので lossless な圧縮はできない
>> Hiroshi> という認識で、もし lossless を実現したいならば全ての bit を落
>> Hiroshi> とすことができない、即ち圧縮がかけられないと思っているのです
>> Hiroshi> が.....
>> 
>> DCTだと「非可逆」符号化になってしまうのではないですか？
>> JPEGだと「可逆」符号化もあったような気がしてるんですが....
>> それはDCTを使用していないような記憶が....(非常にあいまいです)

ですね、DCT は空間パターンにあわせるのですから、それ自体
圧縮されていることになりますよね。

>> 僕の認識は間違っていたですかねぇ? > どなたか詳しい方

同じく > どなたか詳しい方

fj.comp.image の話題になっているような気が....

-----
渡辺浩史 NTT通信ソフトウェア本部 事業所通信プロジェクト
E-mail  : watanabe@eindsman.tsh.cae.ntt.jp
WWW     : http://www.ntt.jp/people/kis/freinds/watanabe.html

From: Hiroshi WATANABE/渡辺浩史 <watanabe@eindsman.tsh.cae.ntt.jp>
Real-Date: Mon, 31 Jul 1995 18:14:48 +0900
Subject: [infotalk,05113] Re: Mosaic inline Color 
Message-Id: <9507310914.AA08384@creaa.eindsman.tsh.cae.ntt.jp>

渡辺＠NTTです。

In message <9507310728.AA09787@notos.is.kochi-u.ac.jp> 
	Tokio Kikuchi <tkikuchi@is.kochi-u.ac.jp> writes:
>> 菊地＠高知大です。
>> > >> 
>> > >> 細かい事を言うと、JPEG の中でも可逆圧縮な方法はあるですね。実際に
>> > >> 使っているのは、私は見た事ないですけど ^^;
>> > 
>> > これって圧縮はできるのですが、単に DCT をかけて符号化するだけの
>> > ような気がしますが。
>> 
>> JPEG の lossless は DCT を使ってはいません。２次元予測
>> なんたら、（いつもこれだ）で上と左の方の pixel との差
>> を使うことで情報量を落とすというものです。

予測符号化ですね。
JPEG って幾つ方式があるのですか。

>> 実際には、gzip の方が圧縮率が高いのと、Patent の問題が
>> あって、Independent JPEG Group でも扱っていません。

ふむふむ。

>> ＃PNG もいいけど、Progressive mode JPEG を使おうよ。

こちらは特許がないのでしょうか。

では
------
渡辺浩史 NTT通信ソフトウェア本部 事業所通信プロジェクト
E-mail: watanabe@eindsman.tsh.cae.ntt.jp
WWW   : http://www.ntt.jp/people/kis/freinds/watanabe.html

From: Tokio Kikuchi <tkikuchi@is.kochi-u.ac.jp>
Real-Date: Mon, 31 Jul 95 16:28:26 JST
Subject: [infotalk,05112] Re: Mosaic inline Color
Message-Id: <9507310728.AA09787@notos.is.kochi-u.ac.jp>

菊地＠高知大です。
> >> 
> >> 細かい事を言うと、JPEG の中でも可逆圧縮な方法はあるですね。実際に
> >> 使っているのは、私は見た事ないですけど ^^;
> 
> これって圧縮はできるのですが、単に DCT をかけて符号化するだけの
> ような気がしますが。

JPEG の lossless は DCT を使ってはいません。２次元予測
なんたら、（いつもこれだ）で上と左の方の pixel との差
を使うことで情報量を落とすというものです。

実際には、gzip の方が圧縮率が高いのと、Patent の問題が
あって、Independent JPEG Group でも扱っていません。

＃PNG もいいけど、Progressive mode JPEG を使おうよ。

---------------------------------------------------
 <a href="http://www.is.kochi-u.ac.jp/~tkikuchi/">
 菊地時夫                 tkikuchi@is.kochi-u.ac.jp
 高知大学理学部情報科学科 Tel:0888-44-8336(direct)
 780 高知市曙町2-5-1      Fax:0888-44-8361 </a>
---------------------------------------------------
高知大学卒業生ＭＬ（鯨ネット）参加者募集中 
  ..............kujira-net-request@is.kochi-u.ac.jp

From: "Masa (Masahiko Takahashi)" <taka@akagai.asahi-kasei.co.jp>
Real-Date: Mon, 31 Jul 1995 16:17:09 +0900
Subject: [infotalk,05111] Re: Mosaic inline Color 
Message-Id: <9507310717.AA08760@akagai.asahi-kasei.co.jp>

高橋＠LSI・情報技術研究所と申します。
素人便乗質問ですが,

>>>>> On Mon, 31 Jul 95 16:07:05 +0900,
>>>>>>Hiroshi WATANABE/渡辺浩史  <watanabe@eindsman.tsh.cae.ntt.jp> said:

Hiroshi> これって圧縮はできるのですが、単に DCT をかけて符号化するだけ
Hiroshi> のような気がしますが。私の理解では JPEG は DCT をかけて人間の
Hiroshi> 目に余り刺激を与えない（ちょっといい方が変かな）高周波領域の 
Hiroshi> bit 数を落として(Q値というもので操作する?)圧縮するというもの
Hiroshi> で、bit 情報自体を壊してしまうので lossless な圧縮はできない
Hiroshi> という認識で、もし lossless を実現したいならば全ての bit を落
Hiroshi> とすことができない、即ち圧縮がかけられないと思っているのです
Hiroshi> が.....

DCTだと「非可逆」符号化になってしまうのではないですか？
JPEGだと「可逆」符号化もあったような気がしてるんですが....
それはDCTを使用していないような記憶が....(非常にあいまいです)

僕の認識は間違っていたですかねぇ? > どなたか詳しい方

--------
高橋正彦  旭化成工業(株) 研究開発本部LSI情報技術研究所 R&D グループ
	  Email:taka@ljk.atsugi.asahi-kasei.co.jp
	  phone : 0462-42-3112 (office)   fax : 0462-42-3240 (office)

From: Hiroshi WATANABE/渡辺浩史 <watanabe@eindsman.tsh.cae.ntt.jp>
Real-Date: Mon, 31 Jul 1995 16:06:44 +0900
Subject: [infotalk,05110] Re: Mosaic inline Color 
Message-Id: <9507310706.AA07600@creaa.eindsman.tsh.cae.ntt.jp>

渡辺＠NTTです。

先日はいろんな方から Mosaic inline 画像について
教えて頂きありがとうございました。
やっぱ Netscape ですかね。

＃またまた疑問です。

In message <199507310638.PAA04402@plover.icsd6.tj.chiba-u.ac.jp> 
	Takuya Asada <asada@icsd6.tj.chiba-u.ac.jp> writes:
>> 土屋さん> 
>> > もう一つの特徴として JPEGは非可逆圧縮で元の画像には戻りませんが、
>> 
>> 細かい事を言うと、JPEG の中でも可逆圧縮な方法はあるですね。実際に
>> 使っているのは、私は見た事ないですけど ^^;

これって圧縮はできるのですが、単に DCT をかけて符号化するだけの
ような気がしますが。私の理解では JPEG は DCT をかけて人間の目に
余り刺激を与えない（ちょっといい方が変かな）高周波領域の bit 数
を落として(Q値というもので操作する?)圧縮するというもので、bit 
情報自体を壊してしまうので lossless な圧縮はできないという認識
で、もし lossless を実現したいならば全ての bit を落とすことが
できない、即ち圧縮がかけられないと思っているのですが.....

圧縮という言葉につられて書きましたが実は素人質問かもしれませんね。

＃なにか勘違いしていればまた教えてください

では
-----
渡辺浩史 NTT通信ソフトウェア本部 事業所通信プロジェクト
E-mail: watanabe@eindsman.tsh.cae.ntt.jp

From: fujita@nal.go.jp (FUJITA Naoyuki)
Real-Date: Mon, 31 Jul 1995 15:45:39 +0900
Subject: [infotalk,05109] Re: HTML
Message-Id: <9507310644.AA02299@asuka.nal.go.jp>

　ギリシャ文字・分数のＨＴＭＬでの表記法について色々お話うかがえて参考に
なりました。ありがとうございます。

　私のまわりでは、Netscape・Mosaicを使っている人が多数おります。Arenaという
ブラウザは今回初めて知りました。Netscape・Mosaicではテキストベースではギリ
シャ文字などはまだ使わない方が良いのかな・・・という感触を得ました。
　レポートや論文などをＷＷＷで見られるようにしようと思いＨＴＭＬ化していて
上記の疑問にぶつかったわけです。これらの種類の文章はhtmlではなくてpsかTeXに
して置いておくのが主流なのかもしれないとも思いました。
　HTML3がどうなるのか楽しみにしたいとおもいます。またHTMLについて議論の場が
あれば教えていただければ幸いです。ありがとうございました。

---藤田＠ＮＡＬ

From: Takuya Asada <asada@icsd6.tj.chiba-u.ac.jp>
Real-Date: Mon, 31 Jul 1995 15:13:43 +0900
Subject: [infotalk,05108] Re: HTML
Message-Id: <199507310638.PAA04407@plover.icsd6.tj.chiba-u.ac.jp>

あさだなのです。

川幡さん> 
> ＃SGMLやDSSSL, SPDLに興味のある方へ。
> ＃このFTPサイトにはDSSSL, SPDLのドラフトの全てが公開されてます。

あと SGML 関連の実装でしたら、http://www.falch.no/~pepper/sgmltool/
あたりからツルたぐるのが、よいのではないかと思うです。

> あ、それから最後に。記号としてのギリシャ文字は、α, βといよ
> うに表記しますが、文字としてのギリシャ文字は、&agr;, &bgr;というように
> 表記します。

えーと、前者は ENTITIES Greek Symbols (ISOgrk3)、後者は ENTITIES 
Greek Letters (ISOgrk1) つーヤツですね。

perlSGML という、DTD 解析なんかをするための perl4 用ライブラリ が
あるですが、その配布にこのへんの ENTITY 定義や、CALS, DocBook とか
html(+,2,3) なんかの DTD が付いていて、けっこー重宝してるです。

# これに付いている dtd2html という DTD 解析ツールが、結構イイです。

> 素直にISO 8859-1を使えればいいのですが、普通のエディタではちょっと面倒
> ですし、

最近、ルクセンブルグにある Timelux という会社から、EditTime とか
いう「Multilingual SGML Editor」なるシロモノが出たです。こういう
のを見ていると、欧州の人達なんかは、Unicode で結構シアワセな世界
が開けるのかなぁ、とか思うです。

> よって、SGML規格を厳密に解釈する限り、SGML文書に限っていえば、その国際
> 化に対するUnicoder達の主張に逆らいにくいこと。

ちなみに SGML のブラウザなんかを出している EBT という会社がある
ですけど、次期バージョンからは Unicode ベースになるとか…世の中
ほっとくと、どんどん Unicode になっていくですねぇ。


土屋さん>
> さらに、フリーのSGML処理系を開発している James Clark (この人 DSSSLのエ
> ディタの一人でもあるんですが)は sgmlsの次のパーサとして sp というのを 
> C++で一から書き直してまして、

えーと、この sp ですが、README には

  The source contains the following directories:
     lib - some general purpose classes, mostly templates
     parser - the parser proper
     em - an entity manager
     app - library code useful for applications
     nsgmls - an application that behaves very much like sgmls
     spam - (SP Add Markup) a normalizer; this shows how to use
       the non-ESIS information that sp provides
     api - a simple parser-independent API built on top of sp's
       native API
     sgmlnorm - a simple normalizer written using this API

みたいなカンジで書いてあって、おぉ、これはゼヒ中身を見なければ、
とか思いつつ、暇がないのと C++ が苦手なのとで、まだやってません
です。

あさだ たくや

From: Takuya Asada <asada@icsd6.tj.chiba-u.ac.jp>
Real-Date: Mon, 31 Jul 1995 11:15:36 +0900
Subject: [infotalk,05107] Re: Mosaic inline Color
Message-Id: <199507310638.PAA04402@plover.icsd6.tj.chiba-u.ac.jp>

土屋さん> 
> もう一つの特徴として JPEGは非可逆圧縮で元の画像には戻りませんが、

細かい事を言うと、JPEG の中でも可逆圧縮な方法はあるですね。実際に
使っているのは、私は見た事ないですけど ^^;

> ロゴなどの文字のように階段的に色が変わる場合には圧縮による歪が出て
> しまうので

JPEG とかでは「隣接する画素の値に正の相関がある」という仮定がいる
です。写真とかの自然画像なんかだと、これはかなり成り立つんですが、
絵のようなものではダメなわけです。

そんで、画面を細かいブロックに分けてから DCT（離散コサイン変換…
ドリカムの略でわない）というのをかけるですけど、そのために、特に
圧縮率を高くした場合に、輪郭がカクカクと滲む「ブロック化歪み」と
いう現象がおこるです。

あと同じ色がベターっと続く場合、「てんてんてん…」と五月蝿い雑音
がが出ちゃうです。ちなみにこれは「モスキート雑音」と呼ばれている
です。

詳しくは、昔「インターフェイス」誌に出ていた特集が、結構わかりや
すかったと思うです。

あさだ たくや

From: Moritaka Arai <mori@gaken.dnp.co.jp>
Real-Date: Mon, 31 Jul 1995 11:45:24 +0900
Subject: [infotalk,05106] Re: Mosaic & 16bpp 
Message-Id: <199507310245.LAA10065@turtle>

荒井＠大日本印刷です。

>内山＠神戸大です.
>
> >Mosaic-2.4用のパッチを 大日本印刷の方に 頂きました。
> >この パッチは 公開されている物なのでしょうか？
>
>私も大日本印刷の方からいただいたパッチを使っています. 公開されているも
>のか否かまではわかりません. 先日, 公開について問い合わせたのですが, メー
>ルが迷子になったのか, まだお返事をいただいておりません. もう一度問い合
>わせてみようかしら.

特に公開しているわけではありませんが、御自由になさって結構です。
DirectColor にも対応したいけど、DirectColor のサーバーが無いのでできません。
メールをもらった記憶は無いけど… どっか行っちゃったのかな…

> >頂いたパッチは CanopusのPowerWindw864+Xaccel1.2で
> >1152 x 900 x depth16、なぜか PseudoColorで うまく動かすことが
> >できました。

Depth 16 の PseudoColor は無いと思うので、default の visual (=TrueColor) で
動いてるんだと思うけど…  ＃ xdpyinfo で PseudoColor になってます？

Moritaka Arai

From: saty@ossi.com (Mr. Tsuchiya)
Real-Date: Sun, 30 Jul 1995 10:17:50 +0800
Subject: [infotalk,05105] Mosaic inline Color 
Message-Id: <9507301717.AA01767@skuld.ossi.com>

>>>>> Regarding [infotalk,05101] Re: Mosaic inline Color ; Takao Hotta <hotta@lab.kdd.co.jp> adds:

Hotta> Portable Network Graphics format (ping と発音的に同じ)です。GIFは
Hotta> 256色以上を表示できず、まるめてしまうので、JPEGと同じように24ビット
Hotta> カラーをサポートし、かつ今のJPEGにない透明化やインタレースをサポート
Hotta> しています。更に圧縮効率も良いようです。

もう一つの特徴として JPEGは非可逆圧縮で元の画像には戻りませんが、PNGは 
GIFのように可逆圧縮のはずです。JPEGの圧縮には人間の視覚の性質をうまく
利用しているところがあるので風景などの自然画ではあまり違和感がないよう
に圧縮しますが、ロゴなどの文字のように階段的に色が変わる場合には圧縮に
よる歪が出てしまうので JPEGではない別のフリーな画像フォーマットが必要
性があると聞いています。

-- 
---------------------------------------------------------------------------
TSUCHIYA Satoshi     | tsuchiya@sysrap.cs.fujitsu.co.jp | NIFTY-ID:GDC02435 
土 屋  哲 (狼疾の人) | 富士通マルチメディアプロジェクト推進本部 企画部 

From: KAWABATA Taichi <kawabata@is.s.u-tokyo.ac.jp>
Real-Date: Mon, 31 Jul 1995 02:01:04 +0900
Subject: [infotalk,05104] Re: HTML 
Message-Id: <9507301701.AA04667@tjm.is.s.u-tokyo.ac.jp>

川幡＠東大理情報です。

>>>>> "川幡" == KAWABATA Taichi <kawabata@is.s.u-tokyo.ac.jp> writes:
>>>>> "向川さん" == 向川信一/MUKAIGAWA Shin'ichi <shin@nff.ncl.omron.co.jp> writes:

川幡> 別に、latin1だけ特別扱いというわけではありません。ISO 8879には他にも 
川幡> latin2, cyrillic1, cyrillic2, greek1, greek2, num, etc. etc.など多くの
川幡> entityが定義されていますし、他の規格でもentityは定義されていますが。

向川さん> latin1とか なら entityを 定義しても たかが知れているかも知れ
向川さん> ませんが、日本語とか中国語、ハングルなどは entityで 表現する
向川さん> のは 不可能に近いですよね？
向川さん> つまり 一部の人しか 恩恵のない entityによる 表現は、(c)とか
向川さん> の 特別なグラフィック文字のみにして、latin1,2...を使いたい人
向川さん> は iso8859シリーズを 直接使うべきなんじゃないか、と 思うので
向川さん> す。

もともと、Entityというのは、何でもありの世界で、文字には限りません。
HTMLでは、とりあえず、InternetではISO 8859-1は使えるようだし、それなら
ば折角だからISO 8879で定義されているISO 8859-1に出てくるentityを使える
ようにしようじゃないか、ということだと思います。ここらへんも、Internet
の現状と、SGMLの理想のせめぎあいのようなものだと思っています。

あと、こうすれば表示装置がどの文字コードを使うかに依存しない、という利
点もありますし。

漢字に関しては、極論すれば、現在のところ日本語HTMLを定めるDTDとSGML宣
言と言うものはまったく決まっておらず、（でも実際決めるとしたら、どこが
決めるのでしょうか？？）ただそのまま英語HTMLの文字コードを日本語に置き
換えたものだけを使っているので、現状ではentityの必要性の議論はできない
と思います。

例えば日本語SGML宣言が普通の内容文字として日本語文字を認めれば、漢字の
entityは必要ないと思います。(例えば、アスキー文字には別にentity名が決
まってませんよね？)

でも、このこともHTML-WGで議論されてたのですが、そこでの提案は、漢字に
関しては&#xxxx;でxxxxはUnicodeにすればいいのでは、というものでした。

まあ、例えば&cat;で「猫」という漢字が出てくればきっと楽しいのですが、
（をいをい）漢字は明確に名前付けができないですから....

これと似た議論で、ISO/IEC 10646-1の漢字部分を決める際、他の全ての文字
コードでは、対応するラテン文字表記によるDescriptive Nameを定めているの
ですが、(例えば、「A」はLATIN CAPITAL LETTER Aという名前が付いている)
漢字にもそれをやれ、と欧米人が強要しても、CJK側は、「それは不可能だ」
と言って、結局これらの漢字は、無理矢理 CJK UNIFIED IDEOGRAPH-xxxx
(xxxxは文字コード)という名前を付けることになった、という話しを聞いたこ
とがあります。

-------------------------------------------------------------
川幡 太一   Taichi Kawabata      kawabata@is.s.u-tokyo.ac.jp
東京大学大学院理学系研究科情報科学専攻１年
-------------------------------------------------------------

From: KAWABATA Taichi <kawabata@is.s.u-tokyo.ac.jp>
Real-Date: Mon, 31 Jul 1995 01:37:32 +0900
Subject: [infotalk,05103] Re: HTML 
Message-Id: <9507301637.AA04534@tjm.is.s.u-tokyo.ac.jp>

川幡＠東大理情報です。

>>>>> "土屋さん" == Tsuchiya  <saty@ossi.com> writes:

川幡> まず、SGMLが２
川幡> バイト言語を使う人々のことや、３言語以上を使う人たちのこと、Writing
川幡> Systemが大幅に異なる言語を使うことを毛ほども考えていない

土屋さん> 誤解なさる方がいるかもしれないので、少し補足させていただくと、
土屋さん> "毛"ぐらいは考慮されています。例えば、現行のSGMLにおいて日本
土屋さん> 語文字を扱うことは可能です。

確かに、「扱うことは可能」なのですが、とてもではないですが「考慮」して
いたとは思えないのは、先ほども述べたように、JIS X 4151の表９（先ほどは
表８備考といいましたが間違いでした）にも現れていると思います。SGML宣言
は、おそらく１バイトを使う言語がその言語を使うためのように設計されたよ
うに思います。

土屋さん> 規格制定時のことは私はわからないのですが、少なくても最近2,3
土屋さん> 年は機会があるときにはこれらの点について日本側からコメントを
土屋さん> 出していますが、インターネットの世界と違って 規格を変えたが
土屋さん> らないISOの世界では単純には改善されません。

ここらへんは、TPOの問題で、ISOの規格は端から端まで絶対というわけではな
く、Internetではあくまでそれを「参考」するか、「準用」すると考えればい
いと思います。欠陥のある規格なら、その部分を使わずに、いい部分だけを使
う、ということです。そのうち規格の方があとから直る、ということを期待し
ていますし、現状に日本語HTMLはまさにそのようなものだと思っています。

現に、HTMLでは文字コードをMIMEのContent-Typeで指定できるので、その時点
ですでに厳密にはSGMLとはあっていないと思います。

土屋さん> 一方、これらの点については ISOとは別に業界ベースで見直しの動
土屋さん> きがあり、SGML Openという米国・カナダ中心のSGML関連業界団体
土屋さん> が ERCS (extended reference coding system(?)すいません正式名
土屋さん> 忘れてしまった)という conventionを提案しています。もとの提案
土屋さん> したのはオーストラリアの人です。(ここでは Unicodeを参照する
土屋さん> 文字集合として利用しています。)

ようするに、あんまり好ましくない動きというのは、Unicodeを使おう、とい
う動きなのです。ERCSは、名前だけは聞いたことがあるのですが、それを参照
するためのURL（確か、http://www.sgmlopen.orgのどこか）を探してもそのド
キュメントがなかったので、調べるのを諦めたことがあります。大体、ERCSと
いう名称からして、その考案者が、SGMLの基本に汲汲とするあまり(SGMLでは、
乱暴に言えば基本的文字集合は唯一であるべきだとして、それを
RCS(Reference Concrete Syntax)と呼んでいます) 全言語を単一の文字集合で
処理することを提案したのではないか、と勝手に想像してそのまま忘れてたの
ですが。

（思うだけなら書かなければいいですね、想像が違っていたら失礼ですので、
先にあやまっておきます。スミマセン。）

＃SGML Openといえば、某インターネット誌が、SGML Open Consortiumの偉い人
＃にインタビューした記事が昔ありましたが、そのインタビューアーが、SGMLと
＃HTMLは全く違う言語だと誤解してたため、対話が食い違っていて苦笑したのを
＃覚えています。

土屋さん> さらに、フリーのSGML処理系を開発している James Clark (この人 
土屋さん> DSSSLのエディタの一人でもあるんですが)は sgmlsの次のパーサと
土屋さん> して sp というのを C++で一から書き直してまして、

これは知りませんでした。あとで調べてみます。昔sgmlsのソースを読もうと
してそのまま忘れててソースがディスクのこやしになってるので...

とりあえず、Internetの現状とSGMLの理想（と呼べるのかどうか..）があまり
かみあってなくて、そのための解決法としてSGMLを直すより、Unicodeを使う
動きが困るということです。基本的にはLANGというSGML属性（というか、
Architectual Formのようなものなのですが）で言語を指定すればいいという
のは私は嫌いです。

-------------------------------------------------------------
川幡 太一   Taichi Kawabata      kawabata@is.s.u-tokyo.ac.jp
東京大学大学院理学系研究科情報科学専攻１年
-------------------------------------------------------------

From: Hiroaki IKEDA <ikeda@hike.te.chiba-u.ac.jp>
Real-Date: Mon, 31 Jul 1995 00:18:02 +0900
Subject: [infotalk,05102] Re: Mosaic inline Color 
Message-Id: <18656.807117482@hike1.hike.te.chiba-u.ac.jp>

池田@千葉大です．

>Date: Sun, 30 Jul 95 23:23:14 +0900
>Message-Id: <199507301423.XAA21884@besot.lab.kdd.co.jp>
>From: Takao Hotta <hotta@lab.kdd.co.jp>
>
> > >> 今、PNG が作られています。Mosaic でも PNG がサポートされるように
> > >> なるんじゃないですかね。
> > 
> > PNG ってなんなんでしょうか。おしえていただけませんか。
> 
> image/png		png
> 
> とでもやっておけば、いいと思います。Mosaic 的には image/* が xvを
> 選択しているので、自動的に外部イメージで見れます。
> 
> 早く、インラインで表示できるといいですね。pngのライブラリも
> 結構そろっているので(まだ、αやβ)、Mosaicを改造するのはそんなに
> 難しくないかも知れません。

NCSA Moasic 2.7b1では，PNGをinline imageとして表示できる機能が
インプリメントされているようです．
まだ，*.pngを使っているsiteで確かめていませんが.

池田