HyperCardスタックへのビットマップフォントの埋め込み

HyperCardスタックにビットマップフォントを埋め込む

私は長い間HyperCardを愛してきました。子供の頃は、それを使って簡単なゲームを作りました。そして、おそらく「大人」と呼ばれるようになった今、HyperCard自体をいじって、それがどんな奇妙なことができるのかを見てみたいと思っています。今日は、テキストを…別のフォントで表示させてみようと思います。

HyperCardは、誰でもインタラクティブなプログラムを素早く構築できるようにするために、オリジナルのMacintosh向けに開発されました。これは、「グラフィックスファースト」のビジュアルオーサリングと、非常に自然なスクリプト言語（実際にそれを使うことはめったにありません）の組み合わせによって実現されています。私が大学にいた頃、何年も前に教授がHyperCardで作った天文学用計算機を使うために、まだMac Plusが稼働していました。

初期リリース後、HyperCardは、優れたフロントエンド、単発の科学ユーティリティ、データベースプログラムを作成する方法としてだけでなく、ゲームを構築する方法としても普及しました。アドベンチャーゲームがそれに最も適していました。有名なところでは、『Myst』がHyperCardで開発され、また、初期のクィアゲームの1つとしてよく挙げられるCaper in the Castroもそうでした。

興味深いフォント

古いMac関連の情報を読んでいたところ、Sioux LacyによるHyperCard用スタックConcentration 2.2が特別なビットマップフォントを埋め込んでいたという言及に出くわしました。そのスタックは、カスタムフォントを使って、マッチングを求められるカードのスート（絵柄）と値（数字）を表示していました。例えば、以下の画像では、ダイヤの6とハートの6がマッチングされているのが見えます。

［画像: Concentration v3.0がエミュレータ上で実行されています。画像がゆっくりと露光されています。2つの6、ハートの6ともう1つのダイヤの6がマッチし、ゲームは「hooray, it's a match.」と表示しています。］

Macの他の多くのものと同様に、そのフォントは間違いなくリソースを通じてスタックに埋め込まれていたのでしょう。

リソースシステム

Macの世界における「リソース」とは具体的に何なのか、少し話しましょう。コンピューターソフトウェアを書いたことがなくても、おそらく直感的に知っていると思いますが、プログラムにはコード以上のものが含まれています。最も退屈なビジネスアプリケーションでさえ、アイコン、画像、大きなテキストブロック、サウンド、カラーパレット、カスタムフォントなどの定義が必要になります。

歴史的に、これらの多くは#definesやそれに類する構造の形でプログラムコードに直接詰め込まれていました。例えば、私のBBC Bridge CompanionのTetrisクローンでは、ブロックの先頭近くのコードブロックに、すべての小さなタイルのグラフィックを設定しています。

このモデルにはいくつかの大きな問題があります。まず、英語のヘルプテキストを日本語に翻訳したり、アイコンを変更したりするような一般的な作業を行うには、プログラム全体を再ビルドするか（またはヘックスエディタでハックするか）する必要があります。より大きな問題は、少なくともAppleにとって1984年頃には、これらの要素が多くのメモリを消費し、常にメモリに置いておく必要がない方が良いということでした。

初期のMacシステムソフトウェアでは、Resource Managerは、リソースを要求するために使用するMacintosh Toolkit APIの一部でした。特定の時点でリソースをすべてアクティブに使用していない場合、システムソフトウェアはそれらに使用されていたメモリをリサイクルすることが許可されていました。これは、68000ベースのコンピューターにわずか128kBのRAMしか搭載していない状態で出荷する場合に重要でした。

リソースを実装するために、Appleのエンジニアリングチームは実行可能ファイル（およびその他の種類のファイル）を2つの部分に分割しました。データフォークとリソースフォークです。クラシックMacでダウンロードしたソフトウェアが動作しない理由について不満を言うとき、おそらくこれらの言葉を聞いたことがあるでしょう。これらの境界線はコードフラグメントの導入ですぐに曖昧になりましたが、実行可能なアプリケーションの場合、データフォークにはすべてのコードが含まれ、リソースフォークにはすべてのリソースが含まれていました。

多くの昔からのMacユーザーは、Appleの公式リソースエディタであるResEditでゲームやその他のプログラムを開き、メニューやアイコンなどを変更した楽しい思い出を持っているかもしれません。

これはResEditがGliderの悪名高いヘルプピクチャを表示しているところです：

［画像: Glider IIIのヘルプダイアログ。紙は追加のグライダー、時計はポイント、そして悪いもの：電気コンセント、紙ヘリコプター、水滴、「悪い猫」であると説明しています。ろうそくには注意するように警告しています。］

コードと「データ」を分離するというこのモデルは、他のオペレーティングシステムにも引き継がれていますが、特にWindowsでは非常に異なる方法で実装されています。

ここでは、HyperCardスタック内に保持されているリソースのみに焦点を当てます。「スタック」はHyperCardプログラムです。HyperCardの古びた「インデックスカード」のメタファーに従い、カード（または画面）のスタックを表し、HyperCardプログラムのすべてのコードとグラフィックを含んでいます。また、リソースフォークを持ち、リソースを含んでいます！

子供の頃、これは私には思いつきませんでした。HyperCardは常に、他の「本物の」Macintoshプログラムとは異なる、特別な「壁に囲まれた庭」のように感じられたので、スタックにResEditのような本物のツールを使おうとは思いませんでした。結果として、それは16ビットのAppleエコシステム全体と驚くほど一貫しています。

リソースを活用する

私のエミュレートされたBasilisk IIインストールで、HyperCardを起動し、testという名前の新しいスタックを作成しました。スタックにリソースフォークがあることを確認するために、Icon Editorを使ってアイコンを作成しました：

［画像: ひどく歪んだスパイラルのアイコンが描かれています。］

次のステップはHyperCardを閉じることでした。HyperCardは自動的に保存するため、スタックを勝手にいじる際には注意が必要です。その後、ResEditでスタックを開き、新しく作成したICONリソースが同じIDでリストに表示されているのを確認しました：

［画像: ResEditに、同じアイコンがICONリソースとして表示されています。］

ICONは、Macで利用可能な多くの種類のアイコンリソースの1つにすぎません。System 7のカラーアイコンの登場により、cicn（カラーアイコン）、icl8など、さらに多くのタイプが追加されました。しかし、HyperCardは本質的にモノクロなので、カスタムXCMD（plotcicnなど）なしでは、昔ながらの白黒ICONに留まります。

これでHyperCardスタックが実際にリソースを使用していることがわかったので、フォントが何を含んでいるかを見てみましょう。

Hello Jeff-Nichols

私の膨大なシェアウェアCDコレクションから、お気に入りの1つであるPower Tools for Macintosh 2.0を取り出しました。1992年にSoftBitから出版されたこのCDは、基本的にどこかのFTPサーバーから集められたランダムなもののタイムカプセルです。まばらに説明が付いているコレクションの中には、いくつかのフォントが含まれていました。適当にJを選び、Jeff-Nichols 72という名前のフォントを見つけました。

組み込みのSystem 7フォントビューアでプレビューすると、以下のようになります：

［画像: フォントがプレビューされています。「How razorback...」の最初の「H」だけが判読可能です。］

ああ。大文字のみのフォントで、しかも比較的装飾的なビットマップフォントです3。この実験にはこれで十分でしょう。

［画像: ResEditでフォントが開かれ、alisリソース、FONDリソース、nfntリソースが表示されています。］

ResEditでフォントを開きました。そこには3つのリソースが含まれていました。私が理解できず必要としないalis、フォントのメタデータを含むFOND、そして実際の文字を含むnfntです。FONDとnfntリソースを私のスタックにコピーし、すべてを保存してResEditを終了しました。

［画像: ResEditには、testスタックがFONDおよびnfntリソースを含んでいることが示されています。］

この新しいフォントの使用

これには少し手間がかかりました。私はフィールドを作成したかったのです。これはWindowsのInputBoxに似ています。ユーザーが入力するボックスです。HyperCardには、フィールドがどのフォントを使用するかを選択できる便利なUIがありますが、「Jeff-Nichols」フォントは認識されませんでした。オペレーティングシステムのグローバルフォントフォルダにインストールされているフォントのみが表示されました。

HyperCardにはメッセージボックスという便利な機能があり、コマンド+Mのショートカットでアクセスできます。それを選択すると、画面下部に小さなコマンドプロンプトが表示され、HyperTalkコマンドを入力できます。これらのコマンドはHyperCardランタイムにメッセージとしてディスパッチされるため、この名前が付いています。

HyperTalkはHyperCardの組み込みスクリプト言語で、自然に見える言語と、実際の自然言語を全く理解できないという能力を組み合わせています。HyperTalkだけでも何十ものブログ記事を書くことができます。いくつかの試行錯誤の後、ついにこの魔法のコマンドにたどり着きました：

set textFont of card field 1 to "Jeff-Nichols"

これにより、フォントサイズが12に設定されたままで、装飾的な72ポイントのフォントが信じられないほど小さく表示されることがわかりました。これを修正するために、HyperCardのフォントセレクタ（すでにJeff-Nicholsフォントの概念を認識していました）に戻り、フィールドのテキストをサイズ72にする必要があると指示しなければなりませんでした。HyperTalkでも同様のことができる方法があるはずですが、簡単な方法を選びました。

［画像: 新しいフォントは、信じられないほど装飾的な方法で「TEXT」を表示しています。その下には、私たちのHyperTalkコマンドを含むメッセージボックスがあります。］

その後、すべてがうまくいきました。

また、このカード上の透明なボタンに、以前作成したアイコンを使用していることにも気づくでしょう。なぜかって？さあ、わかりません。

これがどのように機能するかについての私の仮説は、Mac Toolboxがこのフォントを見つけようとするとき、それを検索する階層があり、「利用可能なリソース」がもちろんその場所の1つであるということです。私はフォントについてあまりやったことがありませんが、少なくとも基本的な理解を持つことは価値があることだと今考えています。

なぜこれをするのか？

なぜカスタムフォントを埋め込むためにこれほど多くの手間をかけるのでしょうか？プログラマーのコンピューターにそのフォントをインストールして、ビットマップ画像を作成するだけではダメなのでしょうか？

明白な理由は、動的に何かを生成したい場合でしょう。例えば、美しいグリーティングカードを生成するHyperCardスタックを作成している場合、受信者の名前を綴るために、出力テキストに派手なフォントを適用したいかもしれません。つまり、おじさんが送ってくるようなカードではなく、上品なカードです。HyperTalkには、プログラムで図形を描画するためのコマンドが豊富に用意されています。実際、既存の描画ツールはすべて、HyperCardにメッセージを送信しているだけなのです。

フォントには、アイコンにはない能力もあります。HyperCardのアイコンは32x32ピクセルに制限されていますが、カスタムフォントを使えば、画面上のどこにでも巨大で派手な文字を素早く描画できることがわかりました。

［画像: JapanEASE（HyperCardベースの日本語学習プログラム）で猫を突いています。離れた声が、猫だと思っているものは実際には「neko」と呼ばれると伝えています。］

この発見は用途が限られているように見えるかもしれませんが、フォントはリソースの一種にすぎないということを忘れないことが重要です。

スタックには、カスタムメニュー、大きなグラフィック、そしてJapanEASEのボイスオーバー（写真）のようなサウンドなど、他にも多くのものを埋め込むことができます。ローカライズされたHyperCardスタックの可能性を開く、文字列リソースをHyperTalkスクリプトから取得できることがわかっても驚きません。

結論

HyperCard全般、特にリソースについては、さらに多くのことを触れるべきことがあります。Bill Atkinson（RIP）や、Danny Goodmanのような他の勤勉なAppleエンジニアたちは、ソフトウェアを迅速に開発するための非常に特別なツールセットを作りました。私を含め、多くの人々がコンピュータープログラミングのキャリアの始まりをそれに credit できます。当時、誰もがすでにそれを知っていたように見えましたが、長年経ってもまだ多くの隠し技を持っていることを発見するのは楽しいことです。

読んでくれてありがとう！

1. 翻訳は古いマシンで解決するのが非常に面倒な問題です。例えば、PC-88のゲームでは、各ゲームが文字列を異なる方法で保存しています。「私の犬」を「私の犬」に翻訳する（これはしばしば起こります）と、パディングが必要になったり、バイナリのどこかに残りの文字列を置くスペースを見つけたり、その文字列を呼び出すコードを変更したりする必要があることがよくあります。ローカライゼーションだけでも、一般的で使いやすいリソースモデルがあれば、物事はずっと簡単になります。↩
2. XCMDはHyperTalkの「拡張コマンド」です（XFCNは「拡張関数」です。ええ、Visual Basicのように、HyperCardは値を返す呼び出しとそうでない呼び出しを区別します。）これらは通常、68Kアセンブリ言語、C、またはPascalのようなネイティブ言語で実装され、HyperCardに設計された以上の機能を与えます。例えば、Color Tools XCMDを使って色を追加できます。XCMDは、スタックに…何だと思いますか？…リソースとして埋め込まれます。HyperCardのライフサイクルの後半では、Tom PittmanのCompileIt!が開発され、HyperTalkで定義されたXCMDをネイティブコードにコンパイルしました。もし興味があるなら、フォローアップ記事を書くかもしれません。↩
3. System 7が使用する完全なプレビューテキストは、「How razorback-jumping frogs can level six piqued gymnasts!」です。ご参考までに。↩