From 72f72d64a422d6628c4796f5c0bf2e508f134214 Mon Sep 17 00:00:00 2001 From: Tatsuya Kinoshita Date: Wed, 4 May 2011 16:05:14 +0900 Subject: Adding upstream version 0.5.1 --- doc-jp/STORY.html | 190 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 190 insertions(+) create mode 100644 doc-jp/STORY.html (limited to 'doc-jp/STORY.html') diff --git a/doc-jp/STORY.html b/doc-jp/STORY.html new file mode 100644 index 0000000..c261b47 --- /dev/null +++ b/doc-jp/STORY.html @@ -0,0 +1,190 @@ + + +w3mの開発について + + +

w3mの開発について

+
+1999/2/18
+1999/3/8改訂
+伊藤 彰則
+aito@fw.ipsj.or.jp +
+

はじめに

+w3mは，WWWに対応したページャ/ブラウザで，テキストベースで動く． +w3mに最も近いアプリケーションとして，有名なテキストベースブラウザ +Lynxがある．しかし，w3mには +Lynxにないいくつかの特徴がある．例えば， + +などだ．もちろん，Lynx は優れたブラウザで，w3mにない多くの機能を +持っている．Lynxにあってw3mにない機能は，例えば + +などなど．Lynx には豊富なドキュメントもあり，一方w3mにはほとんどまともな +ドキュメントがない．ドキュメントは今後の課題だ． +

+というわけで，w3mは既存のブラウザ(Netscapeはもちろん，Lynxも)を代替 +するものではない．それではw3mは何のためにあるのか？ +それは，日常的に「ちょっと」 web を使うためだ．専用線で接続された環境で， +「ちょっとwebを見に行きたい」とき，Netscapeを立ちあげるのはイライラする． +Lynxも立ちあがるのにちょっと間がある． +その点，w3mは一瞬で立ちあがり，マシンにほとんど負担をかけない． +そこで情報を見て，もっと詳細に見たいときに，はじめて他のブラウザを使う +のだ．もっとも私の場合，ほとんどはw3mだけで十分なのだが． + +

w3mの誕生

+

+w3m の前身は，fm +というページャ(moreやlessの親戚)だった．fmが書かれたのは1991年以前 +(記録していなかったので正確な日付はわからない)で，当時まだWWWは +一般的ではなかった(存在しなかったかも)．その当時「ブラウザ」といえば，lessなどの +ファイルを見るツールのことを指していた． +

+fm は，当時私が書いていた +研究用のプログラムをデバッグするために書いたものだ．プログラムの状態 +をトレースするため，プログラムの内部状態を延々とファイルにダンプし， +それを見ながらデバッグをしていた．ある時点での内部状態を1行にプリント +していたため，そのファイルは1行が数百文字あった．それをmoreやlessで +見ると，行が折り返されるため，何が何だかわからなくなってしまうのだった． +そこで私は，行を折り返さないページャであるfmを書いた．物理的な1行は +画面の上でも1行で，画面からはみ出した部分を見るには，画面全体をずらす +という設計にした．当時私は80x24の画面を使っていたので，fm はデバッグ +にとても役立った． +

+そのうち，私もWWWの存在を知って使いはじめた．当時使っていたブラウザは， +XMosaic と Chimera だった．特に Chimera は軽いので愛用していた． +興味があったので HTML と HTTP の勉強をしてみたが，案外簡単なので， +これなら自分でもブラウザが書けるのではないかと思った．当時のHTTPは +GOPHERプロトコルに毛が生えた程度で，非常に簡単なものだった．また， +HTML は 2.0 で，行の折り返しと箇条書きがほとんど全てだった． +そこで，fm にちょっと手を入れて，WWWブラウザを作ってみた．これがw3mだった． +ちなみに，w3m は WWW-wo-Miru (日本語だ)の略で，fm (File-wo-Miru)に +倣った．最初に w3m を書いたのは，1995年初頭だったと思う． + +

w3mの没落と再生

+

+それ以来，ずっと私は w3m を「ページャ」として使っていた．ファイルや +電子メール，マニュアルなどを読むときに，lessの代わりにしていたのだ． +w3mでwebを見ることも時々あったが，その後 w3m で正常に見られないページが +多くなった(その多くはtableを使っていた)こともあって，webブラウザと +してはほとんど使わなくなっていた．一度 table のレンダリングを検討 +したことがあったが，難しいので放ってあった． +

+もう一度 w3m に手を入れる気になったのは，1998年のことだ．動機は2つあった． +その当時，私は客員研究員としてボストン大学に滞在しており，多少時間に余裕があった +ことが一つ．もう一つは，研究日誌を HTML で書いていて，結果をどうしても表に +したくなったためだ．それまでは表を <pre>..</pre>で書いていたのだが， +plain textで表を作るのがわずらわしくて仕方なかった．とうとう我慢できなくなって +<table>タグを使ったが，そうすると今度は Netscape を使わないと日誌が +見られなくなってしまった．そこで，w3m で table の +レンダリングができるようにしようと試みた． +

+私としては，それほど複雑でない表を見ることができれば十分だった．ところが， +半端にtableに対応した結果，画面のレイアウトにtableを使っているページの +表示がぐちゃぐちゃになってしまった．結局，「表が見られて」「その他のページ +もそこそこに見られる」ようにするためには，tableの表示が完璧に近くなければ +ならないのだった．茨の道だ． +

+結局，結構時間がかかったが，何とか +実用になるものができたと思う．table の実装に気をよくして，次に form を実装 +した．これで，w3mはほぼ実用になるブラウザとして生まれ変わったのだ． + +

w3mでのtableのレンダリングアルゴリズム

+ +HTMLのtableのレンダリングは結構難しい．LaTeX の tabular のように， +「表の各列の幅を指定するか，さもなければ必要な最大の幅を取る」 +というのなら話は簡単なのだが，HTMLのtableは「画面に適当に収まるように」 +列の幅を設定して，表の内容を適当に折りかえさなければならない． +幅の決定をいいかげんにすると，非常に表が見づらくなってしまう． +また，tableは入れ子にできるので，それが話を一層ややこしくしている． +そこで，w3mでは次のようなアルゴリズムで幅を決定している． +
    +
  1. まず，各列の内容の最大幅と最小幅を求める．最大幅というのは， +もしいくらでも広い幅が取れたとしたら，最大何桁になるかというもの +だ．一般的には，<BR>や<P>で区切られた段落の長さになる． +最小幅は，それより列の幅が狭いと内容が詰められないという限界の幅 +である．表の内容が日本語だけの場合には最小幅は常に2であり， +internationalization という単語が含まれていれば最小幅は20 +である．また，表の中に<pre>..</pre>があった場合， +その一行の長さの最大値が最小幅になる． +
  2. もし，WIDTH属性で列の幅が指定してあれば，列の幅をその値で固定 +する．ただし，その幅が最小幅よりも小さければ，列の幅を最小幅で固定する． +
  3. 列の最大幅(または固定幅)を合計して，画面の幅よりも広いかどうかを調べる． +もし合計が画面に収まるなら，その値を各列の幅として使う． +
  4. もし合計が画面に収まらなければ，次のようにして幅を決定する． +
      +
    1. 画面の幅から，幅が固定された列の幅の合計を引く．これを W とする． +
    2. 幅が固定されていない列に対して，各列の最大幅の対数に比例して W を配分する． +
    3. もし配分された幅が最小幅よりも小さければ，その列の幅を最小幅で固定し， +幅の配分をやり直す． +
    +
+幅の配分を最大幅の対数に比例させているが，これでいいのかどうか検討を要する． +ただし，最大幅そのものに比例させると悲惨なことになる．table を画面レイアウト +に使っていた場合，ある列に長い文章があると，その列が画面の幅のほとんどを使って +しまうからだ．対数じゃなくて n 乗根でもいいかもしれない． +

+上記のアルゴリズムでは，画面の幅が既知であることが前提になっている．ところが， +これでは困る場合がある．どういう場合かというと，表が入れ子になっている場合だ． +外側の表の列幅がわからないと内側の表がレンダリングできないが，内側の表を +レンダリングしてみないと外側の表の幅が決定できないという矛盾に陥る．WIDTH属性 +が指定してあれば問題はないのだが，そうでない場合には，結局 +「内側の表の幅は，外側の表の幅の0.8倍」で決め打ちしてしまうことにした． +ほとんどの場合はこれで問題ないが，ある表の中に表を入れ子にして2つ並べると， +外側の表が必ず画面をはみだしてしまうようになった．もし厳密にこれを画面に収め +ようとすると，一旦レンダリングして全体の幅を調べたあと，幅を設定しなおして +もう一度レンダリングするという過程を収束するまで繰り返さなければならない． +Netscapeは，多分これをやっているのだろう． + +

利用したライブラリ

+ +w3m は， +Boehm GC +というライブラリを利用している．これは私が書いたものではないが， +コンパイル時の便宜を考えて配布パッケージに含めている． +なお，libwww は使っていない． +

+Boehm GCは，Cから使えるガベージコレクタだ．table を実装したあたりにこれを +使いはじめたのだが，非常に快適だった．GCなしでは，w3mにtableやformを実装 +する根性が私にあったかどうか疑わしい．Boehm GCの利用については，「 + +Boehm GCを使おう」という文章を書いたので，それも見ていただけると良い +と思う． +

+beta-990304より前のバージョンでは， +LIBFTPと +いうライブラリを使っていた． +libftp を使った理由は，FTPプロトコルが HTTP に比べて面倒だったためだ． +しかし，ライセンスの問題がありそうだということなので，同等の関数(のサブセット) +を自前で書いてしまった． +

+ちなみに，w3mはUNIXの正規表現ライブラリと curses ライブラリを使っていない． +どちらも自前の関数群だ．これらを自前で用意した理由は，fmを書いた当時， +日本語の通るまともでフリーな正規表現とcursesのライブラリがなかったためだ． +現在ではどちらも存在するし，他のライブラリを使った方が速そうなのだが， +面倒なので現在までこの実装を引きずっている． + +

今後の予定

+ +...ない．w3mは軽快さが売りなので，あまり機能を満載してしまうとw3m独自の +良さが失われるからだ．とはいっても，まだバグが多いので，それらのfixは +していきたいと思っている． + + + -- cgit v1.2.3 From dbd52ac2ca59d404bdcc29c5c90bda822f2c9334 Mon Sep 17 00:00:00 2001 From: Tatsuya Kinoshita Date: Thu, 24 May 2012 23:14:28 +0900 Subject: Merge from upstream on 2012-05-22 --- doc-jp/STORY.html | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc-jp/STORY.html') diff --git a/doc-jp/STORY.html b/doc-jp/STORY.html index c261b47..a3b22a4 100644 --- a/doc-jp/STORY.html +++ b/doc-jp/STORY.html @@ -158,6 +158,9 @@ w3m Boehm GC というライブラリを利用している．これは私が書いたものではないが， コンパイル時の便宜を考えて配布パッケージに含めている． +

+# Boehm GC は、w3m-0.4.2 以降のパッケージには含まれていません。 +

なお，libwww は使っていない．

Boehm GCは，Cから使えるガベージコレクタだ．table を実装したあたりにこれを -- cgit v1.2.3 From 1d0ba25a660483da1272a31dd077ed94441e3d9f Mon Sep 17 00:00:00 2001 From: Tatsuya Kinoshita Date: Sat, 2 Jan 2021 09:20:37 +0900 Subject: New upstream version 0.5.3+git20210102 --- doc-jp/STORY.html | 294 +++++++++++++++++++++++++++--------------------------- 1 file changed, 147 insertions(+), 147 deletions(-) (limited to 'doc-jp/STORY.html') diff --git a/doc-jp/STORY.html b/doc-jp/STORY.html index a3b22a4..7f78106 100644 --- a/doc-jp/STORY.html +++ b/doc-jp/STORY.html @@ -1,193 +1,193 @@ -w3mの開発について +w3m冴ゃ -

w3mの開発について

+

w3m冴ゃ

1999/2/18
-1999/3/8改訂
-伊藤 彰則
+1999/3/8壕
+篌 綵医
aito@fw.ipsj.or.jp
-

はじめに

-w3mは，WWWに対応したページャ/ブラウザで，テキストベースで動く． -w3mに最も近いアプリケーションとして，有名なテキストベースブラウザ -Lynxがある．しかし，w3mには -Lynxにないいくつかの特徴がある．例えば， +

+w3m鐚WWW絲上若吾/吟э鴻若鴻у鐚 +w3m菴≪宴若激с潟鐚鴻若鴻 +Lynx鐚鐚w3m +Lynxゃ劫彰鐚箴逸 -などだ．もちろん，Lynx は優れたブラウザで，w3mにない多くの機能を -持っている．Lynxにあってw3mにない機能は，例えば +鐚＜鐚Lynx 吟эw3m紊罘純 +ｃ鐚Lynxｃw3m罘純鐚箴 -などなど．Lynx には豊富なドキュメントもあり，一方w3mにはほとんどまともな -ドキュメントがない．ドキュメントは今後の課題だ． +鐚Lynx 莟絲ャ＜潟鐚筝w3m祉障 +ャ＜潟鐚ャ＜潟篁緇茯臥鐚

-というわけで，w3mは既存のブラウザ(Netscapeはもちろん，Lynxも)を代替 -するものではない．それではw3mは何のためにあるのか？ -それは，日常的に「ちょっと」 web を使うためだ．専用線で接続された環境で， -「ちょっとwebを見に行きたい」とき，Netscapeを立ちあげるのはイライラする． -Lynxも立ちあがるのにちょっと間がある． -その点，w3mは一瞬で立ちあがり，マシンにほとんど負担をかけない． -そこで情報を見て，もっと詳細に見たいときに，はじめて他のブラウザを使う -のだ．もっとも私の場合，ほとんどはw3mだけで十分なのだが． +эw3m√(Netscape＜鐚Lynx)篁ｆ +с鐚сw3m篏鐚 +鐚ュ幻＜ｃ web 篏帥鐚絨膩ф･膓医э +＜ｃweb荀茵鐚Netscape腴＜ゃゃ鐚 +Lynx腴＜＜ｃ鐚 +刻w3m筝х＜鐚激潟祉莢鐚 +ф宴荀鐚ｃ荅括完荀鐚篁吟篏帥 +鐚ｃ腱翫鐚祉w3mу鐚 -

w3mの誕生

+

w3m茯

-w3m の前身は，fm -というページャ(moreやlessの親戚)だった．fmが書かれたのは1991年以前 -(記録していなかったので正確な日付はわからない)で，当時まだWWWは -一般的ではなかった(存在しなかったかも)．その当時「ブラウザ」といえば，lessなどの -ファイルを見るツールのことを指していた． +w3m 荳鐚fm +若吾(moreless荀)ｃ鐚fm吾1991綛岩札 +(荐蚊ｃфｇ∈ヤ)э綵障WWW +筝сｃ(絖ｃ)鐚綵吟逸less +＜ゃ荀若鐚

-fm は，当時私が書いていた -研究用のプログラムをデバッグするために書いたものだ．プログラムの状態 -をトレースするため，プログラムの内部状態を延々とファイルにダンプし， -それを見ながらデバッグをしていた．ある時点での内部状態を1行にプリント -していたため，そのファイルは1行が数百文字あった．それをmoreやlessで -見ると，行が折り返されるため，何が何だかわからなくなってしまうのだった． -そこで私は，行を折り返さないページャであるfmを書いた．物理的な1行は -画面の上でも1行で，画面からはみ出した部分を見るには，画面全体をずらす -という設計にした．当時私は80x24の画面を使っていたので，fm はデバッグ -にとても役立った． +fm 鐚綵腱吾 +腥句違違吾鐚違倶 +若鴻鐚違倶綮吟＜ゃ潟鐚 +荀違鐚鴻с倶1茵潟 +鐚＜ゃ1茵亥丈絖ｃ鐚moreless +荀鐚茵菴鐚篏篏ｃ障ｃ鐚 +х鐚茵菴若吾ｃсfm吾鐚1茵 +脂≪筝с1茵э脂≪水冴荀鐚脂√篏 +荐荐鐚綵腱80x24脂≪篏帥ｃэfm +綵合ｃ鐚

-そのうち，私もWWWの存在を知って使いはじめた．当時使っていたブラウザは， -XMosaic と Chimera だった．特に Chimera は軽いので愛用していた． -興味があったので HTML と HTTP の勉強をしてみたが，案外簡単なので， -これなら自分でもブラウザが書けるのではないかと思った．当時のHTTPは -GOPHERプロトコルに毛が生えた程度で，非常に簡単なものだった．また， -HTML は 2.0 で，行の折り返しと箇条書きがほとんど全てだった． -そこで，fm にちょっと手を入れて，WWWブラウザを作ってみた．これがw3mだった． -ちなみに，w3m は WWW-wo-Miru (日本語だ)の略で，fm (File-wo-Miru)に -倣った．最初に w3m を書いたのは，1995年初頭だったと思う． +￥腱WWW絖ャｃ篏帥鐚綵篏帥ｃ吟鐚 +XMosaic Chimera ｃ鐚鴻 Chimera 荵純ф鐚 +潟ｃ HTML HTTP 綣激帥鐚罅紊膂≦э +с吟吾сｃ鐚綵HTTP +GOPHER潟罸腮綺э絽吾膂≦ｃ鐚障鐚 +HTML 2.0 э茵菴膊≧吾祉ｃ鐚 +эfm ＜ｃャ鐚WWW吟篏ｃ帥鐚w3mｃ鐚 +＜帥鐚w3m WWW-wo-Miru (ユ茯)ャэfm (File-wo-Miru) +ｃｃ鐚 w3m 吾鐚1995綛翫ｃ鐚 -

w3mの没落と再生

+

w3m羃∴純

-それ以来，ずっと私は w3m を「ページャ」として使っていた．ファイルや -電子メール，マニュアルなどを読むときに，lessの代わりにしていたのだ． -w3mでwebを見ることも時々あったが，その後 w3m で正常に見られないページが -多くなった(その多くはtableを使っていた)こともあって，webブラウザと -してはほとんど使わなくなっていた．一度 table のレンダリングを検討 -したことがあったが，難しいので放ってあった． +篁ユワｃ腱 w3m 若吾ｃ篏帥ｃ鐚＜ゃ +糸＜若鐚ャ≪茯鐚less篁ｃ鐚 +w3mweb荀ｃ鐚緇 w3m фｅ幻荀若吾 +紊ｃ(紊table篏帥ｃ)ｃ鐚web吟 +祉篏帥ｃ鐚筝綺 table 潟潟違罎荐 +ｃ鐚ｃф障ｃｃ鐚

-もう一度 w3m に手を入れる気になったのは，1998年のことだ．動機は2つあった． -その当時，私は客員研究員としてボストン大学に滞在しており，多少時間に余裕があった -ことが一つ．もう一つは，研究日誌を HTML で書いていて，結果をどうしても表に -したくなったためだ．それまでは表を <pre>..</pre>で書いていたのだが， -plain textで表を作るのがわずらわしくて仕方なかった．とうとう我慢できなくなって -<table>タグを使ったが，そうすると今度は Netscape を使わないと日誌が -見られなくなってしまった．そこで，w3m で table の -レンダリングができるようにしようと試みた． +筝綺 w3m ャ羂ｃ鐚1998綛眼鐚罘2ゃｃ鐚 +綵鐚腱絎√∞腥九＜鴻喝ぇ絖羯鐚紊絨篏茖ｃ +筝わ筝ゃ鐚腥倶ヨ HTML ф吾鐚腟茵 +ｃ鐚障с茵 <pre>..</pre>ф吾鐚 +plain textц；篏篁鴻ｃ鐚≪сｃ +<table>帥違篏帥ｃ鐚篁綺 Netscape 篏帥ヨ +荀ｃ障ｃ鐚эw3m table +潟潟違с荅帥鐚

-私としては，それほど複雑でない表を見ることができれば十分だった．ところが， -半端にtableに対応した結果，画面のレイアウトにtableを使っているページの -表示がぐちゃぐちゃになってしまった．結局，「表が見られて」「その他のページ -もそこそこに見られる」ようにするためには，tableの表示が完璧に近くなければ -ならないのだった．茨の道だ． +腱鐚祉茲с茵荀с医ｃ鐚鐚 +腴table絲上腟鐚脂≪ゃ≪table篏帥ｃ若吾 +茵腓冴＜＜ｃ障ｃ鐚腟絮鐚茵荀篁若 +荀鐚table茵腓冴絎с菴 +ｃ鐚鐚

-結局，結構時間がかかったが，何とか -実用になるものができたと思う．table の実装に気をよくして，次に form を実装 -した．これで，w3mはほぼ実用になるブラウザとして生まれ変わったのだ． +腟絮鐚腟罕ｃ鐚篏 +絎с鐚table 絎茖羂鐚罨＜ form 絎茖 +鐚эw3m祉弱吟障紊ｃ鐚 -

w3mでのtableのレンダリングアルゴリズム

+

w3mсtable潟潟違≪眼冴

-HTMLのtableのレンダリングは結構難しい．LaTeX の tabular のように， -「表の各列の幅を指定するか，さもなければ必要な最大の幅を取る」 -というのなら話は簡単なのだが，HTMLのtableは「画面に適当に収まるように」 -列の幅を設定して，表の内容を適当に折りかえさなければならない． -幅の決定をいいかげんにすると，非常に表が見づらくなってしまう． -また，tableは入れ子にできるので，それが話を一層ややこしくしている． -そこで，w3mでは次のようなアルゴリズムで幅を決定している． +HTMLtable潟潟違腟罕ｃ鐚LaTeX tabular 鐚 +茵綛絎鐚医荀紊с綛 +荅宴膂≦鐚HTMLtable脂≪綵障 +綛荐絎鐚茵絎鴻綵違鐚 +綛羆阪鐚絽吾茵荀ャｃ障鐚 +障鐚tableャ絖сэ荅宴筝絮ゃ鐚 +эw3mс罨＜≪眼冴у羆阪鐚
    -
  1. まず，各列の内容の最大幅と最小幅を求める．最大幅というのは， -もしいくらでも広い幅が取れたとしたら，最大何桁になるかというもの -だ．一般的には，<BR>や<P>で区切られた段落の長さになる． -最小幅は，それより列の幅が狭いと内容が詰められないという限界の幅 -である．表の内容が日本語だけの場合には最小幅は常に2であり， -internationalization という単語が含まれていれば最小幅は20 -である．また，表の中に<pre>..</pre>があった場合， -その一行の長さの最大値が最小幅になる． -
  2. もし，WIDTH属性で列の幅が指定してあれば，列の幅をその値で固定 -する．ただし，その幅が最小幅よりも小さければ，列の幅を最小幅で固定する． -
  3. 列の最大幅(または固定幅)を合計して，画面の幅よりも広いかどうかを調べる． -もし合計が画面に収まるなら，その値を各列の幅として使う． -
  4. もし合計が画面に収まらなければ，次のようにして幅を決定する． +
  5. 障鐚絎鴻紊у絨鎶羆鐚紊у鐚 +с綺綛鐚紊т罅 +鐚筝鐚<BR><P>у阪罧笈純激鐚 +絨鎶鐚綛絎鴻荅違綛 +с鐚茵絎鴻ユ茯翫絨鎶絽吾2с鐚 +internationalization 茯障井絨鎶20 +с鐚障鐚茵筝<pre>..</pre>ｃ翫鐚 +筝茵激紊уゃ絨鎶鐚 +
  6. 鐚WIDTH絮су綛絎逸綛ゃу阪 +鐚鐚綛絨鎶絨逸綛絨鎶у阪鐚 +
  7. 紊у(障阪綛)荐鐚脂≪綛綺茯帥鴻鐚 +荐脂≪障鐚ゃ綛篏帥鐚 +
  8. 荐脂≪障逸罨＜綛羆阪鐚
      -
    1. 画面の幅から，幅が固定された列の幅の合計を引く．これを W とする． -
    2. 幅が固定されていない列に対して，各列の最大幅の対数に比例して W を配分する． -
    3. もし配分された幅が最小幅よりも小さければ，その列の幅を最小幅で固定し， -幅の配分をやり直す． +
    4. 脂≪綛鐚綛阪綛荐綣鐚 W 鐚 +
    5. 綛阪絲障鐚紊у絲丈違罸箴 W 鐚 +
    6. 綛絨鎶絨逸綛絨鎶у阪鐚 +綛眼鐚
-幅の配分を最大幅の対数に比例させているが，これでいいのかどうか検討を要する． -ただし，最大幅そのものに比例させると悲惨なことになる．table を画面レイアウト -に使っていた場合，ある列に長い文章があると，その列が画面の幅のほとんどを使って -しまうからだ．対数じゃなくて n 乗根でもいいかもしれない． +綛紊у絲丈違罸箴鐚с罎荐荀鐚 +鐚紊у罸箴我鐚table 脂≪ゃ≪ +篏帥ｃ翫鐚激腴鐚脂≪綛祉篏帥ｃ +障鐚絲丈違 n 箙鴻с鐚

-上記のアルゴリズムでは，画面の幅が既知であることが前提になっている．ところが， -これでは困る場合がある．どういう場合かというと，表が入れ子になっている場合だ． -外側の表の列幅がわからないと内側の表がレンダリングできないが，内側の表を -レンダリングしてみないと外側の表の幅が決定できないという矛盾に陥る．WIDTH属性 -が指定してあれば問題はないのだが，そうでない場合には，結局 -「内側の表の幅は，外側の表の幅の0.8倍」で決め打ちしてしまうことにした． -ほとんどの場合はこれで問題ないが，ある表の中に表を入れ子にして2つ並べると， -外側の表が必ず画面をはみだしてしまうようになった．もし厳密にこれを画面に収め -ようとすると，一旦レンダリングして全体の幅を調べたあと，幅を設定しなおして -もう一度レンダリングするという過程を収束するまで繰り返さなければならない． -Netscapeは，多分これをやっているのだろう． +筝荐≪眼冴с鐚脂≪綛∝ャсｃ鐚鐚 +с違翫鐚翫鐚茵ャ絖ｃ翫鐚 +紊眼茵綛眼茵潟潟違с鐚眼茵 +潟潟違帥紊眼茵綛羆阪с障ャ鐚WIDTH絮 +絎医馹鐚с翫鐚腟絮 +眼茵綛鐚紊眼茵綛0.8ф浦＜障鐚 +祉翫у馹鐚茵筝茵ャ絖2や研鴻鐚 +紊眼茵綽脂≪帥障ｃ鐚ｳ絲脂≪ +鐚筝潟潟違篏綛茯帥鴻鐚綛荐絎 +筝綺潟潟違腮障х弘菴違鐚 +Netscape鐚紊ｃ鐚 -

利用したライブラリ

+

ゃ

-w3m は， +w3m 鐚 Boehm GC -というライブラリを利用している．これは私が書いたものではないが， -コンパイル時の便宜を考えて配布パッケージに含めている． +ゃ鐚腱吾с鐚 +潟潟ゃ箴水絽宴若吾鐚

-# Boehm GC は、w3m-0.4.2 以降のパッケージには含まれていません。 +# Boehm GC w3m-0.4.2 篁ラ宴若吾障障

-なお，libwww は使っていない． +鐚libwww 篏帥ｃ鐚

-Boehm GCは，Cから使えるガベージコレクタだ．table を実装したあたりにこれを -使いはじめたのだが，非常に快適だった．GCなしでは，w3mにtableやformを実装 -する根性が私にあったかどうか疑わしい．Boehm GCの利用については，「 +Boehm GC鐚C篏帥若吾潟帥鐚table 絎茖 +篏帥鐚絽吾綽ｃ鐚GCс鐚w3mtableform絎茖 +号с腱ｃ鐚Boehm GCゃ鐚 -Boehm GCを使おう」という文章を書いたので，それも見ていただけると良い -と思う． +Boehm GC篏帥腴吾э荀 +鐚

-beta-990304より前のバージョンでは， -LIBFTPと -いうライブラリを使っていた． -libftp を使った理由は，FTPプロトコルが HTTP に比べて面倒だったためだ． -しかし，ライセンスの問題がありそうだということなので，同等の関数(のサブセット) -を自前で書いてしまった． +beta-990304若吾с潟с鐚 +LIBFTP +ゃ篏帥ｃ鐚 +libftp 篏帥ｃ宴鐚FTP潟 HTTP 罸鴻√ｃ鐚 +鐚ゃ祉潟鴻馹э膈∽(泣祉) +ф吾障ｃ鐚

-ちなみに，w3mはUNIXの正規表現ライブラリと curses ライブラリを使っていない． -どちらも自前の関数群だ．これらを自前で用意した理由は，fmを書いた当時， -日本語の通るまともでフリーな正規表現とcursesのライブラリがなかったためだ． -現在ではどちらも存在するし，他のライブラリを使った方が速そうなのだが， -面倒なので現在までこの実装を引きずっている． +＜帥鐚w3mUNIX罩ｈ頫憗ゃ curses ゃ篏帥ｃ鐚 +＜∽亥召鐚х宴鐚fm吾綵鐚 +ユ茯障с若罩ｈ頫憗cursesゃｃ鐚 +憜с＜絖鐚篁ゃ篏帥ｃ鴻鐚 +√х憜障с絎茖綣ｃ鐚 -

今後の予定

+

篁緇篋絎

-...ない．w3mは軽快さが売りなので，あまり機能を満載してしまうとw3m独自の -良さが失われるからだ．とはいっても，まだバグが多いので，それらのfixは -していきたいと思っている． +...鐚w3m荵遵辱紕蚊э障罘純羣莠障w3m +紊宴鐚ｃ鐚障違紊эfix +ｃ鐚 -- cgit v1.2.3