TidBITS-J#467/15-Feb-99 TidBITS-J#467/15-Feb-99さて、Windows ユーザー向けの Web ページはどうしてあんなに文字が小さ いのだろう? Geoff Duncan が、ポイント、パイカ、ピクセル、また Mac OS と Windows とでフォント表示の仕組みがどのように異なるのかについ て考察しながら、その一部始終を明らかにする。Adam は、Web における URL の不変性（そして壊れた URL への対処）に関わるいくつかの考え方に ついて一言申し述べる。ニュースとしては、Macintosh Runtime for Java 2.1、Action Files 1.2、ShareWay IP 2.0、そして MasterJuggler 2.0.2 をみることにしよう。
目次：
Copyright 1997 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。
TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。
今回の TidBITS のスポンサーは：
（翻訳：高島 均 <hitak@kk.iij4u.or.jp>）
Action Files 1.2 がナビゲーションサービスを横取りする -- Power On Software 社の著名な Action Files の最新のアップデートでは、Action Files が提供する拡張 Open／Save ダイアログボックスによって、とうと う Mac OS 8.5 下で Apple 社の Navigation Services をオーバーライド するようになった。このアップデートにはいくつかのバグ修正も含まれて いる。（ TidBITS-434 の“ACTION Files の使命”を参照。）今のとこ ろ、Mac OS 伝統の Open／ Save ダイアログボックスに取って替わる Navigation Services をサポートするアプリケーションがほとんどないの に引き替え、Action Files 1.2 は今やあらゆるアプリケーションの Open ／Save ダイアログボックスに現れ出るのだ。さらに、このアップデートで Kaleidoscope との互換性が増し、エイリアスや 4 GB を越えるボリューム とでもうまく働くようになり、プログラムのデフォルトの設定を越えてさ まざまなコントロールができるようになった。Action Files のオーナーな らこの新バージョンを Power On Software 社からダウンロード（1.1 MB） して、持っている登録ナンバーでそのまま使うことが可能だ。 [JLC]
<http://www.actionutilities.com/site/html/products/ACTIONFiles.html>
<http://db.tidbits.com/getbits.acgi?tbart=04931>
MasterJuggler が Mac OS 8.5 対応となる -- Alsoft 社は、同社のフォ ント管理ユーティリティである MasterJuggler の無料アップデートをリ リースした。このアップデートでは Mac OS 8.5 下でのいくつかの非互換 性を修正している。MasterJuggler 2.0.2 Update は、（フォントリソース の信頼性を検査するコンポーネントである）Font Guardian が Mac の起動 時にスキャンするようセットされているときの問題を修正する。また、 MasterJuggler のポップアップメニューから項目を選択するときのちょっ とした不具合も修正する。MasterJuggler と Suitcase 3.0 との比較につ いては TidBITS-334 の“フォント・ブティック”を参照してほしい。 2.0.2 アップデータは 350K のダウンロードだ。 [JLC]
<http://www.alsoft.com/MJPtech.html>
<http://db.tidbits.com/getbits.acgi?tbart=00956>
Open Door Network 社が ShareWay IP 2.0 をリリース -- Open Door Network 社は ShareWay IP 2.0 を出荷したところで、これは、TCP/IP を 通じて Personal File Sharing サーバあるいは昔ながらの AppleShare サーバにアクセスできるようにする同社の便利なネットワーキングユーティ リティ（ TidBITS-436 の“IP ファイル共有”を参照）のアップグレード である。ShareWay IP 2.0 の主要な新機能は、SLP（Server Location Protocol）のサポート、つまりサーバを動的に探しアクセスする手法の採 用で、AppleTalk Chooser にさらに使い勝手が近づいた。まず、ShareWay IP 2.0 ベースのサーバが SLP を通じて自らを登録することで、ユーザー は Open Door 社がバンドルする AFP Engage 2.0 を使って使用可能なサー バ一覧を見ることができるという具合だ。その他の新機能としては、バッ クグラウンドのみの操作モード、リアルタイムなログ取り、拡張されたセ キュリティ機能などがある。Apple 社の SLP プラグインの制約によって、 2.0 にアップグレードされたのは Personal バージョンと Standard バー ジョンのみだ。SLP プラグインの次期バージョンでは、Open Door 社がマ ルチサーバタイプの ShareWay IP Professional バージョンがリリースで きるようにすべきだろう。99 年 1 月 3 日以降に購入したのならアップ デートは無料で、それ以外の場合は ShareWay IP のバージョンによってシ ングルユーザーライセンスで 34 ドルから 89 ドルの価格である。サイト ライセンスのアップグレードには値引きもあり、評価版はダウンロードに より入手可能だ。 [ACE]
<http://www2.opendoor.com/gateway/sharewayip20.html>
<http://db.tidbits.com/getbits.acgi?tbart=04961>
MRJ 2.1 は高速で Explorer で使える -- Apple 社は Macintosh Runtime for Java 2.1 をリリースしたところで、これまでの MRJ よりかなりのパ フォーマンス向上が図られ、また Microsoft 社の Internet Explorer Web ブラウザで利用可能である。（Microsoft 社は、Sun 社が Microsoft 社の Java 実装に関する予審に勝訴するや否や、自社の Java バーチャルマシン のサポートを止めてしまった。 TidBITS-456 を参照のこと。）MRJ 2.1 は Sun 社の Java JDK 1.1.6 仕様に対応し、Sun 社の Java Foundation Classes や Swing インターフェースツールキット（バージョン 1.0.3 と 1.1）もサポートし、AppleScript のサポートも加わった（短期的にみてど れだけ使えるものとなるかはわからないが）。MRJ 2.1 は、今なおこの世 にあるすべての Java アプレットを実行できるものではない（実際、リリー スノートでは、Apple 社で問題を調査中の間は Yahoo にあるゲームを使わ ないようユーザーに注意を呼びかけている）のだが、MRJ 2.1 は Internet Explorer で使えるし（Explorer の Java バーチャルマシンとして MRJ が 選択されていることを確認すること）、Macintosh 用の Java 開発環境と しても使える。Netscape ブラウザは自前の Java 実装を使っていて、今の ところ MRJ は利用できない。
MRJ 2.1 には、Mac OS 7.6.1 以降（Mac OS 8.1 以降を推奨）の PowerPC ベース Mac と 最低 24 MB の RAM、20 MB の空きディスクスペース、Open Transport 1.1 以上が必要だ。MRJ 2.1 は、すべてのシステムに Text Encoding Converter 1.4.2 をインストールし、また、Mac OS 7.6.1 の場 合には Appearance コントロールパネルのバージョン 1.0.3 をインストー ルする。MRJ 2.1 には Apple Applet Runner が含まれていないので注意が 必要だが、（MRJ 2.0、ということは Mac OS 8.1 以降に同梱された）Apple 社の Applet Runner 2.0 が使えるし、Apple 社の開発者向け Web サイト から MRJ SDK をダウンロードすることも可能だ。MRJ 2.1 は 7.8 MB の ダウンロードだ。 [GD]
<http://db.tidbits.com/getbits.acgi?tbart=05182>
<http://developer.apple.com/java/>
by Adam C. Engst <ace@tidbits.com>
（翻訳：尾高 里華子 <rikako@pobox.com>）
先号で不定期連載 TidBITS ご用達ツールの第 2 段をお送りした。初回は、 NewerRAM 用の便利なユーティリティ GURU を紹介していた。先週の記事か ら GURU の記事へとリンクをたどった読者がいたのだが、彼らはそこに出 ている昨年の 11 月に我々が記した GURU の URL がもう駄目になっている のに気がつきがく然とした。
<http://db.tidbits.com/getbits.acgi?tbart=05191>
<http://www.newerram.com/New_Folder/guru.html>
この類の連絡をよく受け取るが、それは多くの企業が先のことを考えずに Web サイトをデザインし直し、その過程で現存の URL を壊してしまったり する（この操作のことを巷では“linkrot”と呼んだりする）からだ。昔の TidBITS に壊れてしまった URL が出ていても大抵の読者は紳士的であるの だが、それでも「なんで壊れたリンクをいつまでも載せているのだ」のよ うな、ちょっとした苛立ちがしばしば垣間見えたりする。
歴史的な正確さ -- 我々が最も固執している信条の中に、発行してしまっ たら後は手を入れないというのがあるが、これはしばしば非難される部分 でもある。過去、出した後で変更したのはスペルミスだけである。このポ リシーは歴史的な正確さというコンセプトを我々が支持していることに由 来している。98 年 11 月 30 日号の TidBITS に書いたことは、永遠にそ のまま残されるべきだと考えている。でもどうすれば、その号を読むすべ ての人にそれはその日に我々が発行したものそのままであることを分かっ てもらえるだろうか。この考えは自己満足にすぎないだろうが、将来、 Macintosh コミュニティと他のコンピュータユーザーがその昔どう違って いたかを調べようとする人にとってはどうであろうか。過去の正確な姿を 見ることができる未来を作りたいと思うのだ。
我々も人の子、しばしば過去のミスは直しておきたいという誘惑にかられ、 このポリシーを試されることになる。悪くは見られたくないし、ちょっと した修正一つくらいなら ... いやいや、間違いを犯したら、それを肝に銘 じて、翌週その訂正を伝えればよい。
この姿勢はもっぱら紙の出版物を扱っている世界からの受け売りである。 紙の出版に関しては純粋に物理的な理由であまり好きではないのだが、紙 は情報の不変性と分類・保管の両面に優れている。雑誌に印刷された文字 は変更できないし、ある雑誌のすべての号を整理して並べたり、ある情報 を探してざっとページをめくるなどが簡単にできる。TidBITS は電子情報 ではあるが、紙と同等のレベルの不変性と分類・保管を実現するべく努力 している。
というわけで、TidBITS で一度目にしたものは永遠にそのまま変わらない と受け取っていただきたい。タイプミスを直す以外過去に出したものに手 を入れることはしない。早く我々のデータベース内でリンクをフォワード できるようにしたいと思っている。そうすれば、どんな変更があってもオ リジナルの記事からアクセスすることが可能になるのだ。
さらに、我々は自分たちの作った URL が永遠に有効であるように努めてい る。我々の発行するもののタイトルはシンプルで一貫性があるし、我々独 自の GetBITS CGI のおかげで、我々のデータベース内にある記事一つ一つ に短くかつ不変の URL を付けることができるのだ。もちろん TidBITS Talk のスレッドもだ。
壊れている URL の取り扱い -- 幸い URL が壊れてしまっていても、あ る Web ページを再度見つけることは難しくはない。そのページがまだ存在 していればの話だが。そのやりかたは、見たいページを探すことのできる ページが現れるまで、ページやディレクトリの URL を 後ろ から削除し ていくのだ。下記の URL を例にとってみよう。
<http://www.tidbits.com/about/about-tidbits.html>
URL を入れてエラーメッセージが出たら、まずは“about-tidbits.html” の部分を削除して再度 Web ブラウザに URL を送る。URL を短くしてもエ ラーが出たら、今度は“about/”を削除してもう一度トライする。そうす ると、そのサイトのトップのページに行くことができるので、そのページ をもとに見たいところをたぐり寄せることができるはずだ。
バイナリ URL -- TidBITS Talk に新しい GURU URL をポストしたとこ ろ、これに関連した話題になった。バージョンが新しくなったプログラム をポストする際、名称にバージョン番号を入れるようにすると、アップグ レードすることが自動的に壊れた URL を生むということになってしまうの だがこれにどう対処すればよいだろうか。ソフトウェアを配布している方 は、バイナリ linkrot を避ける様々な方法が出ているスレッドをチェック していただきたい。
<http://db.tidbits.com/getbits.acgi?tlkthrd=588>
もっと知りたい方へ -- 最後にこの件に触れている Jakob Nielsen 氏の 素晴らしいコラムを 2 つ紹介しよう。最初のものは linkrot に関するも の（Web にあるリンクの 6 % 以上が壊れているらしい）で、二つ目は常に 管理の行き届いたページにしておくための“コンテンツ管理”に関するも のである。Jakob は歴史的正確さと歴史的修正を避ける必要性に関する私 のコメントにリンクを張ってある。この話題に関心のある方はご一読いた だきたい。
<http://www.useit.com/alertbox/980614.html>
<http://www.useit.com/alertbox/981129.html>
by Geoff Duncan <geoff@tidbits.com>
（翻訳：尾高 修一 <shu@pobox.com>）
（ ：亀岡 孝仁 <tkameoka@fujikura.co.jp>）
（ ：西村 尚 <hisashin@hotsync.co.jp>）
テクニカルジャーナリストとして、どうしても打ち明けなくてはならない 企業秘密がある。我々は時としていいかげんなことを書くことがあるとい うことだ。これはある意味では避けられないことであり、知識が無限大の 価値を持つことがあるように、知識を伝達するには無限大の言葉が必要な ことがあるのだ。でも、はっきり言って読者のためを思って多少のごまか しをすることもある。世の中には頭が痛くなるような真理というものもあ り、何も知らない読者を悪の落とし穴から守ることは私たちの任務でもあ るのだ。
TidBITS-465 の Adam の記事、「4.5 Web ブラウザを使いこなそう」もま さにこの例にあてはまるものだった。ここで Adam は次のように述べた。 「Windows はモニタがデフォルトで Mac の 72 dpi ではなく 96 dpi の画 面解像度を使うと考えるので、Windows ベースの Web デザイナーは、 Windows ユーザーのためにテキストが大きすぎないように、フォントサイ ズをより小さくすることが多い。Mac ユーザーはこうして読みにくい詰まっ たテキストに出くわすことになる。」
<http://db.tidbits.com/getbits.acgi?tbart=05255>
ここで Adam が述べていることは正しい。だが、TidBITS 読者はこのこと の恐ろしさをわかっていなかった。このたったの 2 文に対するコメントの 量は TidBITS 一号分に対する量よりも多いぐらいだった。フォントのレン ダリング、モニタの物理解像度、Windows と Macintosh のどちらの方式が “正しい”のか、などといった質問が大量に寄せられた。
どうしてもというのならお答えしよう。この記事では、読者を守るために 通常ジャーナリストが持ち出す盾を取りさらうことにする。あとで後悔し ても恨みっこなしだ。
虫眼鏡視力 -- Macintosh ユーザーのほとんどは堪え難いほど小さな文 字の Web ページに遭遇したことがある。まだないという方は、Microsoft 社の Web サイト、特に Windows に関するページで数分過ごしていただき たい。ここでは Mac ユーザーが 1 から 4 ピクセルしかない文字を見るこ とが少なくない。
<http://www.microsoft.com/windows/>
この現象は Web に限ったことではない。Times 10 ポイントが素晴らしい スクリーンフォントだと思っている Windows ユーザーから受け取った文書 を編集せざるをえなかったことがないだろうか? また、Arial 9 ポイント で書かれたスプレッドシートをチェックするはめになったことは? あらゆ る Windows ユーザーの目には文字が大きく見えるような虫眼鏡が内蔵され ているのだろうか?
実はそうなのだ。
ポイント様々 -- 混乱の元は誰もが使っているポイントという単位にあ る。誰もが毎日のようにポイントという単位を使う。手紙の本文には 12 ポイント、見出しには 36 ポイントという具合だ。だがポイントがそもそ も何かをご存じの方は?
1 ポイントが 1/72 インチであることは知っている方も多いだろう。これ は正解ではあるのだが、多くのコンピュータのイメージングシステム（た とえば Apple の QuickDraw や Adobe の PostScript）だけにしかあては まらない。コンピュータ以外では、ポイントの定義は様々な度量法によっ て異なり、そのいずれもぴったり 1/72 インチにはならない。
理論的には、1 ポイントは 1/12 パイカに相当する。ではパイカとは? 最 初の近代的なポイント体系は 1737 年に Pierre Fournier によって発表さ れた。彼はシセロという単位を用い、これは 12 ポイントであると同時に 0.1648 インチに相当した。したがって、1 ポイントは 0.0137 インチに相 当する。1770 年には、Francois Ambriose Didot が Fournier のシステム を当時のフランス法で定められていたフィートに合わせ、パイカを 0.1776 インチとした。1 パイカは 12 ポイントなので、1 ポイントは 0.0148 イ ンチとなる。運悪くフランスは 18 世紀末にはメートル法を採用したもの の、Didot のシステムの影響力は強く、今日に至るまでヨーロッパでは広 く使われている。Didot 式では、1 パイカは 1/6 インチよりも大きく、 よって彼の言う1 ポイント（今日でも Didot ポイントと呼ばれている）は 1/72 インチよりも大きい。
当然アメリカはアメリカで我が道を歩んできた。1879 年、アメリカでは Nelson Hawks によって開発された方式が採用され始めた。Hawks はポイン ト体系というものは彼だけが考えたものだと思っていたのだ。誰が元祖か は別として、Hawks のシステムは 10 年足らずのうちにアメリカの出版界 を席捲した。アメリカ式パイカは 0.166 インチと 1/6 インチよりもわず かに小さい。したがって 1 ポイント（パイカポイントとも呼ばれる）は 0.0138 インチとなり、Fournier の当初の値に極めて近いものになるが、 1/72 インチよりはほんの少しだけ短い。
同じく 1879 年に Hermann Berthold は Didot のポイント体系をメートル 法に変換した。Didot-Berthold 体系は今日でもドイツ、ロシア、それに東 欧で使用されている。さらにややこしいことに、ヨーロッパでは活字を直 接ミリメートルで計測し、ポイントを全く使用しない場合も多い。
パイカという用語はタイプライターやデージーホイールプリンターを知っ ている世代の読者にはさらに混乱の元となる。タイプライターなどは、水 平方向にいくつ文字を入れることができるかを基準とする。パイカ書体は 1 インチあたり 10 字、エリートは 1 インチあたり 12 字、マイクロエ リートは 1 インチあたり 15 字だ。今日では等幅フォント（Courier な ど）をそれぞれ 12、10、8 ポイントで使用すれば同等の効果が得られる。
なぜ Windows Web ページが Macintosh では小さく見えることが多いかを 理解するために、ここではコンピュータと同様に 1 インチ = 72 ポイント ということにしておく。
書体の悩み -- 文字の大きさをポイントで表す場合、計測の対象となっ ているのはそのフォントを構成する文字（またはグリフ）の高さであって 幅などの寸法ではない。したがって、1 インチ が 72 ポイントであるから には、72 ポイントの文字の高さは 1 インチであるはずだと思うだろう。 だがこれはほとんど必ず間違いなのだ。文字の高さはアセンダーの最高点、 つまりフォントを構成する文字が到達する最も高い地点（通常は小文字の d または l、あるいは大文字のどれか）からディセンダーの最低点、つま り最も低い地点（通常は小文字の j または y）までの距離を表す。ある書 体のほとんどのグリフはこの長さの一部しか使用しないため、72 ポイント でも 1 インチには達しないのだ。
これではピンと来ないという方は、ピリオドの場合を考えていただきたい。 どんなポイントサイズでも、ピリオドは同じ書体の他の文字よりもはるか に高さが低い。72 ポイントの文字を入力する際、ピリオドの高さが 1 イ ンチになるとは思わないだろう。小文字が占める縦方向の空間は大文字よ りも普通少ないし、大文字は通常全高の 2/3 程度を占める。（ちなみに、 同一書体で最も背の高い文字は大文字の J であることが多い。大文字なの にディセンダーがあるからだ。）
さらにややこしいことに、一部の書体はこのルールに違反している。特殊 記号や発音区別符号、句読点などはポイント数で指定された範囲を超える ことがあるのだ。ただし一つの文字が上限と下限の両方を超えるというこ とはあまりない。また別の書体の場合は、ポイント数で示された高さに達 しないことがある。Times が同じポイントサイズの他の書体よりも小さく 感じられるのはこのためだ。
ポイントサイズが文字の高さを示すものであれば、幅を示すものは? 一応 は絶対値ということになっているポイントとは異なり、文字輻はエムを用 いて測定される。エムとはある書体の高さを示すポイントサイズに等しい。 つまり、36 ポイントの書体なら、1 エムは 36 ポイントに等しく、12 ポ イントの書体なら 1 エムは 12 ポイントとなる。エムという単位はもとも と大文字の M を基準としたもので、それはというのも手組み活字の時代に は M が一つの書体で最も幅の広い文字だったからだ。ところが今日は、大 文字の M の幅はエムよりも狭いことが多い。文字の前後に多少の空間が設 けられているからだ。エムは相対的な単位なので重要なものなのだが、そ の意味するところについてはこの記事の主題からずれるのでここでは触れ ないことにする。
ピクセルのこと -- ここまでで、書体が結構曖昧模糊と計られる事を多 少わかって貰えたと思うので、次にコンピュータが文字をディスプレイ上 に表示するのにどの様にこの情報を使うのかを見てみよう。
例えば小説を書いていて、章の題名を 18 ポイントの文字に設定したとし よう。まず最初に、コンピュータは 18 ポイントはどのぐらいの高さかを 知る必要がある。コンピュータは １ インチは 72 ポイントだと信じて疑 わないから、これは簡単である： 18 ポイントは １ インチの 18/72 だか らちょうど 4 分の 1 インチとなる。次にコンピュータはスクリーン上に 4 分の 1 インチの高さで文字を描こうとする。
ここからが宇宙が奇妙になりはじめるのである。コンピュータはモニタを ピクセルまたは“ドット”からなる x-y 平面であると見なす。コンピュー タにとって、ディスプレイとは○○ピクセル幅で××ピクセル高の物であ り、スクリーン上のすべての物はこのピクセルを用いて表される。従って、 ディスプレイの物理的解像度はピクセル・パー・インチ (ppi) または、 もっと一般的には、ドット・パー・インチ (dpi) で表される。
4 分の 1 インチ高の 18 ポイントの文字を描くには、コンピュータは 4 分の 1 インチは何ピクセルに相当するのか知る必要がある。これを知るに はコンピュータはディスプレイに対してその物理的解像度を問い合わせれ ばいいと思うであろう - しかし、現実はそうではない。現実にはコン ピュータは、モニタサイズとか解像度とかその他いかなるものとも一切関 係なく、1 インチは何ピクセルかについて盲目的な、ほとんど病理学的と も言える 仮定 をしてしまう。
Mac の場合であれば、あなたのコンピュータは常に 72 ピクセル・パー・ インチ、つまり 72 dpi であると想定する。Windows の場合は、通常は 96 ピクセル・パー・インチ、つまり 96 dpi であると想定するが、もし "大 きいフォント" を選択している場合、Windows は 120 ピクセル・パー・イ ンチ (120 dpi) の表示が出来ると想定する。Unix の場合は色々であるが、 一般的には 75 から 100 dpi の間である。Unix のグラフィック環境では、 大抵の場合この設定が出来る何らかの方法がある、そして聞くところによ ると、Windows NT ではこの dpi 設定が出来る方法があり、多分 Windows 98 でも出来るらしい。しかしながら、根本的な問題が解決された訳ではな い：コンピュータにとってディスプレイの物理的解像度は知るすべもない。
これらの仮定の意味するところは、18 ポイントの文字を表現するのに Macintosh は 18 ピクセルを使い、Windows システムでは 24 ピクセル、 Unix システムでは通常 19 から 25 ピクセル、そして大きいフォントを 使っている Windows システムでは 30 ピクセルを使うことになる。
かように、ピクセルと言う観点だけから見れば、大抵の Windows ユーザは Macintosh 上の文字よりも 33 パーセント大きな文字を見ている - Macintosh の観点から言えば、Windows ユーザは文字を拡大像で見ている のである。これらをすべてのピクセルはすべて同条件である一台のディス プレイ上で見てみれば、その違いは一様ではなく、違いがわかる程度から 劇的まで拡がる。Windows の文字は巨大で、Macintosh の文字は小さい - あなたの好みは？下記に私の作ったサンプルがあるので見てみて欲しい。
<http://www.tidbits.com/geoff/texttest.html>
大きさは大事である -- これが我々の 20 ドルの疑問への解答につなが る：なぜ Windows ユーザのために作られた Web ページの文字は Mac 上で は小さく見えるのか？例としてあなたのコンピュータ・ディスプレイ - あ るいは Web ブラウザのウィンドウでもよい - のサイズが 640 x 480 ピク セルだとしよう。メニューバー、タイトルバーや画面上のその他諸々を除 いて、Mac の場合 12 ポイントの文字を 40 行表示できる（行間 1、つま り行間には余分なスペースを置かない場合で）。ところが同じ条件下では、 Windows は 32 行の文字しか表示できない；なぜならば Windows は文字を 表示するのにより多くのピクセルを使用するので、同じ空間にはより少な い文字しか収まらない。結果として、Windows ベースの Web 制作者達は時 として限られた空間により多くの文字を入れようとして小フォントサイズ を 指定 するので、Macintosh ユーザは二重の呪縛を受けることになる ：Macintosh スクリーン上ではもともと少ないピクセルで表示されるよう になっている文字が更に縮小されることになり、時としてはもう文字が判 読できないことすらある。
ドットが問題だ -- 根本的な問題は、コンピュータが未知の物理特性を 備えたディスプレイ装置に対して物理的な寸法であるポイントを描こうと することだ。標準的なコンピュータのモニタは基本的にアナログの投射シ ステムである。そのジオメトリはさまざまな段階に調整可能だが、モニタ 自体はある特定の物理距離を何ピクセルで表示しているのかわからない。 CRT と平面 LCD パネルの両方を含む新方式のデジタルプログラマブルディ スプレイなら、コンピュータに解像度情報を伝達できるのではないかとい う期待を抱かせているようだ。しかし、そんなことができるシステムを私 は知らないし、ビデオハードウェアとオペレーティングシステムで完全対 応しなければならないことは明らかだ。ただ、多くのディスプレイはホス トコンピュータにある種の情報を確かに伝達する。利用可能な論理的ピク セル解像度もその一つだ。
なぜ Windows と Macintosh は表示解像度に関してこういった異なる仮定 を採るのだろう？Macintosh では WYSIWYG（What You See Is What You Get）を達成しなければならない。Mac はグラフィカルインターフェースを 普及させ、Apple は、Macintosh の画面表示が Mac の印刷出力に物理的に できるだけ一致していなければならないと考えた。こうして、ピクセルは ポイントと同値となった。つまり、Mac はインチ当たり 72 ポイントだと 疑わないのとまったく同様に、インチ当たり 72 ピクセルを表示する。300 dpi のレーザプリンタより前の時代には、Mac は WYSIWYG の好例であっ た。初代のコンパクト Mac のディスプレイと Apple の初代カラーディス プレイは 71 から 74 dpi であり、Mac がディスプレイの物理解像度を知 らないという事実を押し隠す 72 dpi に十分近かった。
事実、Apple は高解像度なマルチシンクディスプレイに長年抵抗していた。 結局、1 ピクセルが 1 インチの 1/72 から遠く離れるほど、Mac は WYSIWYG コンピュータから離れていった。Windows の人気の高まりと、 PC メーカーからのコスト的圧力、ラップトップファミリーに対する強い需 要で、Apple はこの問題に関する態度を軟化し、今日、Macintosh のディ スプレイは一般的に 72 dpi よりも大きく表示する。1024 x 768 ピクセル で稼働する 17 インチモニタは、通常 85 から 90 dpi で表示する。iMac の埋め込みディスプレイは（対角線で測って）13.8 インチの表示領域があ る。ピタゴラスの定理でざっとチェックしたところ、iMac の画面は 640 x 480 でかなり低い 58 dpi だが、1024 x 768 の解像度ではほぼ 93 dpi である。13.3 インチの表示領域（同じく対角線で測って）を持つ PowerBook G3 は 1024 x 768 で 96 dpi 以上で表示する。SGI の未到着の 1600SW フラットパネルディスプレイは、110 dpi の解像度を誇っている。
<http://www.sgi.com/peripherals/flatpanel/>
Windows の 96 dpi ディスプレイの仮定に対する歴史的な理由はもっとあ いまいだ。標準は、Windows の市場占有にいくらか先立ち、Video Electronics Standards Association（VESA）の VGA（Video Graphics Adapter）仕様によって設定されたらしい。私の推測するところ、それ以前 の CGA と EGA ビデオシステムに伴う互換性の問題があったのかもしれな い。VESA のスタッフで、10 または 12 ポイント以下のサイズのテキスト が 96 dpi より低い解像度の画面で読みやすいと感じるものはいなかった ようだ。Macintosh は、主として Geneva や Monaco、Chicago、New York といった入念なデザインの画面ビットマップフォントを通して、この誤り を証明した。もっと皮肉っぽくいえば、主流の Macintosh ディスプレイの 解像度はなるほど 96 dpi 近くまで擦り寄ったが、Windows ディスプレイ はごく普通に 96 dpi という仮定をはっきりと下回る解像度を誇っている のだ。17 インチモニタと 1024 x 768 の解像度を持つ Windows ユーザー の知合いがいれば、彼らのモニタは Macintosh とちょうど同じ、恐らく 85 から 95 dpi 間で表示しているだろう。
ドットに接続 -- 願わくば、この記事が、コンピュータがいかにゆるや かにファジーな寸法（ポイント）を採れるかということと、それ自体ポイ ントサイズの恣意的な部分を使う文字を表示するためのものさしとしてい かに使うかということ、そしてコンピュータの内部的なイメージングシス テムには絶対に従うことはありえないディスプレイにいかに最終的に情報 を伝達するかということを示していればと思う。プラットフォームが同じ ではないということを抜きにしても、状況は混乱している。
Windows 擁護者は時に彼らのシステムのより高いテキスト解像度を優位だ として吹聴したり、Mac のより低いテキスト解像度が内部告発されるべき 事実だと公言したりする。歴史的に、どちらの主張も特に本当らしくは聞 こえない。Windows システムのテキストはある特定のポイントサイズでは より読みやすく表示されるが、Windows はその余分なビクセルを得るため に WYSIWYG を犠牲にしている。残念なことに、どちらのプラットフォーム の主流システムも正確なサイズのテキストを表示することはありそうもな いので、結論はみんな負けだ。
そして、印刷がうまくいくか、あるいはいかないか、システム次第。それ だけのことだ。
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
｜ 
｜ 