nDiki : LaTeX

2004年4月2日 (金)

過去の今ごろ

過去の4月2日より。

  • doxygen で RTF
    • 最近のバージョンでは LaTeX 出力されたものはきちんと日本語も通る。Makefile もいい感じに作ってくれる。
[ 4月2日全て ]

2004年10月4日 (月)

仕事のファイルを順次 Subversion リポジトリに突っ込む

1本長めの文書を作ることになったので、(ドラフトを含む)版管理もかねて Subversion のリポジトリに突っ込む事にする。

階層

以前は

 project -> trunk -> subproject

という階層にしていたのだが、プロジェクトをまたがるタグ打ちとかに向いていないので今回は

 trunk -> project -> subproject

という感じに。

LaTeX

texmf に関してはSubversionの外部定義機能の利用をやめ、Makefile で TEXINPUTS を相対指定するように。 それでも別の階層にある texmf 下の共通画像を includegraphics する場合は '../../texmf/logo.png' などとしないといけないのがちょっと気持ち悪い。

タグ打ちは

タグ打ちはどうしようかな。みんなは trunk 以下をごっそり、branches の下にコピーしているのだろうか。 trunk の中の特定プロジェクトディレクトリ + 共通ディレクトリのみをコピーするという手もあるかもしれないけど、それはそれで繁雑だしな。

svn.sty

rcs.sty でいけるかなと思っていたのだが、Subversion だと

  • $Date$ のフォーマットが違う
  • $Revision$ がなぜかうまく展開されない ($LastChangedRevision$ の方はOK。Date の方は LastChangedDate で無くても別名が効くのに)

という問題が。探したら svn.sty という rcs.sty 亜種があったのでこちらを入れて解決。

ついでに

過去のドキュメントとかも順次。

[ 10月4日全て ]

2004年10月16日 (土)

Template Toolkit のテンプレート上で対話的入力

ちょっとしたプログラムパッケージや LaTeX ドキュメントを作成する時に、Makefile やその他ファイルのスケルトンをまとめて生成する算段を検討中。 例えば Perlh2xs のような感じ。

基本的には Template Toolkit ベースでいってみたい。 ttree あたりを使えばだいたいできそうだ。 ここで --define var=value で全て間違えずに指定するのは大変になってくるだろう。 ということでテンプレート変数定義をまとめたテンプレートファイルを作成し、各テンプレート処理をする際にプリプロセスするようにする。

でこのテンプレート変数定義のテンプレートファイルは対話的に作成できるようにしたい。 テンプレートファイルのテンプレートファイルを処理して。

で対話的入力の方法なのだが、探してもそのようなディレクティブもプラグインもみつからない。ありそうなもんだけどなぁ。

しょうがないので、PERL ディレクィブ内で Term::ReadLineを使って入力。 こんな感じ。

 [% TAGS [- -] -%]
 [- PERL -]
 use Term::ReadLine;
 my $term = new Term::ReadLine('template');
 $stash->set('readline' => sub {
   my $prompt = shift || 'input:';
   my $text = $term->readline($prompt);
   if (defined $text) {
     $term->addhistory($text);
   }
   return $text;
 });
 [- END --]
 [% project.name = '[- readline('project name:') -]' -%]
 [% project.author = '[- readline('author:') -]' -%]

tpage でこのテンプレートファイルを処理すると、対話的に値を入力しながらテンプレートファイルを生成できる。 実際は文字列のエスケープなどもうちょっと工夫が必要。

ちなみに Debian GNU/Linux sid の libtemplate-perl は 2.10-1 で、このバージョンの Template Toolkittpage だと EVAL_PERL が有効になっておらずうまく動かない。 手元にコピーして Template オブジェクトの初期化部分に EVAL_PERL => 1 を追加する必要あり (2.14 の tpage は --eval_perl オプションで有効にできる)。

[ 10月16日全て ]

2005年4月20日 (水)

SConsGNU Autotools のかわりになるか

NSIS のサイトによるとビルドに「SCons」を使うようしたらしい。

  • クロスプラットフォーム
  • AutoconfAutomake と同様の機能を統合
  • LaTeX もビルトインサポート

と興味深いツールになっているようだ。

現在プロジェクトLaTeXベースのドキュメント生成には GNU Make を使っているのだが、UNIXWindows の両方でビルドできるようにするには ComSpec 環境変数の有無で使用するコマンドを切り換えたり等いろいろ面倒なので、代替ツールとして使えないかなと。

基本的な機能は Make に対する改良がなされているようであるし、コピー等ファイル操作も SCons 自体がもっているのでクロスプラットフォームでビルドできるようにするのも楽そうだ。

一方 Autoconf 系の機能については、インストール済みのライブラリの検出や実装レベルのチェック等を実装しているようである。 make check や make dist、make install 等にあたるターゲットに関する機能(あるいは規約)のようなものは無い。これは非常に残念。 結局自分が Ant を使わなくなったのも GNU Autotools にあるこれらの機能に欠けているからであるし。

実は私がPerl が好きな理由の一つとして、これらサポートが充実しているという点がある。Perl では ExtUtils::MakeMaker (あるいは Module::Build)があり、ビルドからテスト、ソースパッケージのパッケージングまでフレームワークが整っている。

SConsPython ベースで、Makefile にあたるファイルも Python スクリプトである。 SCons が影響を受けた Cons は Perl ベースであったのだが、既に2001年5月ごろから開発が止まってしまっている。残念。

ということで Make の代替には使えそうであるが、GNU Autotools と同じようなことをするにはいろいろ手をかけないといけないといった印象。

[ 4月20日全て ]

2005年6月21日 (火)

LaTeXプレゼンテーション

提案資料の作成作業。 今後の事も考えて、自分流プレゼンテーション資料のつくり方を用意したい。

  • ソース
    • ソースは LaTeX で。
    • スライドショーと、配布資料は同一ソースから生成したい。
  • スライドショー
    • ダイナミックなスライドはほとんど作らない。
    • LaTeX からだと、やっぱり PDF + Adobe Redear か。全画面表示可能だし、簡単な動きも表現できるから機能的には問題なさそう。Linux でも動くし。
  • 配布資料
    • 配布資料はPDF化。
    • 配布資料は PowerPoint みたいにスライドショーそのままの紙芝居になるのではなくて、追加の説明文が加えられたA4縦のレポートになるようにしたい。PowerPoint で作った紙芝居の配布ってなんか安っぽい感じがする。

TeXPower

最初にチェックしたパッケージ。 文書クラスとして powersem というのが含まれているけれど、ちょっと地味らしい。 もともと動的な表現をするための texpower パッケージが中核で、レイアウト関連は他のプレゼンテーション用文書クラス(FoilTeX など)に頼ることになりそうだ。

使うかどうか保留。

Prosper

PowerPoint ライクなスタイル(テンプレート)があり、比較的簡単に見栄えのするスライドが作れる。 ただし dvipdfmxでは PDF化できない。 dvips + ps2pdf などで PDF 化する必要がある。

まずはこれで、ちょこちょこと作ってみる。dvips + ps2pdf だと、PDF しおりの文字化け対策やフォントまわりの設定など dvipdfmx とは違ってくるので面倒だな。

さらに PNG画像を貼りつけるところではたと困る。dvipdfmx じゃないから、簡単に貼れない。 困った。

スクリーンキャプチャを簡単に貼りつけられないと面倒だ。

今回は普通に jsarticle?

たぶん今回はプリントアウトを配ってテーブルを囲む形ですすめるんじゃないかと思うので、jsarticle で普通にレポートにしてしまうかなぁ。 あまり時間がとれないし。

使い勝手を考えると Prosper ではなく、やはり dvipdfmx が使えるスライド系の文書クラスで作っていく方がよいか。

配布資料の方は? DocStrip あたりを使って自分で生成しわける方が簡単か?

[ 6月21日全て ]

2005年11月21日 (月)

定型書式で内容を記述していくのに便利な形式は?

要求仕様書LaTeX で書いている。 要求と仕様の組をまとめて longtable で記述しているのだが、 LaTeX らしい繁雑さがあってちょっと効率が悪い。 マクロを定義すればある程度書きやすくなると思うが、それでもそこそこまでな気がする。

文書の中にレコードの並びが書けて、レコードの並びの中に文章が書きやすいそんなフォーマットはないものかなぁ。

  • LaTeX + マクロ
    • 整形は綺麗。
    • 記述が繁雑になりがち。\マクロ名とか {} とか。
  • DocBook
    • 仕様デカスギ
    • 以前使ってみたことがあるが、手で書くのにはしんどい。
  • XML
    • 構造的な情報の表現には良いのだが、手で書くのはしんどい。開きタグも閉じタグも。
    • 普通の章節や、マークアップのルールを考えなければならない(定義するか借りてくるか)。
    • LaTeX等へのコンバータを書く必要あり。
  • YAML
    • レコードの並びだけだったら良いが、文書の他の要素を一緒に書くのには適さない。
    • ある程度の構造やボリュームがあると、思ったほど手書きしやすくない。
    • YAML Perl モジュールで痛い目にあっている。

Wiki に慣れきっている自分にとっては Wiki 文法のような感じで記述できて、一部に定型レコードの並びが書けて、そこの整形ルールだけ定義してあげれば LaTeX に変換できるとかそういった感じがのものが欲しい。 定型レコードの部分は RFC822 のヘッダみたいな感じで良くで、値の部分に長めの文章を複数行で書けるものがいい。

構造化テキスト用フォーマット、あるいはWiki フォーマットをアレンジするのがいいかもしれないな。 このあたりのフォーマットは、ソーステキストのままでも十分読み易いことを意識して定義されているので書くのは楽。

  • reStructuredText
    • いいらしい。
    • HTMLLaTeXXML へのコンバータがある。
    • 拡張性も考慮されているらしい。
    • でも Python
  • Markdown
  • WiKicker (Wiki)
    • かなり書き慣れている。
    • レコードの並びの書き方を考える必要あり。
    • 複数行にまたがる処理を書くのが面倒。
    • 自分で書いているシステムなので中身は何でも知っている。
    • マイナー。

レコード部分とは関係ないけれど reStructuredTextMarkdown の「アンダーラインのあるテキストを見出しとする」っていうのはいいな。 普段メールプレーンテキストでちょっと文書を打つときに使っているスタイルと一緒だ。

要求仕様書用に使うかどうかは別として、要チェック。

[ 11月21日全て ]

2005年11月22日 (火)

reStructuredText いいんじゃない?

昨日の続きであるが、reStructuredText がライトなドキュメント書きにはいいんじゃないかという感蝕を得た。

基本的にプレーンテキストのままで十分見られるので、そのままメールに貼りつけられる。

今までは文書を作成する際、メールで草稿をやりとりしたのち内容が固まったら LaTeX のコマンドでマークアップしてコンパイルしてPDF化していた。 これだとちょっと手間であるのだが、最初から reStructuredText 形式で書いていれば、そのまま rst2latex で LaTeX に落とせる。

また必要に応じて rst2html で HTMLに変換してWebサイトに置いておくこともできる。

これらで満足できない場合は Python のコードをいじって変更ということになるが、Python が駄目でも rst2xml でXMLに変換してしまえば他の言語でも reStructuredText のパーサを書かなくても(XMLの処理系を使って)コンバータを書くことができるの比較的楽である。

しかも欲しかったレコードの表現用にフィールドリストというシンタックスがあるではないか。

いいじゃん。

ということで早速今日から使うことにした。

Debian GNU/Linux sid にある Docutils 0.3.9 ではいわゆる全角文字も文字幅を1として扱かう。 このためテーブルなど桁揃えを用いる書式の部分がこのままだと不便である。 画面上では2文字分幅があっても1文字として数えられるため Docutils が通るようにするためには余計な空白などを入れて文字数を調整しなければならないが、そうすると今度は見た目的にずれるので可読性がかなり落ちてしまう。

この問題のためにMatsumoto,Tadashi氏がパッチ

を作成されているので、これを適用。

これでばっちり。

[ 11月22日全て ]

2005年11月24日 (木)

早速 reStructuredText から LaTeX へのコンバータを書く

要求仕様書を書くのに reStructuredText を使ってみることにしる。 reStructuredText文法の上で、あるルールに従って書いた特定のセクションやフィールドリストを要求レコードや要求仕様レコードとし、自前でコンバータを書いて LaTeX へ変換する形。

まずは最初のアイデア通り rst2xml で XML に変換してから、Perl スクリプトで読み込んで処理することにする。

Perl 側の処理は XML::LibXML で (何となく XML::DOM より好き)。 しかし毎度ながら DOM 面倒くさい。 とりあえず、今必要な要素のみ変換コードを書く。 reStructuredTextXML へ変換した時の DTD があるので、おいおいこれを見ながらきちんと埋めていかねば。

最低限のものができて、早速コンバート。

これで生 LaTeX で書くより随分楽になった。よし。

[ 11月24日全て ]

2005年12月1日 (木)

Docutils は自分にとっての Python キラーアプリかも

先日 reStructuredText ベースの要求仕様書ファイルから、LaTeX への変換プログラムを Perl で作成した。rst2xml で変換した XML 文書経由で。

欲しいところだけまずは実装して使ったんだけれど、この先使っていくには細かいところを組んでいく必要がある。やっぱりフルスクラッチするのは面倒だな。

本来は Docutils 用の Writer を作成するのが王道。

しかし Python なんだよね。以前に何度か覚えておこうと思ったんだけれど動機付けが弱かったのかいつも途中でフェードアウト。 しかし今回は明確な目的があるので、もりもりやりそう。

まずは既存の docutils.writers.latex2e.py あたりをコピーしていじって遊んでみるかな。 自分の場合この方法が一番覚えるのが早い。 小学生の時に最初にBASICをいじった時も、既存のゲームのパラメータとか改造から入ったし。

さて、その latex2e.py であるが「documentclass がオプションや設定ファイルで変更できるものの、標準の LaTeX2e 用のもののどれかしか駄目」だったりなど、普通に使うにもちょっといじる必要がありそう(jsbook とか使いたいし)。

一旦自分好みの LaTeX2e Writer を作ってから、それを拡張する形で特定文書毎の Writer を作るのがよさそうだ。

[ 12月1日全て ]

2005年12月7日 (水)

DocutilsreStructuredText から LaTeX への Writer は継承しづらい

この間やっつけでPerl で コンバータをちょっと書いたのだが、やはりここは正攻法で Docutils の Writer として書いておきたい。

Docutils に含まれている LaTeX2e Writer (docutils.writers.latex2e) のクラスを継承してカスタマイズ版を作ればいいかなと着手。 この Writer の生成する TeX ファイルがちょっと好みではないので、継承して自分好みの Writer を書いた上で、それを継承してドメイン毎の Writer を書く事にする。

Python でコードを書いたことはほとんどないのだがそれほど迷う点はない。 素直な言語なのかな。$ とか @ が出てこないのはちょっと寂しい。ブロックをインデントで示すので「閉じ」がなく、ちょっと「スースー」する。 わかる? この気持ち。

Docutils はパースした結果 DOM ライクなツリーができて、これに対して visit / depart 式の visitor を使って処理をしていけるようになっている。 そのあたりはフレームワークがあるし、典型的なパターンなので楽ではある。

ただし、docutils.writers.latex2e のクラスが継承されることを意識されている感じがしないので、メソッドをコピーして書き換えてオーバーライドといった事が必要になる箇所が思ったよりあるのがちょっと気になる。 今後バージョンアップした時に内部も変わる可能性があるだろうし、最終的にはごっそり Writer を作ってしまう方が良さそうだ。

[ 12月7日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.080494s / load averages: 1.78, 1.45, 1.76
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker