「Wonderful Server Life」　　第53回　　田畑 英和

　 〜環境設定編〜

　iMacがモデルチェンジしiLifeやiWorkもバージョンアップしました。XserveやMac Proでも若干アップデートがありました。これらの機種には内蔵ハードディスクを複数台内蔵できますが、オプションとしてRAIDカードが選択可能になっています。
　さて、それでは今回は環境設定「モバイル環境」について解説します。「モバイル環境」では「モバイルアカウント」を設定することができます。

◇ローカルユーザとネットワークユーザ
　では、モバイルアカウントの説明をする前に、まずはローカルアカウントとネットワークアカウントの復習からしておきましょう。一般的にそれぞれのアカウントは次のような特徴を持っています。

・ローカルアカウント
　　アカウントの保存場所：ローカルのディレクトリ(NetInfo)
　　ホーム：起動ボリュームの「/ユーザ」の下
・ネットワークアカウント
　　アカウントの保存場所：ディレクトリサーバ上(LDAP)
　　ホーム：ファイルサーバ上のネットワークホーム

　ローカルアカウントはローカル環境でのみ使用可能なアカウントであるのに対し、ネットワークアカウントはネットワーク上で共有して他のコンピュータ上で使用することができます。
　つまり、ネットワークアカウントを使えばユーザをサーバ上で一元管理できるわけですが、サーバ上で管理されているネットワークユーザを使用するには、ネットワークに接続していることが大前提となります。
　ここで問題になるのがノートパソコンです。ノートパソコンですので持ち歩いて使用することもありますが、そうなるとネットワーク上のサーバに常時アクセスすることが難しくなります。こういった環境ではネットワークユーザではなくローカルユーザを使うしかありませんが、これではユーザの一元管理が出来ませんし、場合によってはネットワークユーザとローカルユーザを環境によって使い分けるといった面倒なことになってしまいます。

◇モバイルアカウント
　そこでモバイルアカウントの出番なのですが、モバイルアカウントを使えばネットワークユーザとローカルユーザを同一のアカウントで管理できるようになります。
　どうしてこういったことができるかといいますと、モバイルアカウントの設定をおこなえば、もともとネットワークユーザとして登録しておいたユーザアカウントの情報を、ローカル上(ローカルのNetInfo)にコピーすることができるのです。また、このときホームフォルダもローカル上に作成されます。
　アカウント情報をローカル上にコピーした後は，通常のローカルユーザと同じように使用できますので、コンピュータをネットワークから切り離した状態でも使用できるということになります。さらに、もともとモバイルアカウントはネットワークユーザとしてサーバ上に登録しますので、ユーザの一元管理も可能になるというわけです。
　なおモバイルアカウントは、ノートパソコンだけではなく、デスクトップ機でも利用可能です。

◇モバイルアカウントの設定
　モバイルアカウントの設定方法ですが、まずは普通にネットワークユーザを作成します。次に「ワークグループマネージャ」の「環境設定」で「モバイル環境」を選択し、「同期」で「オフラインで使用するためにアカウントを同期する」をチェックします。
　この「モバイル環境」の設定は、他の環境設定と同様にユーザ単位で行えますし、グループ単位やコンピュータリスト単位でも設定できます。

・「モバイル環境」の環境設定
http://homepage.mac.com/htabata/MXS10.3/img/WGM_MCX/WGM_MCX_Mobile01.png

　設定しただけではまだモバイルアカウントは実際には作成されません。「モバイル環境」の「同期」を設定したアカウントを使ってコンピュータにログインすると、このとき自動的にサーバ上のアカウント情報を使ってローカル上にもアカウントが作成されます。
　「同期」の設定をしたときに、「モバイルアカウントを作成する前に確認を要求する」もチェックしておくと、ログイン時に実際にモバイルアカウントを作成するかどうかを選択することが出来ます。
　
　モバイルアカウントはクライアント上でも設定可能です。ネットワークユーザとしてログイン中に「システム環境設定」の「アカウント」を使ってモバイルアカウントの設定を行うこともできます。
　さらに、Windows ServerのActive Directoryで管理しているユーザを使ってモバイアカウントを作成することもできます。
　
　いずれかの方法でモバイルアカウントを作成すると、あとはコンピュータをネットワークから切り離しても同一のアカウントを使用し続けることができます。それでは次回はモバイルアカウントのホームの扱いについて解説します。
つづく　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

小池邦人のCarbon視点でCocoa探求（2007/08/21）

〜　Cocoa新規プロジェクトの中身　〜

今回は、テンプレートから作成した「Cocoa Application」と「CocoaDocument-based Application」の新規プロジェクトフォルダの中身を、Carbonプロジェクトの場合と比較しながら調べてみることにします。

まず最初に、Cocoa Applicationプロジェクトの内容を調べてみます。新規作成したプロジェクトの名称は「Cocoa_Test」とします。これにより、プロジェクトに必要なファイルは、すべてCocoa_Testフォルダ内に保存されます。

Cocoa_Test.xcodeprojはプロジェクトファイル（ドキュメント）自身です。これをダブルクリックすることでXcodeが起動し、対応するプロジェクトウィンドウがオープンされます。Buildフォルダには、登録ファイルのリンク関係、コンパイル後のオブジェクトファイル、Makeされた実行ファイル（アプリケーション自身）などが保存されることになります。このフォルダは削除しても、次回にプロジェクトをオープンする時に再度作成されます。よって、プロジェクトに登録しているファイルのリンク関係が壊れてMake時にエラーが出るような場合、このフォルダを削除してやれば直ることがあります。

Cocoa_Test_Prefix.pchファイルはプリコンパイルされるソースファイルであり、一般的にはプリコンパイルしておきたいヘッダファイルを記述しておくのが普通です。Carbonのデフォルト記述は#include ですが、Cocoa_Test_Prefix.pchでは以下のように記述されています。

#ifdef __OBJC__
   #import 
#endif

これにより、Cocoa.hの内容がプリコンパイルされることで、2回目からのLink処理の速度を上げることが出来ます。不思議なことに、Carbonの場合にはビルドオプションのコンパイラ設定で「プレフィックスヘッダをプリコンパイルする」オプションをONにし、「プレフィックスヘッダ」に、そのファイル名（例えばCaarbon_Test_Prefix.pch）を記述しておかないとダメなのですが、Cocoaプロジェクトでは、そのオプションはOFFのままでファイル名も記述されていません。しかし、これでもちゃんとプリコンパイルされているようなのです？謎ですね。

ところで、Cocoa.hの中身は以下のような記述となっています。

#import 
#import 
#import 

このためプロジェクトのFrameworksグループには、ヘッダ名に準拠した4つの
Framework
（Cocoa.framework,AppKit.framework,CoreData.framework,Foundation.frame
work）が登録されています。

もし、ソースコード内でQTKitやQuartzComposerなどの最新機能を使いたい場合には、プロジェクトにそれらを含むFreameworkを追加登録し、ソースファイルの必要箇所に関連ヘッダファイルを記述しておく必要があります。例えば、QTKitを使いたい時は、Xcodeのプロジェクトメニューの「プロジェクトに追加…」でプロジェクトのFrameworksグループにQTKit.frameworksを登録し、それを必要とするソースファイルの先頭には#import を記述します。ちなみに、こうしたFrameworkが保存されている場所は、システムフォルダに含まれるライブラリフォルダ内のFrameworksフォルダ内です。

English.lprojフォルダの内部には、InfoPlist.stringsとMainMenu.nibの2つのファイルが含まれています。InfoPlist.stringsは、アプケーション情報のローカライズされた文字列が記述されています。ディフォルトでは、以下のようにアバウト表示に用いるコピーライトのみが含まれています。

NSHumanReadableCopyright = "  __MyCompanyName__, 2007";

この文字列の内容を変更すると、アバウトに表示される文字列も自動で切り替わります。余談ですが、Carbonの場合には、何故だかこの文字列がアバウトに表示されません。バグでしょうか？

MainMenu.nibは、アプリケーションで用いられるメインNibファイルです。Carbonプロジェクトのmain.nibと同じ意味合いを持っています。このNibファイルの内容については次回に詳しく解説したいと思います。

English.lprojフォルダには英語にローカライズされた文字列ファイルやNibファイルを保存しておきます。別途日本語用ローカライズファイルを用意した時には、Japanese.lprojフォルダを作り、その中に必要なファイルを入れておきます。こうしたフォルダは、その後アプリケーション・パッケージのResourcesフォルダ内に複製されることになります。また同様に、アプリケーションで用いるアイコンや画像ファイルもResourcesフォルダに複製されますので、最終的にパッケージのResourcesフォルダには相当数のファイルが保存されるケースが出てきます。

こうしたことから、筆者は、先んじてプロジェクトフォルダ（今回はCocoa_Testフォルダ）内にResourcesフォルダを作り、その中にEnglish.lprojを入れてプロジェクトに再登録しています。同様にJapanese.lprojフォルダやアイコン、画像ファイルを使う時も、そのResourcesフォルダに保存しておきます。こうすれば、パッケージのResourcesフォルダ内に保存されるファイルは、すべてプロジェクフォルダのResourcesフォルダ内と一対一で対応していることになり、プロジェクトのファイル構成が分かり易くなります。

info.plistは、作成するアプリケーションに必要な各種情報が記載されているXMLファイルです。この内容は、プロジェクトウィンドウのターゲットアイコン（Cocoa_Test）をダブルクリックすることで表示される「ターゲット”Cocoa_Test”の情報」パネルの「プロパティ」タブに示される内容と同等です。ですから、info.plistを編集する必要がある場合には、直接ではなくこちらのパネル経由で操作すれば良いことになります。

main.mは唯一のソースファイルです。Objective-C用ソースファイルの拡張子は.cではなく.mである必要があります。記述内容は、以下の通りで、main()でNSApplicationMain()を呼び出しているだけです。

int main(int argc, char *argv[])
{
   return NSApplicationMain(argc,  (const char **) argv);
}

Carbonで言えば RunApplicationEventLoop()を呼び出しただけのような感じですね。しかし、Carbonアプリケーションの場合にはそれだけでは何も起こりません。メニュー用のNibファイルを呼び出したり、アプリケーション用のCarbon Event Handlerを登録したりする必要があります。また、main.nibに登録されているウィンドウを実際にオープンするためにも、それなりの手続きを記述してやる必要があります。

それと比較してCocoaの場合には、これだけの記述でMainMenu.nib内の各オブジェクトをインスタンス化し、適切なイベントコマンドとアクションのリンクまで行います。その結果としてNibファイルに登録されているウィンドウがオープンされ、メインメニューに記述されてるコマンドも認識されるアプリケーションが完成します。つまりCarbn用のプロジェクトのmain.cに記述されている処理内容を、すべてCocoa Framework側が受け持ってくれていると考えれば良いわけです。

続いてCocoa Document-based Applicationプロジェクトの方を調べてみます。新規作成したプロジェクトの名称は「Cocoa_Doc」とします。CocoaApplicationプロジェクトとの違いは、English.lprojフォルダ内にCredits.rtfとMyDocument.nibが追加されていることです。Credits.rtfにはアバウト表示での追加情報が記載されており、MyDocument.nibには、ドキュメントとしてオープンさせるべきウィンドウなどのオブジェクトが登録されています。また、MyDocumentクラス（NSDocumentクラスを継承）を記述した、MyDocument.hとMyDocument.mの2つのソースファイルも追加されています。プロジェクトフォルダ内の違いはたったこれだけです。

CocoaアプリケーションでのNibファイルの役割は、Carbonのそれとは大きく異なります。Cocoa Frameworkを用いると、ソースコードをあまり記述しなくても色々な処理がこなせるようになります。その理由のひとつがNibファイルの仕組みにあります。次回は、今回登場した2つのNibファイル、MainMenu.nibとMyDocument.nibの内容を詳しく調べてみたいと思います。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
つづく

ターミナルの向こうから　　　　　　第8回　　海上 忍

〜 MacでLaTeXを使うメリットとは・LaTeX編その2 〜

前回は、ASCII日本語TeX（てふ/てっく）（pTeX）の導入までを説明しました。今回はLaTeX編の第2回、TeXShopなどのツールを利用したLaTeX文書の作成方法を紹介します。

・道具を揃える — TeXShop編 –
　LaTeXの文書を作成するときには、テキストエディタを利用します。LaTeX文書そのものはプレインテキストですから、書体の変更などデザイン機能は必要ありません。Mac OS X備え付けのテキストエディットでも十分に対応可能です。

　しかし、LaTeXはWYSIWYGな編集機能を持たないため、書き終えたあとタイプセット（文書のコンパイル）を実行する必要があります。Mac OS Xの場合、Terminal.appなどの端末ソフトでコマンドを実行することがオーソドックスな方法ですが、タイプセットを頻繁に実行するようになると、その作業が煩わしくなってきます。

　そんなとき便利に使えるアプリケーションが「TeXShop」です。テキストエディタとしての基本的な機能のほか、［タイプセット］ボタンをクリックすればタイプセットとプレビューを一括処理できるなど、LaTeX文書のいわばIDEとしての機能を備えています。環境（\begin{ }〜\end{ }）など予約語は色分けして表示されるので、LaTeXの命令と本文を一目で区別できます。マクロ機能など拡張性も備えているので、LaTeXビギナーはもちろん”TeXニシャン”にもお勧めです。なお、TeXShopにTeXの処理系は含まれないため、前回紹介したpTeXパッケージのインストールが利用の条件となることに注意してください。

URL=http://www.uoregon.edu/~koch/texshop/

　どれだけ簡単にLaTeX文書を作成できるか、実際に試してみましょう。まずはTeXShopを起動し、環境設定パネル左下にある設定プロファイルで「pTeX（Shift JIS）」を選択、［OK］ボタンをクリックしたあとTeXShopを再起動してください。これで日本語（SJIS）を含むLaTeX文書を扱えるようになります。

　そのあと、以下のLaTeX文書をコピーし、TeXShopの画面へペーストしてください。その後［タイプセット］ボタンをクリック（新規作成ファイルは要保存）すると、TeX→DVI→PDFの順にタイプセットが実行され、美しい数式を含むPDFが表示されるはずです。

- - - - -
\documentclass{jarticle}

\begin{document}
これはp\LaTeXe{}で作成した文書です。
二次方程式（$ax^2+bx+c=0$）の解の公式も、こんな感じで
出力できます。きれいでしょ？
\[x=\frac{-b\pm \sqrt{b^2-4ac}}{2a}\]
\end{document}
- - - - -

・日本語の扱いとMac OS Xならではの事情
　数式の出力など独特の得意分野を持つLaTeXですが、日本語フォントの扱いにはいくつかの制限があります。本格的に取り組む前に、フォントについてはある程度覚悟してください。

　まず1つは、フォント種の少なさ。ASCIIが開発した日本語TeX（pTeX）および日本語LaTeX（pLaTeX2e）では、利用できるフォントはデフォルトでは明朝体（リュウミンL-KL）とゴシック体（中ゴシックBBB）のみです。他のフォントを使用することは可能ですが、pTeX/pLaTeX2eの仕様では、基本的に1つの文書に2種以上の日本語フォントを含めることを想定していません。有志ユーザが作成したフォント拡張パッケージを利用すると、同時に4〜5種のフォントを扱えるようになりますが、ワープロソフトほどの自由度は期待しないほうがいいでしょう。

　Mac OS Xの場合、システムそのものがPDFと親和性が高いことから、LaTeX文書の最終出力にPDFを使うことが好まれますが、その結果DVI→PDFコンバータ「dvipdfmx」の仕様による制限を受けます。PSTricks（直接PostScriptの命令を使うことで曲線など豊かな表現を可能にする拡張パッケージ）に対応しないことは、個人的には惜しまれる点です。PDFで使う日本語フォントを変更するときには、/usr/local/share/texmf/fonts/map/dvipdfm/base/ディレクトリ以下にある設定ファイルを書き換える必要があるなど、UNIX剥き出しな点に拒否反応を示す人も多いかもしれません。

・道具を揃える — YaTeX編 –

　Mac OS XでLaTeX文書を作成するときのツールは、前述したTeXShopもお勧めですが、Carbon Emacsでyatex（やてふ/野鳥）を使う、という手もあります。まずは、ネットワークに接続した状態で、Carbon EmacsからHelp→CarbonEmacs Package→Net Install→YaTeXを実行してください。インストールを確認するダイアログで［Yes］をクリックしたあと、「Installation done」と表示されれば準備完了です。

　もう紙幅も残り少なくなってきたので、使い方を少しだけ。YaTeXを起動（YaTeXモードの開始）するには、Carbon Emacsを再起動後、M-x yatex
（[ESC]に続けて[x]を押し、yatexと入力後[Enter]）と入力すればOK。これで、メニューバーに「YaTeX」の項目が追加されたはずです。どのような便利な使い方ができるかは、次回紹介する予定です。

◇MOSAからのお知らせと編集後記は割愛します◇

りんご味Ruby　　　第9回　　藤本 尚邦

今回は、RubyをRubyたらしめているに違いない、ブロック付きメソッド呼出しについて説明します。いきなりですが、簡単なコード例をいくつか上げてみましょう。

-----------------------------------------------
(1..10).each      { |i| puts i }       # 1から10までプリント
(1..10).map       { |i| i * -1 }       # => -1から-10までの配列
(1..10).find_all  { |i| i%2 == 0 }     # => 2から10までの偶数の配列
(1..10).inject(0) { |sum,i| sum + i }  # => 1から10までの和
(1..10).inject(1) { |prd,i| prd * i }  # => 1から10までの積 (階乗)
-----------------------------------------------

1..10 というのは、「1から10まで」を表わすRangeオブジェクト(リテラル)です。この場合、`{‘と`}’で囲った部分がブロックです。

そういえば、初回で紹介したRSSリーダにも、2つのブロック付きメソッド呼出しが含まれていました。

----------------------------------------------- RSSリーダより抜粋 --
open(url)      { |io| RSS::Parser.parse(io.read, false) }
rss.items.each { |item| puts item.title }
-----------------------------------------------

■ ブロックとは？

そもそもブロックとは何でしょう？　ひとことで言うと、実質的には

 名前のない「手続き定義」

です。メソッド呼出しがブロックをともなう場合、そのブロックで定義された「手続き」がメソッドの(意味的な)実引数として渡されます。

■ ブロック付きメソッド呼出しとは？

ブロック付きで呼び出されるメソッド(の定義)には、ブロックとして渡された「手続き」を、いつ・どこで・何回・どんな風に、実行するかがプログラムされています。どんな「手続き」かはまだわからないけど、どんな風に「手続き」を使うかにはパターン(抽象)があるというケースは結構あります。

・処理の繰り返し(イテレータ)
・並べ替え(ソート)での値の比較
・コンピュータシステム上のリソースへのアクセス
 ・IO (ファイル・ソケットなど)
 ・メモリ、スレッドなど
 ・DBトランザクション

Rubyに標準で入っているクラスライブラリには、さまざまなパターンを扱う多くのブロック付きメソッドがあらかじめ定義されています。もちろん、プログラマが自分で見つけた抽象をブロック付きメソッドとして定義することもできます。ブロック付きメソッド呼出しは、この種のパターンを抽象化してプログラムを簡潔で読みやすくするための強力な記法なのです。

■ ブロックの記法

ブロックの記法は以下の2つです。

 do |ブロックの仮引数リスト| ブロックの手続き定義 end
 {  |ブロックの仮引数リスト| ブロックの手続き定義 }

ブロック全体(仮引数リストと手続き定義)を囲む両端の記号が違うだけで、「無名の手続き定義」としての意味は同じです。便宜上、do/endで囲む記法のブロックのことを「doブロック」と呼ぶことにします。

これらの記法をどう使い分けるかですが、実引数リストの場合と同様、好みの問題かもしれません。私はおおざっぱに

・1行で書けるときは { … }
・手続き定義が長い(改行あり)ときは do … end
・返す値を使うときは { … }
・返す値を捨てるときは do … end
・DSLっぽさを強調したければ do … end

という感じで使い分けています。

■ ブロック付きメソッド呼出しの記法

 レシーバ.メソッド名               ブロック
 レシーバ.メソッド名()             ブロック
 レシーバ.メソッド名(実引数リスト) ブロック
 レシーバ.メソッド名 実引数リスト  doブロック

実引数があるときに括弧を省略した場合(4つめ)には、doブロックしか使うことができません。

ブロックのみを評価(eval)すると構文エラーになります。ブロック単体はRubyプログラムではないのです。メソッド呼出しと組み合わせて初めて、Rubyプログラムとして成立します。

■ 実例

標準Cライブラリには qsort という関数があります。この関数は、配列(とい
うかメモリアドレスとそのデータ構造に関する情報)および比較関数を引数に
とり、その配列を比較関数を使ってクイックソートするというものです。

--------------------------------------------- C言語の qsort 使用例 --
#include 
#include 
static int comp_func(const void* a, const void* b) {
 return *(long*)a - *(long*)b;
}
static void ary_fill_randam(long* ary, size_t len) {
 while (len-- > 0) ary[len] = random() % 1000;
}
static void ary_print(long* ary, size_t len) {
 int i;
 for (i = 0; i < len; i++) printf("%ld n", ary[i]);
}
int main() {
 long ary[100];
 ary_fill_randam(ary, 100);
 qsort(ary, 100, sizeof(long), comp_func);
 ary_print(ary, 100);
 return 0;
}
---------------------------------------------

これは

・配列に乱数をセットして
・それを昇順にソートして
・配列の内容をプリントする

というqsortを使ったCプログラムです。同じようなプログラムをRubyで書くと

--------------------------------------------- Rubyの場合 --
ary = (1..100).map{ rand(1000) }
ary.sort! {|a,b| a - b }
ary.each { |i| puts i }
---------------------------------------------

となります。上記の3つのプロセスすべてについて、あらかじめ定義されているブロック付きメソッドを使って簡潔に書くことが出来ました。ループ回数を制御するためだけの変数(Cプログラムのiやlen)がまったくないのも、繰り返しが抽象化されていることによる効果です。

■ まとめ

繰り返し抽象に関するブロック付きメソッドにはどんなものがあるのかな、ということに興味を持った方はRubyのオンラインマニュアルの

 http://www.ruby-lang.org/ja/man/?cmd=view;name=Enumerable

あたりを見てみるのもよいかもしれません。

今回は、概略と繰り返し抽象の簡単な説明だけで終ってしまいました。次回は、ブロック付きメソッド呼出しのもっとRubyらしい実例を紹介できればと思います。

[補足] DSL(Domain Specific Language)について詳しくは、前回紹介したマーチン・ファウラ氏の記事や、Wikipediaの記事:

* http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainSpecificLanguage
* http://ja.wikipedia.org/wiki/ドメイン固有言語

をご覧ください。

藤本裕之のプログラミング夜話　#120

　承前のごとく、タカハシ編集長のリクエストで他のnibファイル（TabView.nib）から読み込んだビュー上にあるボタンのEnable/Disableも切り替えるやり方を解説する。これまたいろいろやり方はあるが、ここでは読み込んだビューのコントローラからボタンのインスタンスへのポインタを受け取ってそいつにEnable/Disableのメッセージを送れるようにすることにする。このやり方ならEnable/Disableだけでなくボタンに表示している文字列を変更するとか、そういうことも簡単にできるからね。

　まずはMyApplication.hを開いて、以下のインスタンス変数を定義する。

IBOutlet NSButton*            button1Sw;
IBOutlet NSButton*            button2Sw;
IBOutlet NSButton*            button3Sw;

　これらはちゃんと目当てのボタンがEnable/Disableできるかどうかを確かめるためのスイッチである。チェックボックスとしてタブビューの下に配置することにする。え、別にこれをインスタンス変数として定義する必要はないんぢゃないかって？　だって、TabView.nibから読み込むビューが表示されていない時にはこいつらの方をDisableできないと変でしょ？

　お次はこれらのチェックボックスが押されたときに実行されるメソッドを定義。

- (IBAction)toggleButton1:(id)sender;
- (IBAction)toggleButton2:(id)sender;
- (IBAction)toggleButton3:(id)sender;

　こんだけを付け加えたらInterface BuilderでMainMenu.nibを開き、Instancesのタブにこのヘッダファイルをドラッグ＆ドロップする。タブビューの下にチェックボックスを3つ、名前は「Button1」「Button2」「Button3」でいいや、こんなところで凝っても何も出ないからな。で、こいつらに上のアウトレット（「button1Sw」など）とアクションメソッド（「toggleButton1」など）を連結する。あとはコーディングだけ。

　MyApplication.mを開き、-tabView:didSelectTabViewItem: を以下のように書き換える。

-(void)tabView:(NSTabView*)tabView didSelectTabViewItem:(NSTabViewItem*)tabViewItem {
    NSString* identifier = [tabViewItem identifier];
    BOOL      switches = NO;
    if([identifier isEqualToString:@"2"]){
         if(tabViewController == nil){
              tabViewController = [[MyTabViewController alloc]
                                  initWithWindowNibName: @"TabView"];
              [tabViewController setTarget:self];
              [tabViewItem setView:[[tabViewController window] contentView]];
         }
         switches = YES;
    }
    [button1Sw setEnabled:switches];
    [button2Sw setEnabled:switches];
    [button3Sw setEnabled:switches];
}

　「switches」はさっき作ったチェックボックスどもをEnableにするかDisableにするかのフラッグ。タブビューに表示されるのがTabView.nibのビューのときはYESにしてこれらのチェックボックスをEnableにする。次に「toggleButton1」などを用意……。みんな同じなので以下ではbutton1についてだけ示す。

- (IBAction)toggleButton1:(id)sender {
    [[tabViewController button1] setEnabled:(BOOL)([sender state] == NSOnState)];
}

　ここで「tabViewController」に送っている「button1」などのメッセージがつまりTabView.nibのビュー上にある「buttonNo1」へのポインタを返すもの。MyTabViewController.hを開いて

- (id)button1;

と定義し、MyTabViewController.mに

- (id)button1{
    return buttonNo1;
}

とその中身を書けばできあがりである。ここまでのプロジェクトを編集長に頼んでMOSAのサイトにアップしてもらうので、詳しくはそれを見て確認してちょうだい。質問も歓迎。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　（2007_08_16）
◇編集部から◇
今回のサンプルプログラムはMOSAのwebサイトからダウンロード可能です。
http://www.mosa.gr.jp/?p=1243

高橋真人の「プログラミング指南」第118回

プログラマのためのオブジェクト指向再入門(26)

〜XcodeによるPowerPlant X入門(9)〜

　こんにちは、高橋真人です。
　さて、今までの説明で少しはPPxのイベント処理の動きが見えてきたでしょうか？　今度は前のような変なやり方ではなく、ちゃんとWindow自身に自分へのイベントを処理させるようにしてみましょう。
　今回は、いきなりコーディングを始めるのでなく、まずこの処理をするための戦略を考えてみます。

　まず、前回のコードでは、HICommandのCarbonイベント、つまり、kEventClassCommand/kEventCommandProcessの組み合わせ（以下、便宜的に「コマンドイベント」と記します）でCarbonイベントがアプリケーション（PPx::Application）に対して送られた場合に、それを処理する形でした。
　それを今度は、イベントがApplicationに送られる前に、もしアクティブなウインドウ（PPx::Windowまたはそのサブクラス）があったら、先にそっちに
イベントが渡るようにしたいというわけです。
　ただこの場合、問題はすべてのコマンドはコマンドイベントの付加情報として渡ってくるということです。それがなぜ問題なのかというと、PPxの振り分け機能が「イベントクラス／イベント種類」の組み合わせパターンごとに1つの関数を割り振るようになっているからです。

　つまり、HICommandのいろいろなもの、たとえばkHICommandNewもkHICommandOpenも、イベントの組み合わせパターンという観点から見れば何ら違いがないため、PPxのイベント振り分けの仕組みで別々の関数に割り当てることができないのです。
　しかし、ここでやりたいのは、例えばkHICommandNewはPPx::Applicationの関数に処理をさせ、kHICommandCloseはPPx::Windowに処理させるということなのです。
　ちなみに、通常のCarbonのプログラムでは、以下のような手順でこういうケースに対処します。
　まず、ウインドウのイベントハンドラでは、

OSStatus
EventHandlerOfWindow(..., EventRef event, ...)
{
    EventClass theClass = GetEventClass(event);
    EventKind theKind = GetEventKind(event);

    if (theClass == kEventClassHICommand
        && theKind == kEventCommandProcess) {
        HICommand command;
        GetEventParameter(event, kEventParamDirectObject,
                 typeHICommand, NULL, sizeof(command), NULL, &command);

        if (command.commandID == kHICommandClose) {
            // ウインドウのクローズ処理をここで行う
            return noErr;
        }
    }

    return eventNotHandledErr;
}

　こんな感じに自分に関心のあるイベント＆コマンドの時にのみnoErrを返し、それ以外の時にはeventNotHandledErrを返すのです。Carbonイベントの仕組みでは、ハンドラがeventNotHandledErrを返した場合は次の処理候補に処理を依頼するようになっています。ここでの例では、次の処理候補はアプリケーションのイベントハンドラということになります。この辺の仕組みは、前回紹介したAppleのデベロッパサイトのドキュメントを参照してください。

　さて、PPxは以上の問題をどのように解決するのでしょうか？
　PPxの主要な機能の一つに、実はこのコマンドの処理があります。PPxでは、Carbonイベントの種類だけではなく、何とCommandの種類ごとに専用の関数を用意できる仕組みがあるのです。早速その仕組みを説明いたしましょう。
　今まで見てきましたように、PPxではEventDoerというイベント処理のためのクラスをカスタマイズ（サブクラス化）することにより、イベントの種類ごとに個別に反応する関数を呼び出す仕組みを実現しています。
　今回の、コマンドごとに個別の処理を行う場合にもこれと同じ仕組みを利用します。PPxでは、独自にイベントクラスを用意し、それにHICommandのIDをイベントの種類とすることで、イベントのクラス／種類の組み合わせを実現しています。
　このために用意されている独自のイベントクラスがSpecificCommandDoerというクラスです。コマンドは多くの場合、ユーザーのメニュー選択に伴って発生するので、このクラス以外にメニューのハンドリングなどを含めた関連クラスがいくつかあり、これらはすべて、PPxCommadEvents.hに記述されています。
　本質的にはSpecificCommandDoerの使い方を理解できれば、他のクラスの使い方に関しても要領はほぼ同じなので、やり方は想像付くと思うのですが、まずはメニュー処理も同時にハンドリングしてくれるSpecificMenuCommandDoerというクラスを取り上げてみます。
　実際にやってみましょう。
　連載の第111回でやったのと同じ要領で今度は、PPxForXcode03というプロジェクトを作ります。01を複製しても02を複製しても構いませんが、01を複製した場合は、MyApplication.hとMyApplication.cpを作っておいてください。
　加えて、今度のプロジェクトではMyWindow.hとMyWindow.cpというファイルを加えます。やり方については、連載の第112回目を参照してください。

以上の操作で、
main.cp
MyApplication.h
MyApplication.cp
MyWindow.h
MyWindow.cp
という5つのソースファイルがプロジェクトに加わっているはずです。ではコードを入れていきます。

まず、main.cpは前のもの(02)と共通です。

====================== MyApplication.h =========================

#include 
#include 

class MyApplication : public PPx::Application,
                     public PPx::CommandConverter,
                     public PPx::SpecificMenuCommandEnableDoer,
                     public PPx::SpecificMenuCommandDoer
{
public:
                    MyApplication();


protected:
    virtual OSStatus    DoSpecificCommand(
                            PPx::CommandIDType,
                            PPx::SysCarbonEvent&       ioEvent);
};

====================== MyApplication.cp =========================

#include "MyApplication.h"
#include 
#include "MyWindow.h"

MyApplication::MyApplication()
{
    EventTargetRef targetRef = GetSysEventTarget();
    CommandConverter::Install(targetRef);
    PPx::SpecificMenuCommandEnableDoer::Install(targetRef);
    PPx::SpecificMenuCommandDoer::Install(targetRef);
}


OSStatus
MyApplication::DoSpecificCommand(
                            PPx::CommandIDType,
                            PPx::SysCarbonEvent& ioEvent)
{
    OSStatus status = eventNotHandledErr;

    MyWindow* theWindow = PPx::NibDecoder::CreateWindowFromNib(
                                                   CFSTR("main"), CFSTR("MainWindow"));
    if (theWindow) {
        ::RepositionWindow(theWindow->GetSysWindow(), nil, kWindowCascadeOnMainScreen);
        theWindow->Show();
        status = noErr;
    }

    return status;
}

====================== MyWindow.h =========================

#include 
#include 

class MyWindow : public PPx::Window,
                 public PPx::SpecificMenuCommandDoer
{
    virtual OSStatus    DoSpecificCommand(
                            PPx::CommandIDType,
                            PPx::SysCarbonEvent&          ioEvent);
private:
    virtual void        FinishInit();
};

====================== MyWindow.cp =========================

#include "MyWindow.h"
#include 

void
MyWindow::FinishInit()
{
    EventTargetRef targetRef = GetSysEventTarget();
    PPx::SpecificMenuCommandDoer::Install(targetRef);
}

OSStatus
MyWindow::DoSpecificCommand(
                PPx::CommandIDType,
                PPx::SysCarbonEvent&   ioEvent)
{
    Close();

    return noErr;
}

　以上を打ち込むかコピーしたら、ビルドして実行してみてください。まずは動作を観察しましょう。前のものと挙動として変わっているのがどこなのかをいろいろ試して探してみてください。

◇MOSAからのお知らせと編集後記は割愛します◇

「Wonderful Server Life」　　第52回　　田畑 英和

　 〜環境設定編〜

　前回は環境設定の優先順位について解説をしました。1つのパラメータしか設定できないような項目では、ユーザ／グループ／コンピュータリストの各レベルで環境設定を行った場合、ユーザレベルでの環境設定が最も優先され、グループレベルの環境設定の優先度が最も低くなります。
　コンピュータリストでは、1台のコンピュータを環境設定が可能な複数のコンピュータリストに重複して登録することはできません。ですので、ある1台のコンピュータに対して適用されるコンピュータリストレベルでの環境設定は1つしか存在しないことになります。
　しかし、グループの場合は事情が異なります。1人のユーザは複数のグループに所属することができます。ここで問題になるのが、複数のグループに所属していたときに、それぞれのグループで環境設定が行われた場合です。
　ユーザが複数のグループに所属していた場合でも、グループレベルの環境設定はどれか1つのグループ分の環境設定しか適用されません。ではどのグループの環境設定が適用されるかですが、このような場合には、ログイン時にログインウインドウにグループの一覧が表示されますので、ここでどのグループのメンバーとしてログインするかを選択します。
　環境設定のルールには「上書き」と「結合」がありましたが、ログイン時にグループを1つだけ選択しますので、いずれの場合でも1つのグループに対する環境設定だけが処理の対象になります。

　これで環境設定に関する基本的なルールの説明が終わりました。この後は、いくつかの環境設定の項目を詳しく解説していきたいと思います。

◇アプリケ−ション
　「アプリケーション」ではユーザが起動できる、あるいは起動できないアプリケーションを設定できます。アプリケーションを指定するには「追加…」ボタンをクリックし、任意のアプリケーションを選択しますが、ここでの設定は、管理対象となる環境に適用される設定であるということをよく覚えておいてください。
　サーバ上で「ワークグループマネージャ」を起動した場合、選択可能なアプリケーションは、サーバ上にインストールされているアプリケーションになります。もしクライアント環境にしかインストールされていないアプリケーションがある場合、これでは選択ができません。
　もちろんサーバ上にもアプリケーションをインストールすれば選択可能になりますが、設定を行うだけであれば必ずしもサーバ上でインストールをおこなう必要はありません。サーバではなくクライアントコンピュータ上で「ワークグループマネージャ」を起動すれば、クライアント上にインストールされたアプリケーションを選択することができます。

・「アプリケーション」の環境設定
http://homepage.mac.com/htabata/MXS10.3/img/WGM_MCX/WGM_MCX_App.png

◇ソフトウェア・アップデート
　Mac OS X Server v10.4では、新機能としてソフトウェア・アップデートのサーバをローカルネットワーク上に構築できるようになりました。この機能を利用すれば、各クライアントコンピュータはアップルが提供するアップデートサーバに直接アクセスしなくても、ローカルネットワーク上のサーバからアップデートをインストールできるようになります。
　ですが、いくらローカルにソフトウェア・アップデートのサーバを設置しても、それだけは各クライアントコンピュータは今までどおりアップルのサーバを参照してしまいます。クライアントコンピュータを特定のアップデートサーバにアクセスさせたい場合は、この環境設定でサーバを指定します。
　ソフトウェア・アップデートはシステム全体に関わる設定ですので、この項目を設定するときはコンピュータリストに対して設定を行うのが効果的でしょう。

・「ソフトウェア・アップデート」の環境設定
http://homepage.mac.com/htabata/MXS10.3/img/WGM_MCX/WGM_MCX_SU.png

◇ネットワーク
　Mac OS X Server v10.4から新たに追加された環境設定の項目です。この項目ではクライアントコンピュータが使用するプロキシサーバを設定することができます。

・「ネットワーク」の環境設定
http://homepage.mac.com/htabata/MXS10.3/img/WGM_MCX/WGM_MCX_Network.png

◇メディアアクセス
　「メディアアクセス」ではセキュリティ上便利な設定を行うことができます。
ここでは、「CD & CD-ROM」「DVD」「記録可能ディスク」それぞれに対するアクセスを制御できます。例えば、「記録可能ディスク」の「許可」を外しておけば、CD-RやDVDへの書き込みを禁止することができます。また「認証が必要」を設定することで、管理者のみにアクセスを許可することもできます。
　さらに「内蔵ディスク」「外部ディスク」についても同様の設定を行うことができます。

・「メディアアクセス」の環境設定
http://homepage.mac.com/htabata/MXS10.3/img/WGM_MCX/WGM_MCX_Media01.png
http://homepage.mac.com/htabata/MXS10.3/img/WGM_MCX/WGM_MCX_Media02.png

　それでは次回は「モバイル環境」について解説します。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　つづく

小池邦人のCarbon視点でCocoa探求（2007/08/03）

〜　XcodeとInterface Builder　〜

今回からは技術的な内容にも踏み込むのですが、なにせ筆者はCocoa初心者です。何か間違いを書いていたら、ぜひメールでMOSA事務局へご連絡くださいませ。また、私の方で疑問点を取り上げることもあるでしょうが、その答えが判明した時には優先して提示したいと思います。「一人の疑問は全員の答え」「一人の間違いは全員の知識」という方針で連載を続けたいと思いますので（笑）ひとつよろしくお願い致します。

今回の開発で用いるXcodeは最新版のv2.4.1です。Leopard（Mac OS X 10.5）にはXcode v3.0が搭載される予定ですが、もうしばらくの間は、このバージョンとの付き合いが続くことになります。また、Cocoaプログラミングモデルでは、Carbon以上にnibファイルが重要な枠割を担います。そのファイルを作成、編集するためのInterface Builderの最新版はv2.5.4となっています。この2つのアプリケーションが、Cocoa Frameworkを用いるアプリケーション開発の「両輪」となります。

ところで、Xcodeの方はちゃんと日本語にローカライズされており、以下のサイトには日本語訳されたユーザーガイドも存在しています。また、日本語訳された関連ドキュメントも幾つか参照することが可能です。

「Xcode 2.3ユーザーガイド」

http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeUserGuide/Contents/Resources/ja.lproj/index.html

「Xcodeを使った作業：将来に対応したアプリケーションの構築」

http://developer.apple.com/jp/tools/xcode/xcodefuture.html

「XcodeへのCodeWarriorプロジェクトの移植に関する概論」

http://developer.apple.com/jp/documentation/DeveloperTools/Conceptual/MovingProjectsToXcode/index.html

ところが「相棒」のInterface Builderの方は未だローカライズされていません。それどころか、英語版の正式ユーザーガイドさえ存在していないのが現状です（ですよね？）。アプリケーションで簡単なヘルプは参照できますが、それを見ながらの操作と言うのはさすがに辛いものがあります。そんな状態ですので「Interface BuilderはApple社内で開発されていないのではないか？」という噂もあるようですが（笑）兎にも角にも、Leopardではこうした状況を改善してもらわないと困ります。

それでは「どうやってInterface Builderの操作を習得すれば良いのか？」という問題になります。Cocoaで開発してみると、Carbonの時とは比べものにならないぐらいInterface Builderに依存した操作や処理が発生することが分かります。そのため、Cocoaでのプログラミングを解説したドキュメントには
「逐次」Interface Builderの操作方法が記述されています。つまり、Interface Builderの操作方法は、Cocoaのプログラミング解説書の方でカバーされているわけです。Apple社も、そうした状況を見越して、InterfaceBuilder自身のドキュメントに関しては手を抜いているのかもしれません…。

さて、まずはXcodeを起動しましょう。ファイルメニューから「新規プロジェクト…」を選択すると、アシスタントから空プロジェクトのテンプレート
（新規雛形）を選ぶことが可能になります。プロジェクトの種類を大きく分類すると、Action、Application、Audio Units、Bundle、Command LineUtility、Dynamic Library、Framework、J2EE、Java、Kernel Extention、Standard Apple Plug-ins、Static Libraryの12種類です。このうち今回の開発は「Application」が対象ですので、全部で13種類のテンプレートの中から目的に合ったものを選択することになります。

テンプレートを選ぶと、ダイアログの下にその目的の解説が表示されるのですが、残念ながらその部分は日本語訳されていません（手抜き）。Carbonなら「Carbon Application」「Carbon C++ Application」「Carbon C++ Standard
Application」の3種類から選択します。Cocoaであれば「Cocoa Application」
と「Cocoa Document-based Application」を含め、全部で7種類の中から選択します。筆者がCarbonアプリケーションを開発している時には「CarbonApplication」を利用していました。C++も使っていないという所がミソでして（笑）CarbonとピュアCから突然CocoaとObjective-Cへ移行するとどうなるのか？アプリケーションのソースコードを比較することで色々と面白いことが判明しそうです。

筆者には両者の区別が分からないのですが、C++に関しては「CarbonC++Application」と「Carbon C++ Standard Application」の2つのテンプレートが用意されています。このテンプレートで作成したプロジェクトファイルを見ると、「Sources」グループ中に「HIFramewrok」というファイル群が登録されていることが分かります。これは、Apple社がよりモダンなCarbonプログラミングモデルを提供するため用意したFrameworkです。具体的には、Carbonに導入されているCarbon EventやHIViewなどの仕組みと、C++（OOP環境）との親和性を高めるために使われています。

現在、クロスプラットフォーム向けにアプリケーションを開発するとすれば、やはりC++と何かしらのFrameworkを使うことになるでしょう。HIFramewrok
も、その一手段として重要な意味を持っていたと思います。ところが、この
HIFramewrokの中で使われているのは、「64bit化しませんよ」と宣言された
Carbon APIがほとんどです。つまり、64Bitアプリケーションの開発では利用できなくなるのです。このように、自ら開発の選択肢を消してしまうのは、何とももったいないような気がするのは筆者だけでしょうか？

さて、Cocoaアプリケーションを開発するプロジェクトテンプレートを選択しましょう。とりあえず、Cocoa-JavaとCore Dataベースのアプリケーション（機会があれば後でチャレンジします）を選択から外すと、残りは「CocoaApplication」と「Cocoa Document-based Application」のどちらかになります。「Cocoa Document-based Application」は、ワープロソフトのようにユーザが作成したドキュメントをファイルに保存するタイプのアプリケーションがターゲットです。もう片方の「Cocoa Application」は、それ以外のタイプということになりますが、せっかくなので、今回は両方のプロジェクトを作成して比較してみたいと思います。

アシスタントから目的プロジェクトを選び、「次へ」ボタンをクリックしてプロジェクト名を入力して「完了」ボタンを押します。これで指定したディレクトリにプロジェクト名が付いたフォルダが作成され、その中に開発で必要な「材料一式」（ソースファイルやnibファイルなど）が保存されます。プロジェクト名は、幾つかのファイル名やアプリケーション名に使われますので（後から変更可能）、最初から適切な名称を選んでおいた方が良いでしょう。また、プロジェクト名は日本語でもかまいません。

次回は、今回作成した「Cocoa Application」と「Cocoa Document-based
Application」のプロジェクトフォルダの中身を、Carbonプロジェクトの場合と比較しながら調べてみることにします。
つづく
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

ターミナルの向こうから　　　　　　第7回　　海上 忍

〜 MacでLaTeXを使うメリットとは・LaTeX編その1 〜

　大学や研究機関にユーザが多いLaTeXですが、筆者はプログラマにもその便利さを知ってほしいと考えています。ようやくここまで辿り着きました、LaTeX編の第1回です。

・人は何故LaTeXを使うのか
　文書をつくるとき、ベースとする”ひな型”があれば便利なことは、誰しも理解できるはず。顧客に送る案内状にしても、拝啓から始まり時候の挨拶、要件を記述したあと敬具で締める、という流れを毎回繰り返すのは効率的ではありません。顧客の名前や日付を変えるだけで使い回しできることこそ、コンピュータによる文章作成の利点といえるでしょう。

　そのような作業にもってこいの文章作成環境が、今回紹介する「LaTeX」です。著書The Art of Computer Programmingでも知られるDonald E. Knuth博士が開発した組版処理ソフト「TeX」を利用した、いわばマクロプログラム集ですが、商業出版に利用される（筆者も数冊ほどLaTeXで組版した本を出した経験があります）ほど高品質です。TeXネイティブの命令（通称プリミティブ）より理解しやすく、機能の拡張など管理が容易という理由でも、LaTeXが好まれています。

　LaTeXは、いわゆるマークアップ言語の一種で、2つのタグの間にテキストなどのコンテンツを配置して文書をつくりあげることが基本です。HTMLの直書きをイメージすると、わかりやすいかもしれません。WYSIWYGの対極にある文章作成スタイルですが、体裁はプレインテキストであり、ソフトのバージョンアップに動じることはありません。Perlなどテキストの扱いに長けたスクリプト言語を利用し、宛名印刷に活用することも可能です。実際、筆者は長年LaTeX + Perlで年賀状の宛名印刷を行っています。

・LaTeXのサンプルを見る
　では、なぜLaTeXは一般ユーザのレベルに浸透していないのでしょう? 答えは単純、いわゆるワープロソフトのようなインターフェイスを持たないからです。しかし以下のサンプルをご覧いただければ、その便利さの片鱗を理解していただけることと思います。

　かんたんに内容を説明してみましょう。まず、\begin{document}と\end
{document}に注目してください。この2つのタグで囲まれた範囲が「本文」で、ここに文書のコンテンツを記述します。\begin{ }〜\end{ }のセットは「環境」と呼ばれ、図版を表示するpicture環境、文を中央揃えにするcenter環境など、覚えきれないほどの環境がLaTeXには用意されています。以下のサンプルでは、4行目から10行目が本文(document環境)となります。

　6行目では、\title命令を実行し、文章のタイトル（MOSA伝）を設定しています。7行目の\date命令は、日付を出力します。どちらも文書を装飾するための命令で、\maketitle命令が記述された位置（通常は先頭ページ）に出力されます。環境と同様、LaTeXには多くの命令が用意されています。

　document環境に含まれない1行目から2行目は、「プリアンブル」と呼ばれる文書のお膳立てを行うエリアです。1行目では文書クラス（横/縦組、用紙サイズで分類）を指定し、2行目ではマクロパッケージのascmac（サンプルではダミーで使用しています）を読み込んでいるわけですが、イメージとしてはObjective-Cでいうところの「#import 〜」と同じです。LaTeXには膨大な数のマクロパッケージが用意されていますし、同様の方法でひな型（スタイルファイル）を呼び出すこともできます。

　そろそろお気づきかもしれませんが、TeX/LaTeXでは命令が「\」から開始されます。{ や }は特殊文字と呼ばれ、\と同様にそのままでは出力できません。ほかにも、連続するスペースは1つとして扱われるとか、改行文字とスペースだけの行は段落の終わりを意味するとか、約束事はたくさんあります。それこそ書籍が数冊書けてしまうほどの情報量がありますので、興味があれば入門書の購入をお勧めします。

- - - - -
1: \documentclass{jarticle}
2: \usepackage{ascmac}
3:
4: \begin{document}
5:
6: \title{MOSA伝}
7: \date{2007年8月14日}
8: \maketitle
9:
10: \end{document}
- - - - -

・LaTeXの導入
　LaTeXの文書処理系は、TeX/LaTeXの実行ファイルのほか、各種フォントやLaTeXのマクロなど多数のファイルで構成されます。ソースコードはすべて公開されているので、UNIX系OS向けの配布用パッケージ「TeTeX」にASCIIが提供する日本語化パッチ「pTeX」を当ててコンパイル、といった手順でインストールしますが、有志が作成したバイナリパッケージを利用させていただくほうがいいでしょう。

　ここでは、熊本学園大学の小川弘和氏が配布中のパッケージを紹介します。以下のURLにアクセスし、pTeX(sjis) + JMacoros package for MacOSX（ppc/intel）の項目から約180MBのディスクイメージをダウンロードしてください。インストールはかんたん、ディスクイメージをマウントすると現れるパッケージ（big-ptex.pkg）を開き、インストーラで処理するだけです。パッケージに含まれるコマンド群は/usr/local/binにコピーされるので、連載第3回で解説したパスの設定が完了していれば、作業は完了です。

http://www2.kumagaku.ac.jp/teacher/herogw/

　次回は、Carbon Emacs上でyatexを使うなど、”LaTeXの敷居”を下げるための情報を紹介する予定です。

◇MOSAからのお知らせと編集後記は割愛します◇