トップ(最新)

nDiki : Docutils

Docutils

Python で書かれたオープンソースのテキスト処理システム。

関連情報

スポンサード リンク

Related term

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年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日全て ]

2006年2月7日 (火)

Docutils 0.4 の日本語文字対応はまだまだ駄目 このエントリーを含むはてなブックマーク

reStructuredText 形式の parse が失敗するようになったと思ったら、Docutils のパッケージが upstream の 0.4 に追従してバージョンが上がっていた。

Release Notes に

Added Japanese and Simplified Chinese language mappings, and support for double-width CJK-characters in tables and section titles.

とあって期待したのだが、試してみたところまだまだ駄目っぽい。

0.3.9 に戻して 以前入れた時と同様 patch をあて、元の環境に戻す。

今後に期待。


[ 2月7日全て ]

2006年2月15日 (水)

ドキュメンテーション大全 このエントリーを含むはてなブックマーク

開発の現場 Vol.003 効率UP&スキルUP ドキュメンテーション大全

プロジェクトの後半で納品用ドキュメントの整備を始めるのだが、その時はたいがいもう切羽詰りはじめていて構成やら体裁やらマネジメントやらを工夫する余力が無かったりする。 ついつい(次回は改良しようと思っていつも思っている)前回のプロジェクトの手法を踏襲してしまいがちだ。 ともすれば劣化コピーになりかねない。

やはり、忙しくても日頃からの改善は重要である。

最近はアジェンダ議事録開発メモなどを、積極的に WikiSubversion で共有するようにし、その点では以前より改善してきている。

今後はさらに、出荷ドキュメントのレビュープロセスなどを確立し品質を高めていきたいところである。 現状でもチームメンバでのピアデスクチェックやパスアランドを非形式的に行っているのだが、「チェックの程度」やその後の「修正」および「修正の確認」については、まだなんとなくやったかなという具合。この辺りを工夫したい。

先月発売されていて気になっていた「開発現場 Vol.003」に、何かヒントがあるかなと思って買ってみた。

パラパラと見た感じではテクニカルライティングの話はあまりなく、主にソフトウェア開発における中間成果物としてのドキュメントや開発者間ドキュメントをどうとりまとめていくかという話が中心のよう。 Wiki による開発資料のライトな共有など、うちのチームでも進めている話など。

「(最初から)完全なドキュメントを書こうとしない」というのはもっとも。 状況はほとんどの場合変わるし、最初の段階では未確定の部分も多い。 だからといって、いつまでたっても手元で温めていてもしょうがない。

技術的な話では PerlPod を活用しようという話。 Perl 以外の言語のコメント中に Pod 形式でドキュメントを書こうという提案や、Apache で動的に Pod ドキュメントを整形しようという話とか。

テキストフォーマットとしての Pod は =over / =item / =back によるリスト表現など、最近のフォーマットに比べてすごく読み易いわけではないが、たしかに他の言語のコメントに埋め込んでおいて処理するのは、標準の Pod 関連のモジュールでできるな。

自分も Pod でドキュメントを書くけれど、(Perl 以外は) 個人的には reStructuredText にしたいと考えている。 ただ Pod みたいに他のテキストの一部に埋め込んでその部分のみ処理する記法およびツールがが標準の reStructuredText / Docutils には見当らない。 実はどっかにあるのだろうか。


[ 書評 ]


[ 2月15日全て ]

2006年3月8日 (水)

Mule-UCS の設定 このエントリーを含むはてなブックマーク

reStructuredText では表を作る時は文字数で桁揃えして、表セルを表現していく。 ASCII 文字などフォント幅がいわゆる半角幅であるものだけならば、良いのだが全角幅の文字がある場合はちょっと厄介である。

文字数的には1文字なのだが、プレーンテキストファイル上では2文字分の幅を取るので見た目上桁が揃わなくなってしまう。 というかそれを忘れて桁を揃えておくと、パーサに怒られる。

このためにパッチがあったり、Docutil 0.4 ではこの対策がほどこされたりしている(不完全であるが)。

さらに厄介なのが Unicode 変換がからむところで、 Emacs + Mule-UCS ではいくつかの(いわゆる)全角文字は UTF-8 で保存すると違う文字に変換されてしまい、これまた Docutils のパーサに、桁があっていないと怒られることになる。

できるだけ全角文字はそのままにしておくということで、以下の設定を追加しておいた。

 (require 'un-define)
 (un-define-change-charset-order
  (append '(ascii japanese-jisx0208)
          unicode-basic-translation-charset-order-list))

またバックスラシュと円記号の方も混乱が少ないように

 (require 'un-supple)
 (un-supple-enable 'windows)

を追加してく。


[ 3月8日全て ]

Related web page

nDiki: Docutils は自分にとっての Python キラーアプリかも (2005-12-01)
欲しいところだけまずは実装して使ったんだけれど、この先使っていくには細かいところを組んでいく必要がある。やっぱりフルスクラッチするのは面倒だな。 本来は <strong>Docutils</strong> 用の Writer を作成するのが王道。 しかし Python なんだよね。以前に何度か覚えておこうと思ったんだけれど動機付けが弱かったのかいつも途中でフェードアウト。 しかし今回は明確な目的があるので、もり
http://www.naney.org/diki/d/2005-12-01-Docutils.html

■よく検索されるキーワード

torrent(173) expressions(80) 竹内まりや(58) x31(25) ドラマ(23) linux(23) 手帳(21) 壁紙(21) perl(21) windows(20) 動画(19) wiki(17) porter(17) debian(16) 使い方(16) 画像(15) thinkpad(15) 作り方(15) gmail(14) usb(14) 秋葉原(13) ヨドバシ(13) ほぼ日手帳(13) 提案書(12) 活用(12) 竹内(12) 古川小百合(12) 修理(12) ノート(11) 無印(11) ヨドバシカメラ(11) nikon(11) 書き方(10) ダイソー(10) 万年筆(10) 生年月日(10) 大井町(10) ミニ6穴(9) ほぼ日(9) tc-1(9) 冷蔵庫(9) 設定(9) ニコン(9) java(9) mp3(8) 故障(8) 方眼(8) xp(8) 日誌(8) 感想(8) カメラ(8) allinanchor:*.torrent(8) バッグ(8) firefox(7) インストール(7) キーボード(7) mixi(7) 無料(7) リフィル(7) 小林麻耶(7) nikkor(7) ジョイントラック(7) madwifi(7) 原田夏希(7) skype(6) 変更(6) 三条まゆみ(6) ペンケース(6) web(6) emacs(6) home(6) ポーター(6) 2009(6) itunes(6) a6(6) 無印良品(6) デジカメ(6) finepix(6) 無線lan(6) 評判(6)

この日記のはてなブックマーク数 Add to Google RSS

Process Time: 1.250876s / load averages: 1.26, 1.33, 1.32
nDiki by WATANABE Yoshimasa (profile)
Powered by DiKicker
Base theme by Nana (for tDiary)