ブラザーのレーザー複合機

Posted on 2007/10/5 金曜日 | コメントをどうぞ
レーザープリンタのドラムが汚れて縦に黒線が入るようになってどうしようかなと思っていたところに Fax付電話機が故障したので、ここは複合機を買うことにした。 Postscript(互換)、Linux用のドライバが用意されているということでブラザーのレーザー複合機を購入した。

ほしい機能

Fax機能で、受信時は複合機のメモリに保持しておき(これは当然できる)、必要なときに PCからファイルとして見えると助かる1)のだが、結局、紙に印刷するしかない。スキャナ機能ではデータをFTPでPCに送ることもできるのだから、Fax機能でも受信データを同じように送ることができてもよさそうなものだが、その機能はないらしい。

brpcfax

オンラインでマニュアルを読めばだいたいの設定はできたのだが、「PC-FAX 送信 CUPS Wrapper ドライバのインストール方法」はちょっと不親切だ。インストールまではできるが使い方がわかりにくい2)。 そこで検索してみると英語版のInstalling a Brother Linux PC-FAX send driver into a CUPS based Linux Systemが見つかり、こちらの方がはるかにわかりやすい3)。もっとも使用頻度の高いと思われる OpenOffice.org から直接印刷するようにFaxを送る方法が載っている。ここにかいつまんで訳すと4)
  1. OpenOfficeの設定ユーティリティである spadmin を起動する。(注: このプログラムを探すには find / | grep spadmin )
  2. 「新しいプリンタ」ボタンをクリック
  3. 「Fax 機の設定」を選択して、「次へ」ボタンをクリック
  4. 「標準ドライバ」を選択して、「次へ」ボタンをクリック
  5. 次のコマンド行を入力5)
    brpcfax -o fax-number=(PHONE)
    そして「次へ」ボタンをクリック
  6. Faxプリンタの名前を入力。例えば Brother fax
  7. 「完了」ボタンをクリック
OOo で作成した文書を送るには、「印刷」で上記で名づけたFaxプリンタ名を選択して「OK」すると、Fax番号を入れる小さなウィンドウが開くのでそれを入力して「OK」する。 英語版マニュアルにはこの下に Mozilla の場合の設定方法があるが、firefoxでは「PostScript/default」以外のプリンタでは印刷コマンド指定ができないようだ。
  1. Windows なら附属のソフトでできるらしい。 ↩
  2. さらに誤りもある。「ファクス送信を実行する」の章の最初のコマンド例「単一宛先にファクス送信する場合：」は dpkg -i brmfcfaxcups-1.0.0-1.i386.deb と書かれているが、いくらなんでもそんな訳はない。英語版を見れば brpcfax -o fax-number=0566-55-12345 psfile.ps である。 ↩
  3. 検索中に見つけたブログの記事も参考になる。 ↩
  4. 実はStarSuite 8 管理ガイドにほぼ同じ記述がある。 ↩
  5. StarSuite 8 管理ガイドやブログの記事によると (TMP)をつけたほうがよさそうだ。 ↩

→ コメントをどうぞ

カテゴリー: ソフトウェア

タグ: ,

WordPress 2.3

Posted on 2007/9/29 土曜日 | コメントをどうぞ
WordPress 2.3 が出たので、入れ換え。プラグインの挙動についてはしばらく様子を見たい。このサイトで使っているものはいまのところ特に問題はなさそうだ。

日本語リソース

日本語リソース案内の記述は着々とよくなっている。 ここで私なりの補足。「日本語リソース」とは、WordPress の主要なメッセージの日本語訳をひとつのファイルにまとめたもの。詳しい説明はLocalization Technologyにある。 オリジナル版をダウンロードし、上記の「日本語リソース」を入れれば、主要な部分は日本語になり、これでも使える。 ところが、この方法ではカバーできないメッセージがどうしても残る。そこでそれらのメッセージはプログラム本体の中を直接書き換えなければならない。それは既に「オリジナル版ダウンロード」では得られないので、この書きかえられたものに上記の「日本語リソース」を合わせてパックしたものが「 日本語リソース入り WordPress」となる。この「日本語リソース入り WordPress」パックには、オリジナル版で日本語を扱う際の不都合を補うプラグインも同梱されている。 そこでユーザはどれを選べばいいか、ということになる。
「日本語リソース入りWordPress」
主要なメッセージのほかインストーラやエラー時の表示も日本語化。補助的プラグインも付いてくる。初めて WordPress をインストールするときや、完全日本語版でいう方はこの方法。
オリジナル版に「日本語リソース」のみ
主要なメッセージは日本語化される。インストーラやエラー時の表示は英語のまま。もう WordPress に慣れていて、バージョンアップだからインストーラは不要とか、プラグインは既に入手済または別途入手するから、「日本語リソース入りWordPress」が出るまで待てないという方はこの方法。
オリジナル版のみ
それでも構わない。あちこちのメッセージが英語のままというだけで、日本語を使うこと自体はできる。事情がわかっている方向き。
公開の順番は、オリジナル版のバージョンがまず発表され、それを受けて「日本語リソース」が出され、最後にそれらを受けて「日本語リソース入りWordPress」が発表されることになる。 今回の私の場合は、バージョンアップ、プラグイン導入済、エラーメッセージくらい英語でもかまわない、という状況のため、二番めの「オリジナル版に「日本語リソース」のみ」の方法をとった。

→ コメントをどうぞ

カテゴリー: WordPress

タグ:

連用日記

Posted on 2007/9/25 火曜日 | コメントをどうぞ
紙の日記帳に「10年日記」というものがある。複数年日記のことを連用日記というらしい。Web日記システム tDiary には「長年日記」という機能がある。 WordPress でもこのようなプラグインはないだろうかと探してみた1)。「連用日記」を英語で何と言うのだろうなどと思いつつ、いろいろ探しているうちに onthisday というものを見つけたので、試してみる。

改造のアイデア

自分ではコードを書けないくせに、元ネタがあるともう少し何とかならないものかと思ってしまう。時間が経つと忘れてしまいそうなのでアイデアをここにメモしておく。 まず、そのままでは excerpt (抜粋)の作り方が日本語だとうまくいかないようだ。これは WordPress 本体のどこからかコードをコピーしてくればよさそうだ。 それから、「見ている時点と同じ年の記事は参照しない」というスイッチはあるが、「書かれた時点と同じ年(つまり全く同日)の記事は参照しない」というスイッチもほしい。 もう一つのアイデアはもっと根本的なこと。この onthisday を見つける前から思っていたことだ。例に挙げた tDiary の「長年日記」や紙の連用日記でも過去の年の「同一月日」を参照する。しかし実生活は「曜日」を基準に動いていることが多いのではなかろうか。たとえば今年は月曜日とすると去年の同じ日は日曜日で、普通の勤め人や学生のような生活なら、その日どうしを並べるより同じ月曜日を参照するほうが意味が多いように思える。 しばらく前に「第何何曜日」について考えたので、それを使って、同月同曜日を指すようにできるのではないか。 欠点と言えば、だいたいの場合は1年で1日違い(うるう年なら2日違い)なのだがたまに1週間ほど日付がずれてしまうところがあることだろう。これはそもそも今の暦システムの欠点2)なのだが。 そのうち暇をみて、改造できるものかどうかやってみたい。もし何かの拍子にこれをご覧になって(あるいは見るより前に)さっさと実装された方があったら教えてください。
  1. このサイトのようにポツポツとしか書いていないと何の面白味もないが。 ↩
  2. 1年365日を1週7日で割りきれないこと。しかも月ごとに日数が変わるなど、不規則だらけでまったく変なシステムである。 ↩

→ コメントをどうぞ

カテゴリー: WordPress

タグ:

WordPress 2.2.2

Posted on 2007/8/9 木曜日 | コメントをどうぞ
WordPress 2.2.2 が出たので入れ換え。マイナーな変更のようだし、もはやあまり話題にはなっていないようだ。 本家からダウンロードし、日本語リソース案内所から ja.mo をもらってきて置くだけで完了。特に問題はなさそうだ。

wp_list_authors()

さてここを含め複数の管理している(請け負っている) WordPress サイトをアップグレードしたのだが、そのひとつは久しぶりだった (2.1.3 –> 2.2.2)。そこで挙動が変わった点を見つけた。 そこは複数のユーザが執筆しており、通常の記事のほかにも(静的)ページもたくさんあるという構成になっている。たいていの場合サイドバーに「カテゴリー」「アーカイブ」のリストが設置されているように、それらに加えて「執筆者」のリストも表示するるようにしていた。これは wp_list_authors() という用意されている関数を用いている。この引数に optioncount=1 を与えると、執筆者名の横にその人の書いた記事数が表示される。これまでその数は記事のみの数だったのだが、今回のアップグレードで(静的)ページの数も含んだ数が表示されるようになってしまった。 どちらが便利かはサイトによるだろうから、一概にバグとは言えないとは思う1)。仕様を変更してしまうより、どちらか選択できるようにスイッチを増やしてもらったほうがありがたかった。
  1. 複数ユーザで静的ページも多くあるサイトを運営していているところは割合としてはとても小さいだろうだろうから、情報は極めて少ないだろう。検索してみても日本語でこれに触れているものは見つからなかった。英語でまで調べてみようとはいまは思っていない。 ↩

→ コメントをどうぞ

カテゴリー: WordPress

タグ:

emacs22 と wnn7-elisp パッケージ

Posted on 2007/7/10 火曜日 | 1件のコメント
Debian sid に emacs22 (とその GTK版emacs22-gtk) が降りてきた。さっそく入れようと思ったがいくつかのパッケージが対応していない。特に wnn7-elisp は Debian 公式のものではなく、商用(しかも5,6年も前)なので対応パッケージが出るとも思われない。自分で修正することとした。
PLAIN TEXT
DIFF:
  1. --- wnn7-elisp.orig/DEBIAN/control  2002-05-22 18:42:05.000000000 +0900
  2. +++ wnn7-elisp/DEBIAN/control   2007-07-09 15:02:36.000000000 +0900
  3. @@ -1,13 +1,13 @@
  4.  Priority: extra
  5.  Architecture: all
  6. -Depends: emacs20 | emacs20-dl | xemacs21-mule | xemacs21-mule-canna-wnn
  7. +Depends: emacs22 | emacs-snapshot | emacs21 | emacs20 | emacs20-dl | xemacs21-mule | xemacs21-mule-canna-wnn
  8.  Installed-Size: 587
  9.  Maintainer: OMRON SOFTWARE Co.,Ltd. <wnn-info@omronsoft.co.jp>
  10.  Description: A package of Japanese input method 'Wnn7' elisp client.
  11. diff -u -r wnn7-elisp.orig/usr/lib/emacsen-common/packages/install/wnn7-elisp wnn7-elisp/usr/lib/emacsen-common/packages/install/wnn7-elisp
  12. --- wnn7-elisp.orig/usr/lib/emacsen-common/packages/install/wnn7-elisp  2002-05-22 18:41:59.000000000 +0900
  13. +++ wnn7-elisp/usr/lib/emacsen-common/packages/install/wnn7-elisp   2007-07-10 21:50:47.818091867 +0900
  14. @@ -37,7 +37,7 @@
  15.      emacs)
  16.      ;;
  17.  
  18. -    emacs20|xemacs21)
  19. +    emacs22|emacs-snapshot|emacs21|emacs20|xemacs21)
  20.      install -m 755 -d ${ELCDIR}
  21.      (cd ${ELDIR}
  22.  
  23. diff -u -r wnn7-elisp.orig/usr/lib/emacsen-common/packages/remove/wnn7-elisp wnn7-elisp/usr/lib/emacsen-common/packages/remove/wnn7-elisp
  24. --- wnn7-elisp.orig/usr/lib/emacsen-common/packages/remove/wnn7-elisp   2002-05-22 18:41:59.000000000 +0900
  25. +++ wnn7-elisp/usr/lib/emacsen-common/packages/remove/wnn7-elisp    2007-07-10 21:51:17.472192301 +0900
  26. @@ -10,7 +10,7 @@
  27.  case "${FLAVOR}" in
  28.      emacs)
  29.      ;;
  30. -    emacs20|xemacs21)
  31. +    emacs22|emacs-snapshot|emacs21|emacs20|xemacs21)
  32.      echo remove/${PACKAGE}: purging byte-compiled files for ${FLAVOR}
  33.      rm -rf /usr/share/${FLAVOR}/site-lisp/${PACKAGE}
  34.      rm -f ${STARTDIR}/50${STARTFILE}*;

wnn7-elisp の他にも auctex, gnus も同様に修正すればいますぐ使える。これらは公式パッケージなのでしばらく待てば emacs22 対応版が出るだろう。

→ 1件のコメント

カテゴリー: Debian

タグ: , ,

MediaWikiのスタイルシート

Posted on 2007/6/6 水曜日 | コメントをどうぞ
編集の際、プレビューはするものの最後に保存するのを忘れてしまい、せっかくの編集が水泡に帰すことがしばしばある。そこでせめてプレビューのあいだは背景に色を着けて注意を促したい。 全ての外装に反映されるスタイルは MediaWiki:Common.css に書けばいいらしい。編集画面でプレビューは <div id='wikiPreview'> となっているので、
PLAIN TEXT
CSS:
  1. div#wikiPreview {
  2. background-color: #ACCAC1;
  3. }

のように書いた。

→ コメントをどうぞ

カテゴリー: ソフトウェア

タグ: ,

第何何曜日

Posted on 2007/4/9 月曜日 | 1件のコメント

日付を尋ねる場合に「何年何月何日」のようにあいだに別の語が挟まればいいのだが、「第何何曜日」というのは言いにくい1)。次のような事情で「第何何曜日」を求める方法を検索したく、この単語でいいのだろうかと思ったが、やはり仕方ないのかこのまま書いてあるのがいくつか見つかった。ともあれ意味は通じるし、そもそも未知のところを「何」に置き換えればほぼそのまま表現できる日本語は強力だ。

さて、その事情というのは……うちの資源ゴミの収集日は「第 2, 4 月曜日」だ。うっかり忘れてしまうことがしばしばあるので、収集日 (の前日) に自分宛にメールを飛ばそうと考えた。cron では「第何何曜日」という指定はできないので、スクリプトのほうで判定する。せっかくだからメモしておく。

Y 年 m 月 d 日は、その月の第 i の w 曜日か

これは検索ですぐに見つかった。曜日は、PHP なら求める手段は用意されている。

PLAIN TEXT
PHP:
  1. $i = floor(($d+6)/7);
  2. $w = date("w", strtotime($Y . $m . $d));

Y 年 m 月の第 i の w 曜日は、その月の d 日か

上の逆だから簡単だと思ったが、何度か試してみてようやく

PLAIN TEXT
PHP:
  1. $w1= date("w", strtotime($Y . $m . "01"));
  2. $d = $i*7-6 + ($w+(7-$w1))%7;

とした。ここで $w1 は当該月の 1 日の曜日である。$d が当該月の最大日を越えない判定が必要かもしれないが、ゴミ収集日はたいていの場合 5 回目の曜日には設定されないので省略した。

---

ところでこのために PHP マニュアルの日付・時刻関数を見ていたら、日の出時刻や日の入り時刻を返す関数というものまであるではないか2)。

現代の都市生活者には日の出・日の入り時刻より、ゴミ収集日を返す関数のほうがありがたい。……と思ったら、この日の出・日の入り時刻関数は宗教上の必要から作られたらしい。別に農耕狩猟生活のためというわけではなかった。


  1. 「第何週の何曜日」というと誤解を招く。今月はたまたま 1 日 が日曜日だからいいとして、たとえば来月 (2007年5月) の「第 2 週の月曜日」は 7 日? 14日? ↩
  2. 残念ながらここのサーバは PHP のバージョンが 4 なので、これらを使えない。 ↩

→ 1件のコメント

カテゴリー: ことば, ソフトウェア

タグ: , ,

電子テキストの文字校正

Posted on 2007/3/31 土曜日 | コメントをどうぞ

印刷を目的としない文章を、修正個所を判りやすく指示 (つまり「校正」) しながら遠くにいる人ととともに作っていくにはどうするか。メールでやりとりすることを念頭において考えていたことをまとめてここにメモしておく。

ごく短いプレーンテキスト

「2 段落めの最初の文、ふたつめの『ロボット』を『人間』に置換」という感じの、電話で口伝えするような、長たらしい指示。 ごく短い文書で校正個所が少ないときにはこれでも伝わるが、増えてくると嫌になる。

指示を受け取った側 (この文章では「著者」と呼ぶことにする) は、その指示にしたがって元の文書を書き換える。

改行が少ない文書

自然言語の単純なテキストファイルや HTML の文書など1)。

校正の内容は、プレーンテキストなら文字種や大きさはないので、ほとんど削除・挿入のみ (置換は「削除して挿入」で表現できる) となる。

タグによる校正記号

<del> と <ins> で表現する。校正に関するコメントは著者と校正者で了解して <comm> にするとか、あるいは HTML の範囲内のタグを流用する。

PLAIN TEXT
HTML:
  1. ロボットは他の<del>ロボット<comm>これは「人間」のはず</comm></del><ins>人間</ins>に危害を加えてはならない．

HTML を知っている人には意味が通じやすい。しかし、人間に伝えるためのもので、実際に HTML のタグとして機能するわけではない2)ので注意が必要である。エディタは HTML 対応のもので代用できるかもしれない。

校正の作業

校正者は対象ファイルにエディタで直接タグを書き込んでいく。置換の場合、<del> と <ins> が連続することになる。

ruby を使える環境なら Docdiff (単語あるいは文字単位の差分でとる) を利用する方法がある。docdiff.conf で

PLAIN TEXT
CODE:
  1. tag_del_start           = <del>
  2. tag_del_end             = </del>
  3. tag_add_start           = <ins>
  4. tag_add_end             = </ins>
  5. tag_change_before_start = <del>
  6. tag_change_before_end   = </del>
  7. tag_change_after_start  = <ins>
  8. tag_change_after_end    = </ins>

と設定しておく。

元ファイルを別に保存しておき、対象ファイルは校正後の形に書き換える。

PLAIN TEXT
BASH:
  1. docdiff --format=user example.txt.orig example.txt

で校正記号入りテキストを作成する3)。コメントには対応していないので、その後エディタで開いて書き込む。

著者の作業

校正記号入りテキストを受け取った著者は、エディタで <del> のタグで囲まれた部分 (もし校正者の指摘を受け入れられなければ <del> ではなく <ins> で囲まれた部分) や <comm> で囲まれた部分を削除する。さらに <ins> タグを (囲んでいる内容は残して) 削除する。

HTML 文書

HTML 文書の場合、上記の <del> や <ins> のタグを使う方法では校正記号が目立たない。また、タグ自体の校正をするときに特に混乱する。たとえば

PLAIN TEXT
HTML:
  2.   <li>ロボットは他の人間に危害を加えてはならない．</li>
  3. <del></ol><comm>閉じタグが間違っています</comm></del><ins></ul></ins>

となってしまう。そもそも上記の方法で用いたタグは人間のためのもので、著者と校正者で了解できていれば何でもよく、<del> や <ins> でなければならないわけではない。

それを一般化した 真鵺道 Manued というものがある。もちろん HTML 以外のプレーンテキストにも使える。規則は少ないのですぐに覚えられる。たとえば上の例は

PLAIN TEXT
TEXT:
  1. <ul>
  2.   <li>ロボットは他の人間に危害を加えてはならない．</li>
  3. 【</ol>／</ul>＃閉じタグが間違っています】

のように書くことができる4)。

真鵺道 Manued の最大の特長は機械処理が可能という点である。Emacs (系) には manued.el がある。しかし残念ながらほかのエディタの対応は見かけない。

校正の作業

対象ファイルにエディタで校正記号を書き込んでいく。Emacs で manued.el を使えば楽である。

校正ファイルの先頭に、アプリケーション (Emacs の manued.el のみなのか) に対する修正記号定義コマンドと、人間に対する注意書 (著者と校正者がしっかり了解していればなくてもいい) を付ける。

PLAIN TEXT
CODE:
  1. defparentheses  [ ]
  2. defdelete       /
  3. defswap         |
  4. defcomment      ;
  5. defescape       ~
  6. deforder        newer-last
  7. defversion      0.9.5
  8. 校正記号は次のとおりです。
  9. [α/β]          αをβに変更する
  10. [/α]            αを挿入する (変更の特殊形)
  11. [α/]            αを削除する (変更の特殊形)
  12. [α|γ|β]       αγβをβγαに並べ換える
  13. [α||β]         αβをβαに並べ換える(並べ換えの特殊形)
  14. [;コメント]    校正に関するコメント

ruby を使える環境なら、Docdiff (単語あるいは文字単位の差分でとる) を利用する方法がある。

元ファイルを保存しておき、

PLAIN TEXT
BASH:
  1. docdiff --format=manued example.txt.orig example.txt

とする。

真鵺道 Manued 自体は上述の定義コマンドで修正記号を変更できる。しかし Docdiff は真鵺道のデフォルトの修正記号 (上記のもの) に固定されていて自由に変更できない。また Docdiff はコメントには対応していないので、後でエディタで書き込んでいく。

著者の作業

もし著者が Emacs で manued.el を使えるなら、受け取った校正記号入りテキストで、個々の校正記号についてオリジナルか修正指示のどちらを選択するかを簡単な操作でできるし、校正記号を含まない元の文書または修正された文書の全体を取り出すことも簡単にできる。

もしそれを使えない場合は、前述のタグ表現の場合と同じように、いちいち校正個所を直していく。

改行を多く含む文書

もちろん適宜改行されているテキストに対しても上記の方法は適用できる。 そのほかに diff を使うことができる。元ファイルを保存しておき、

PLAIN TEXT
BASH:
  1. diff -u example.txt.orig example.txt

とする。ディレクトリごとまとめて扱うこともできる。 プログラムのソースコードなどに向いている。よく改行されている HTML 文書や TeX の文書に使うこともできる。

校正コメントは使えない。

著者は diff ファイルを受け取ったら、patch で元ファイルに反映させることができる。

書き換えてしまう

ここまで「変更個所および変更内容をわかるように指示する」ことに留意して、ファイルを直接書き換えてしまう (オリジナルを残さずに) ことは考えなかった。

だんだん「校正」から逸れてきたが、履歴がきちんと残るのなら直接書き換えてしまうということも考えられる。メールでのやりとりではないが Wiki という手もある。しかし短い単なるテキストを扱うには大袈裟すぎる。それに校正段階では一般に公開しないのが普通で、そのためには認証のしくみをつけて、いちいちログインしてもらうようにしなければならない。いわゆる一般人にはそれだけでも敬遠される。

cvs, subversion などと適切なブラウザの組み合わせも、変更点がわかるので「校正」と言えなくもない。しかしこれもプログラマやそれと同じ程度にコンピュータに興味を持って向かい合える人以外にはなかなか受け入れてもらえないだろう。

朱を入れる

OpenOffice.org Writer, MS Word, PDF などの文書に「朱」を入れる。それぞれのデータを扱えるソフトを著者と校正者がそれぞれ所有していて、その「コメント機能」の類を使えることが前提となる。商用ソフトが必須となったり Linux では揃えられなかったりと障壁が大きい。

文字種や大きさ、レイアウトなどの校正は、ここで言う文字校正の範囲を越える。文字校正だけなら、テキストに変換して上記の方法を適用することも考えられる。

最後の手段は、紙にプリントして朱を入れる。もはや「電子テキスト」からも逸脱する。ついでなのでここにメモしておくが、「印刷校正記号 JIS Z 8208:2007」は 2007-01-20 改正になっている。これは有料となっているが、日本工業標準調査会のサイトで、JIS規格番号「Z8208」で検索すれば閲覧できる。


  1. HTML の地の文で適当に改行を入れると、たいてい微妙に空白がはいってレンダリングされる。英語などでは改行は単語間空白という取り扱いで問題ないのだが、日本語では格好悪いので 1段落のあいだ改行を入れないことが多い。pTeX はこのへんをうまくやってくれるので気にせず適当な文字数で改行をいれたほうがいい (エラーの際に行番号が表示されるので場所を特定しやすい)。 ↩
  2. 全体を <pre> で囲むだけでもブラウザでそれなりに見えるかもしれない。 ↩
  3. Docdiff には --format=html というオプションもある。変更点を HTML で美しく表示できるようにするものである。しかしその表示のためにたくさんのタグなどがはいるので、著者が校正結果を抽出するのにやや手間がかかる。 ↩
  4. defparentheses を【 】、defdelete を／、defcommentを＃と設定している場合。 ↩

→ コメントをどうぞ

カテゴリー: ことば, ソフトウェア

タグ: , , ,

日本語スタイルガイド

Posted on 2007/3/22 木曜日 | コメントをどうぞ

Wiki 書式をやめて(簡略)HTML で書くようになったら、そのほうがむしろ書きたいように楽に書けることが判って、なんだという気がしている。

さてそうすると内容以外の、文章のスタイルについても気になってきた。それは何もここに書くときだけではない。自分のなかではこれまでの経験からある一定のルールというのが出来ているのだが、重要度 (自分にとっての) に応じてブレるものもある。

そこで文章のスタイルについてのガイドラインについて、検索してみた。Gnome.JP の Wiki を経由して、タイムリーにも出たばかりの What's Translation@Sun の 日本語スタイルガイド を発見した。元々の Sun 内部の指針を再編されたものということだ。英語から日本語への翻訳を前提に書かれているが、はじめから日本語の文章を書く場合にもよく当てはまる。いったん通読したら普段は クイックリファレンスを見るだけでも随分役に立ちそうだ。何しろ個人や小さなコミュニティではこのような明文化の作業はしない (できない) ので、たいへんありがたい。

自分のなかのルールといくつかの点で違いはある。たとえば感嘆符・疑問符は使わない、としている点。横書きの、特にブログのような場面では既に日本語の一部として使用可能だと思う。さらに、もし使う場合 (メッセージでは使うとされている) には日本語と疑問符のあいだにスペースを入れるとしている点も疑問に思う。そのほか漢字とかなの使い分けのなかにもいくつか自分の基準と違うものがある。

しかしそれらを除いて大部分はたいへん有益な内容である。カタカナ語の末尾の長音は、自分のなかでも場面ごとにブレが大きく気になっていたので、100% 同意できるかどうかは別として、大いに参考になった。元々が技術文書、マニュアルを対象として作られているので、それ以外にそのまま適用できないかもしれないが、参照資料のひとつとして活用したい。

→ コメントをどうぞ

カテゴリー: ことば

タグ: ,

iG:Syntax Hiliter プラグインと Footnotes プラグイン

Posted on 2007/3/21 水曜日 | コメントをどうぞ
WP-Dokuwiki をやめてしばらく WP 標準で書いてみようと思っている。WP-Dokuwiki で便利に思っていたのはソースコードのハイライトと脚注。これに代わるプラグインを探す。それぞれ数種類づつ見つかったが、ちょっとづつ試してみて iG:Syntax Hiliter プラグインと Footnotes プラグインを使うことにした。

iG:Syntax Hiliter プラグイン

現在のバージョン v3.5 は、添付のマニュアルを見ると 19 ほどの言語に対応しているとある。が、ふとサブディレクトリの GeSHi を最新版に入れ替えてみたらどうだろうと思い、やってみると特に問題はなさそうだ1)。これで 80 ほどの言語に対応する(ほとんどは一度も使わないだろう)。Bash や diff, LaTeX もいけそうだ。 いろいろ探しているうちに “iG:Syntax Hiliterの不具合(?)を直す” という記事を発見。ここでも何かの拍子に設定がリセットされてしまったことがあったので、これかと思い対策した。

Footnotes プラグイン

使い方は WP-Dokuwiki の脚注とほぼ同じで、簡単。ただ出力は、本文の最後に <br /> をつけてそのあとに番号付きリストを生成するようになっているらしい。するとなぜか自動で挿入される </p> がおかしくなり、HTML 的に間違ったことになる。それで
PLAIN TEXT
DIFF:
  1. --- footnotes.php.orig
  2. +++ footnotes.php
  3. @@ -98,14 +98,14 @@
  4.  
  5.         if ($footnotes){
  6.                 $counter = $start_number;
  7. -               if ($start_number != 0) $data = $data.'<br /><ol start="'. ($start_number + 1) .'" class="footnotes">';
  8. -               else $data = $data.'<br /><ol class="footnotes">';
  9. +               if ($start_number != 0) $data = $data.'<div><ol start="'. ($start_number + 1) .'" class="footnotes">';
  10. +               else $data = $data.'<div><ol class="footnotes">';
  11.  
  12.                 foreach($footnotes as $footnote){
  13.                         $counter++;
  14.                         $data = $data.'<li id="footnote-'.$counter.'-'.$post->ID.'">'.$footnote.'  '.$current_settings['pre_backlink'].'<a href="#footnote-link-'.$counter.'-'.$post->ID.'">'.$current_settings['backlink'].'</a>'.$current_settings['post_backlink'].'</li>';
  15.                 }
  16. -               $data = $data.'</ol>';
  17. +               $data = $data.'</ol></div>';
  18.         }
  19.      return $data;
  20.  }

と、<div> に入れることにした。 見栄えはスタイルシートで設定する。
  1. iG:Syntax Hiliter プラグインの syntax_hilite.php の switch 文にいくつか case を書き足す必要があるかも。 ↩

→ コメントをどうぞ

カテゴリー: WordPress

タグ: