さて、Emacs を使った構造化文書の編集技法の基本については大丈夫としても、まださらに学ぶべきことが沢山あります。ここからは文章編集を楽にするいくつかの巧妙なトリックやこつについて見ていきましょう。 ワープロよりテキスト処理が優れている主要な利点の一つに、ファイルを分割して好きなように作業を体系化できるということがあげられます。実際にはプログラムによって文書をより柔軟に体系化することができます。 実体(Entity)は文書の先頭の文書型 (DOCTYPE) 宣言内で宣言しなければなりません。そして典型的な実体宣言は次のようになります: <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN" [ <!ENTITY presDeLaCompania SYSTEM "presDeLaCompania.sgml"> ]> この例を見ればわかるように、実体は四角括弧 [] 内で宣言します。また実体へのシステム識別子があるので、パーザが文書を処理する際にそのファイルをみつけることができるということもわかるでしょう。実体名はこの文書の中で実体を識別し、好きなように名前を付けることができます。 アンパサンド & と実体名を次のように指定するだけでいつでもこの実体を使うことができます: &presDeLaCompania; 実体を連携させているときに実体内に文書型(DOCTYPE)宣言を含めることはできません。そうすると Emacs がこの文書をどうやって検証するか知ることができなくなってしまいます。しかしこれについては打開する方法をみつけたので以下で説明します。 この節で後で見るように Emacs/PSGML は妥当な文書を書くのを手助けするだけでなく、思いがけなく手動で(例えばカットアンドペーストで)節を 含めたとしても、必要に応じて妥当性を検証することができます。それでは構造化文書の編集作業を手助けするような(PSGML に加えて)他の Emacs の標準機能についても見ていきましょう。 あなたはいつでもC-c C-vと打ってミニバッファ内にnsgmlsコマンド行を表示し、ただEnterを押すだけで文書の妥当性を検証できます。もし何らかのエラーがあれば下の画面のようにプロンプトが表示されます: 文書の検証 そしてすぐわかるように、エラーの一つをクリックしEnterを押すと直接エラー個所にジャンプします。もしそれが異なるファイルであっても、Emacs はそのファイルを開き、エラー個所にカーソルを移動します! これは Emacs の標準機能であり、システムの他のツールと統合されています。gdb、make、java コンパイラなどで同じように使うことができます。 文書の部分(SGML では 実体 と呼ばれます)にまつわる主な問題は、その中に DOCTYPE 宣言行を含めることが できないということです。このために Emacs がどこの DTD を見に行けばよいのか知ることができません。[これを解決するために]私が やったことは次のとおりです。 DOCTYPE 宣言行を持つ主文書を開き、DTD->Save Parsed DTD[パーズ済みの DTD を保存]メニューを クリックします。そのファイルに docbook.ced あるいは main.cedといった簡単な 名前を付け、通常主ファイルと同じディレクトリ内に保存しておきます。 文書の部分を開くと、Example entity XXXXX not found (XXXXX は最初のタグがみつかる場所)というようなエラーメッセージが表示されるでしょう。これを無視し、単に C-x 1を押して作業フレームを最大化します。そしてメニューから DTD->Load Parsed DTD を選択し、この filename.ced を前のステップで付けたファイル名で置き換えてやります。 この通り! 主文書と同じようにして文書の部分でも作業することができます。 字下げと調整 PSGML メジャーモードは他の多くの Emacs メジャーモードと同じように適切な字下げを保つように手助けしてくれます。 私が見てきたエディタとは違い、タブキーは Emacs では実に知的なものとなっています。一つ例を あげると、テキストのどこでもこのキーを叩くと、他のエディタのようにテキストの間に空白を入れてしまうテキストモード とはならず、適切にその行を字下げしてくれます。 さて Sect2 を Sect1 にすると決め、正しくこの節を字下げしたいとしましょう。次のようにします: その領域を選択し(C-space でその節のブロックがアクティブになります)、 タグを置き換えます。もしその領域にいないなら外側のタグを検索し、置き換えることからはじめます。 その領域内にいても同様です。 タグに正しい名前をつけると、 Emacs は自動的にその領域を字下げすることができるはずです。 ただその領域を選択し、M-x indent-regionを押すだけで終り! これはさらにはスタイルとコード可読性の問題となります。私は個人的にはタグがあってその後に CDATA(文字データ)があるよりもタグの間に挟まれている方が好みです。段落は完璧な例です: <para> This is more a question of style and code readability. I personally prefer to have <emphasis>CDATA</emphasis> (character data) between the tags rather than having the tags at the beginning and end of the CDATA. Paragraphs are perfect examples: </para> 対 <para>This is more a question of style and code readability. I personally prefer to have <emphasis>CDATA</emphasis> (character data) between the tags rather than having the tags at the beginning and end of the CDATA. Paragraphs are perfect examples:</para> こうすると、Emacs はこれを理解し、CDATA とタグを適切に調整した状態に正しく保つようにします。CDTADA については Emacs はその領域での最初の行の字下げに従います。つまり、それを最初に字下げすると残りの行はそのスタイルに従うようになります。 私が Emacs でみつけた一つの興味深い特長は段落埋め、もしくは段落調整(ほとんどの人にはこちらの方がずっと親しみやすい用語でしょう)です。 調整は自動的に(マイナーモードとして)、あるいは手動でM-q 打鍵でいつでも行うことができます。調整マイナーモードでは テキストは自動的に埋められ、字下げされメジャーモードのルールに従って折り返しがなされるので、あなたがしなければならないのは入力することだけ です。調整マイナーモードにするには単にM-x auto-fill-modeと入力します。 また、領域を選択しM-x fill-region と入力して調整することもできます。 Emacs がその下の OS とツールを滑らかに統合しているのと同じ方法で、ispell と spell が完璧に統合されています。 これは ispell メジャーモードを有効にすることで ad-hoc になされるか、あるいはマイナーモードとして動作させられます。 これは MS-Word の赤線に似ていて、文書全体の綴りを検査します。次はいくつかのチップスです: 文書の綴りを検査するには単に M-x ispell と入力します。 辞書を変えるには M-x ispell-change-dictionary と入力します (利用可能な辞書については /usr/lib/ispell を参照して下さい)。 ispell マイナーモードを有効にするには単に M-x ispell-minor-mode とします。 綴りの間違っている語句に赤い下線を引くようにしたければ、M-x flyspell-mode とします。 ispell マイナーモードを有効にしていてビープ音が鳴ったら、それは語句の綴りを間違っているということを意味します。 これを修正するにはすぐに入力をやめ M-$ とするとちょうど ispell メジャーモードのように画面の上部に オプションが表示されます。 ispell メジャーモードの例 SGML 自体は任意の他の形式に手際良く変換できるけれども、実際に異なる媒体で配布するつもりなら考慮に入れなくてはならない いくつかの注意点があります。例えば、保守したい文書を Postscript と HTML の両方で配布するとしましょう。もし文書に画像が 含まれていなければ大きな問題はありません。しかし、もし画像があると、二つのこと - 双方の媒体に対する画像の大きさとファイル形式 - を考慮に入れる必要があります。800x600 のスクリーンショットはおそらく HTML なら完璧に表示されますが、A4 サイズの PDF では 見栄えが良くありません。また PNG は Postscript ファイルの中で直接表示させることはできませんし、EPS 画像を HTML ファイル内で 表示させることもできません。 おそらく SGML でもこれをプリプロセッサのようにしてやってしまう方法があるでしょうから、もしみつけたら この文書を更新することにします。しかしここでは私のみつけたこの仕事を十分よくなしとげる簡単な方法をあげておきます: すべての画像を保存する graphicサブディレクトリをつくります。このディレクトリ内に それぞれの媒体形式に対するサブディレクトリをつくります。私の場合は Gimp を使い主に PS と HTML で配布しているので、 三つのサブディレクトリ(XCF、EPS、PNF)をつくっています。 画像をつくったら各々のサブディレクトリに異なるファイル形式で保存しておきます。XCF と EPS では 拡張子をつけておきますが、PNG にはつけません(つまり私の PNG ファイルには拡張子がありません)。 文書内ではファイルの種類を指定してはいけません、というのは逐語的に解釈する HTML への変換を 除けば、各々の変換ルーティンは異なる拡張子を期待しているからです。こういうわけで前述のように PNG ファイルには .png 拡張子をつけないようにといったわけです。ブラウザはファイルの種類を何とか判別することができます。次はスクリーンショットの 例です: 変換する前に正しいファイルが graphicディレクトリ内に存在していることを確かめておいて下さい。 PS 変換では .eps 拡張子を持つファイルを期待するので、文書内で画像の種類を指定する必要はありません。 HTML 変換では画像ファイルは新規作成ディレクトリに複製されません。手動でそれらを複製し、画像ディレクトリをつくらなければ なりません。PNG ファイルには拡張子がないので、HTML の中の IMG パラメータには理想的なパスと SGML から受けついだファイル名が 入ることになります。 SGML ではすべての要素がユーザー定義の ID を持つことができます。この ID で異なる目的、媒体出力にでもこの要素を 参照することができます。HTML や他のハイパーリンク可能な媒体で配布しようとしているなら、文書の異なる節へのハイパーリンク させるのにとても便利です。これらリンクについては Docbook ではいくつかの異なる方法で定義されていますが、そのいくつかの 興味深いものをここであげてみます。 私は XRef がとても多芸多才で、紙の出力(PostScript)でも HTML 出力でも同様に機能することをみつけました (さらに HTML ではハイパーリンクも付け加えられます)。 XRef を使うには最初に link-end ノード(指し示すノード)を指定しなければなりません。それにはただその指定したい 要素の開始タグに移動し、C-c +とし、パラメータ IDを選択し、名前を付けます: <sect1 id="wpf"> <title>The Word Processing Fantasy</title> この要素(この場合は節)を参照したいと思ったらいつでもただ次のようなタグを使うだけで良いのです: which where listed in <xref linkend="wpf">. URL の宣言は非常に簡単で、単に ULink 要素を次の例のようにして使うだけです: ここでは私が Emacs と PSGML モジュールの利用を通して発見した他の巧妙なテクニックについてふれてみようと思います。この節はおそらく 時間とともに内容が増えていくはずですので引き続き注意していて下さい... この節はもっと良いタイトルをみつけられなかったのでこれで我慢して下さい。文書を校正していて何かを強調したいとします。 C-c C-eではじめたものの終了タグは期待していなかったとします。この場合使うべきなのは C-< であり、開始タグを選択でき、終了タグは生成しません。開いているタグを閉じたければ、ただ C-/と入力するだけでよく、こうすると自動的に適切な終了タグを得ることができます! Docbook や HTML を書いているとタグは非常に様々な異なるパラメータを持っていて覚えるのも既定値を使うのも難しいということが わかるでしょう。このような場合、開始タグのどこでもカーソルを合わせて単に C-c +とします。するとパラメータ リストが表示され、異なるパラメータと(定義済みならば)すべての可能で正当な値を示してくれます。この機能は実に素晴しく、 すべてのマークアップ編集に不可欠であるとわかります。つまり、ほとんどのものについては自動補完から推測できるので Docbook あるいは HTML のリファレンスは必要ないということです。もちろんこれは使っているマークアップの標準について学ばなくても 良いという言い訳にはなりませんが、しかし、単にこれらを覚えておくためのリファレンスの必要性をなくしてくれます。 GNU Emacs マニュアル。私は FSF の印刷されたマニュアルを買い、それが非常に完成度が高く、一般に信じられているのとは 違って、とても簡単で読むのが楽しいということを発見しました。FSF 版とは違ったアプローチの O'Reily の GNU Emacs 本も 持っていますが、こちらもとても好きです。 Debian の linuxdoc-tools パッケージについてきた LinuxDoc-Tools ユーザーガイド。これは SGML とそしてもちろん linuxdoc の非常に優れたガイドです。 Docbook DTD のガイド。これはほとんどの Linux ディストリビューションでは通常は /usr/share/doc/ にインストールされます。もちろんこれには Docbook 文書を インストールしなければなりません。また Docbook の本は沢山ありますが、中でも特に O'Reily の非常に優れた本は GPL です! これは O'Reily の本の中で唯一の GPL なものだと思います。 PSGML メジャーモードをインストールするとついてくるガイド。大抵のものと同様に通常は /usr/share/doc/psgml にインストールされます。このガイドはあなたが知りたいであろう残りの PSGML の技について教えてくれることでしょう。 http://www.tldp.org/HOWTO/DocBook-Demystification-HOWTO/ http://www-106.ibm.com/developerworks/xml/library/x-emacs/#1