投稿者: Mako

fontconfig 2.4.1

Debian, コメントを残す
永らく 2.3.2-1 で hold していたのだが、思い余って現時点の sid のバージョン 2.4.1 に入れ換えてみた。

設定ファイル

設定ファイルの配置が変更になったようで、/etc/fonts/conf.avail/ から/etc/fonts/conf.d/ にリンクが張られていると有効となるようだ。で、この中に 51-local.conf というのがあって、それで /etc/fonts/local.conf を読み込むようになっているので、ローカルの設定は結局 /etc/fonts/local.conf に書けばよさそう。 ところで debian 的には、/etc/fonts/conf.avail/ 以下の内容を書き換えたい(上書きしたい場合)はどうするのがよいのだろう。例えば 90-synthetic.conf は「疑似斜体」と「疑似ボールド」を実現するのだが、このうち斜体は生かしたくてボールドは抑制したい。local.conf で embolden を false にしても読み込みの順番によって true にされてしまう。90-synthetic.conf を直接書き直すのだろうか。 ここでは、リンクを /etc/fonts/conf.avail/51-local.conf から/etc/fonts/conf.d/91-local.conf に張りかえて、local.conf が最後になるようにした。

IPAフォントを総称名で

「sans」「sans-serif」で指定したときに、IPAフォント[1]を用いるようにしたい。Xft フォントシステムの設定を参考にして、/etc/fonts/local.conf に 
<alias>
  <family>serif</family>
  <prefer>
    <family>Bitstream Vera Serif</family>
    <family>IPAMincho</family>
  </prefer>
</alias>
<alias>
  <family>sans-serif</family>
  <prefer>
    <family>Bitstream Vera Sans</family>
    <family>IPAGothic</family>
  </prefer>
</alias>
<alias>
  <family>monospace</family>
  <prefer>
    <family>Bitstream Vera Sans Mono</family>
    <family>IPAGothic</family>
  </prefer>
</alias>
のように書く。

ボールドはEPSONフォントを

EPSON プリンタに付属の CD-ROM に太明朝や太ゴシックなどのフォントが入っている[2]ので、ボールドは疑似を使わず、これらを用いるようにする。 /etc/fonts/local.conf では、まず疑似ボールドを抑制し[3]、 
<match target="font">
  <edit name="embolden" mode="assign">
    <bool>false</bool>
  </edit>
</match>
明朝 (IPAMincho) のボールドに EpsonFutoMincho, ゴシック (IPAGothic) に EpsonFutoKakugo をそれぞれ対応させる。 
<match target="pattern" >
 <test name="family" >
   <string>IPAMincho</string>
 </test>
 <test compare="more" name="weight" >
   <const>medium</const>
 </test>
 <edit mode="assign" name="family" >
   <string>EPSON 太明朝体Ｂ</string>
 </edit>
</match>
<match target="pattern" >
 <test name="family" >
   <string>IPAGothic</string>
 </test>
 <test compare="more" name="weight" >
   <const>medium</const>
 </test>
 <edit mode="assign" name="family" >
   <string>EPSON 太角ゴシック体Ｂ</string>
 </edit>
</match>
ここでフォント名はフォントそのものに埋め込まれている名前 (fc-listで表示される)を書く。UTF-8 なら local.conf も UTF-8 にする。

ビットマップを抑制

武藤さんの日記にあるとおりなので、/etc/fonts/local.conf に 
<match target="font" >
  <edit mode="assign" name="embeddedbitmap">
    <bool>false</bool>
  </edit>
</match>
を書く。

「〜」(波ダッシュ、U+301C)

IPAフォントでは「〜」(波ダッシュ、U+301C)が表示されない。これについてはいろいろ意見があるだろうが、現実問題として、Firefoxであちこちのサイトを見る場合などかなり鬱陶しい。 根本的解決でなくても、表示する際に fontconfig あたりで置換することはできないのだろうかと思って検索してみると、やはり既にパッチがあった。 上記のもののうち必要な部分だけを取り出し、最新の fontconfig (2.4.1)に行番号を合わせたものを置いておく。 まず apt-get source fontconfig でソースを持ってくる。ディレクトリ debian/ の下にpatches/ というディレクトリを作り、その下に上記のパッチを置く。その際ファイル名の拡張子は .patch とか .diff にする。 あとは dpkg-buildpackage -rfakeroot で、自動的にパッチを当てながらパッケージができる。 パッケージをインストールした後、fc-cacheを忘れずに。
  1. GRASS国際化版やオープンプリンティングプロジェクトで入手できる。↑
  2. もしCD-ROMを紛失したならEPSONダウンロードサービスから入手可能。↑
  3. そして前述のようにこの指定が最後に来て有効になるようにして。抑制しておかないと太字にデザインされたフォントをさらにボールド化しようとして醜くなる。↑

MediaWiki

ソフトウェア, コメントを残す

またもや随分間があいてしまった。

さて今度は訳あって某所に Wikiを導入。多言語を扱いたいという要望により MediaWiki にした。特に問題なくインストール完了。

一般公開するものではなく、閲覧もメンバに限りたいということで、LocalSettings.php に

  $wgWhitelistRead = array( "Main Page", "Special:Userlogin");
  $wgGroupPermissions['*']['read'] = false;
この2行めが必要ということに気づくまで時間がかかってしまった[1]。

書込みももちろんメンバ限定なので

  $wgGroupPermissions['*']['createaccount']   = false;
  $wgGroupPermissions['*']['edit'] = false;
  1. 1行めは、もし日本語でインストール場合は 
      $wgWhitelistRead = array ("メインページ", "特別:ユーザログイン");
    として utf-8で保存する。↑

Organizerプラグイン

WordPress, 1件のコメント
「半月記」と銘打ちながら2ヶ月あまりも放置している間に、[[//pasero.net/~mako/blog/s/27|Organizerプラグイン]]にトラックバックがあり、多くの人に見られている模様。こりゃちゃんと更新しなきゃいかんなと思いつつも、WordPressは安定していてほとんど書くことないし。何か長続きするネタを考えないと。 さて紹介していただいたはいいものの、実はOrganizerプラグイン、まったく使えていない。ここと、別に運用している某所の2個所にいれてみたが、なぜか挙動が多少違う(ここではサブディレクトリの作成と削除だけができるが、サブディレクトリへの移動すらできないし画像編集などは機能しない。某所ではサブディレクトリの移動はできるがやはり画像編集は機能しない)が、いずれにしろ使い物にならないのだ。 こことその某所の共通点は、[[http://www.sakura.ne.jp/rs/index.shtml|さくらインターネットのレンタルサーバ]]ということである(2つのサーバは別々だが)。 さくらでOrganizerちゃんと動いてるよ、という方いますか?

mod_rewrite

WordPress2件のコメント

しばらく間が空いてしまった。WordPress自体があまり手がかからないようで、ひととおり設定してしまえば特に問題もなく、書くこともない。

今回の件は WordPress カテゴリに含めるのも何だという気もするが、その関連ということで。

WordPress導入時、.htaccessに自動的に

# BEGIN WordPress
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</ifmodule>
# END WordPress

と書き込まれる。実在するファイル名・ディレクトリ名でない場合、/index.php が呼ばれるようになる。

さて、WordPress 導入以前に同じサイトで某日記システムを使っていたのだが、その URL は

http://www.example.com/?date=20050325

のようになるものであった。現在この URL で指示されるものはないのだが、上記により、404 エラーにはならず、トップページが表示される。

検索エンジンに旧い形式の URL が残っていて、しかもいま WordPress で作られたトップページがその旧い形式の URL の内容として着々と更新され続ける。WordPress で書いた最新の記事の内容が、http://www.example.com/?date=20050325 のものとして検索されてしまうのだ。

放っておいてもその連鎖は断ち切れないので、ロボット対策を参考に、.htaccess に次のように書き加えてみた[1]。

<ifmodule mod_rewrite.c>
RewriteCond %{HTTP_USER_AGENT} archiver [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} crawler [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} robot [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} slurp [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} spider [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} googlebot [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} msnbot [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
RewriteCond %{HTTP_USER_AGENT} findlinks [NC]
RewriteCond %{QUERY_STRING} .*date=200.*
RewriteRule ^.*$ - [G,L]
</ifmodule>

旧URLへのアクセスは、(1)せっかく検索して見つけて来てくれる人には今のトップページをみていただく (2)検索ロボットなら 410 エラーを返す、とした。こうしておけばそのうち検索エンジンから消えるだろうし、昔の記事に直接リンクしている人はほぼいないだろうから、旧URLへのアクセスは絶滅するだろうと考えた。

—-

という対策をとったのが実は1ヶ月前。だいたい思ったとおりに絶滅に向かっていったのだが、Yahoo の Slurp というのは行儀が悪いのか[2]、なかなか根絶できない。

そして今日、検索で旧 URL をたどってくる人がなぜか増えている。確認すると、.htaccess の当該部分がすっかり消えている。ファイルの時刻を見ると、絶対に自分で何かをした時刻ではない。WordPress がこれを書き換えることはないと思うし、そうするとこれを置いているレンタルサーバの問題なのだろうか。なんだか気持ちが悪い。

  1. (A or B or C) and D は mod_rewrite の文法でどう書くのだろう。はっきりしないので冗長に書いた。↑
  2. ログを見るとアクセス頻度もやたらと多い↑

Organizerプラグイン

WordPress, 2件のコメント
画像ファイルを管理するプラグインを探していて、見つけた。 [[http://imthi.com/organizer/|Organizerプラグイン]]は * wp-content/uploadsディレクトリ(または設定しているアップロード用ディレクトリ)とその中のサブディレクトリのファイルを一覧 * アップロード用ディレクトリ内のファイルのコピー・ファイル名変更・削除 * サブディレクトリの作成・名前変更・削除 * ファイルのアップロード * 画像の拡大縮小 * 複数ユーザとパーミッションに対応 * アップロード用ディレクトリでファイル名を変更したら、記事内での参照個所も自動的に変更 * roles に対応。[[http://redalt.com/wiki/Role+Manager|Role Manager]]で管理 というもの。特に最後の3点が嬉しい。そのほかはこの前に導入した[[http://soderlind.no/archives/2006/01/03/imagemanager-20/|ImageManagerプラグイン]]([[http://bd.dotted.jp/archives/85/|日本語版]])でカバーされていたので。 [[//pasero.net/~mako/blog/|ここ]]と、別の管理している某所にいれてみた。その某所ではうまく機能するのに、ここではディレクトリの中のファイルを見つけてくれない(‘No files in this directory’)。ほかのプラグインと干渉しているのか、はたまた別の問題なのか。 その某所とここの大きな違いは、[[http://support.sakura.ad.jp/support/manual/rs/setdom_h.shtml|ドメインのエイリアス設定]]にしていることか。これが何らか影響しているのか。 というわけで、インストールとだいたいの動作は確認できたが、こまかくは見ていない。

Chatzilla

ソフトウェア, 2件のコメント

MLで第三回WordPress交流会のお知らせがあったので顔を出してみた。都合があってほんの30分ほどしか参加できなかったのだが、皆さんありがとうございました。

さて、もうずいぶん長いこと使っていない IRC だったので、クライアントを探して入れるところからだった。いくつか試してみて、手っ取り早く使いやすかったのは Chatzilla。Mozilla Suite から Firefox になってなくなってしまったかと思っていたら、拡張としてちゃんと存在していた。日本語化されているにょずらのものを入れた。

[2007年6月25日追記] にょ☆ずらの URI が変更になっていたので、現在のものに変更した。

wp-dokuwiki手直し

WordPress, コメントを残す
===excerptの生成=== トラックバックの際、特に excerptを書かなかった場合、本文の冒頭から自動的に excerptを生成してくれるが、本文を最初から最後まで[[http://floatingsun.net/blog/code/wp-dokuwiki/|wp-dokuwiki]]で書いた場合、excerpt は空になってしまう。 これを機に、 > 概要\ > ほとんどのトラックバックは概要 ( excerpt ) を記述していないために、トラックバック欄に表示される内容が記事の冒頭部分となってしまっているものばかりです。トラックバックを受信した側は、そういったトラックバックでは記事の概要をつかめません。 >
—概要 ( excerpt ) の重要性
ももっともと考え、できるだけ書くようにしようと思った((この記事はまさにexcerptを書くべきであるが、自動生成の試験も兼ねているので敢えて書かない))。 しかし、短い記事やささっと書くものなどわざわざexcerptを書くまでもないものも多いだろうし、それに本文の冒頭は「つかみ」としてexcerpt的に書くことが望ましいとも思う。やはり本文から自動的にexcerptを生成してほしい。 さて、WordPress本体か日本語化の部分に問題があるのかと散々探しまわった挙げ句、やはり wp-dokuwikiの側を直せばいいことがわかった。 wp-dokuwiki.php内のフィルタは、echoで出力し戻り値は空になっている。本文を本文として表示するときにはこれでいいのかもしれないが、今回のように別の個所で利用する際には具合いが悪い。echoで出力されているものを(echoでは出力しないようにして)いったん蓄え、戻り値で返すようにした。これで excerptが生成されるようになった。 === wp-dokuwiki プラグイン 0.3=== [[http://floatingsun.net/blog/code/wp-dokuwiki/|wp-dokuwiki プラグイン]]のバージョンが上がっていたので、入れ替えてみる。 /wp-content/plugins/wp-dokuwiki/lib/tpl/default/design.cssも適用されるようで、いろいろ見た目が違ってくる。すべての記事をすべてwp-dokuwikiで書くのならまあ統一もとれるだろうが、管理している某所のように執筆者や記事ごとに記法が違うと、CSSが適用されたりされなかったりで、見た目がバラバラになってしまう。 code や blockquoteくらいは残してほかは使わないようにして、WordPressのthemeに合わせるようにしたい。 リンクの種類にしたがってアイコンがつくなどいろいろありそうだが、パスが違っているのか、ただ置いただけではうまく働かなかった。詳しくはまだ見ていない。