雑記

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|
2007|01|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|11|
2009|02|03|05|06|07|08|10|11|12|
2010|01|03|04|05|06|07|08|09|10|
2011|05|06|09|10|
2012|03|07|09|12|
2013|01|02|04|05|07|08|10|11|
2014|04|05|08|10|12|
2015|01|05|
2016|09|
2024|06|
2025|01|

2006-05-02 [長年日記]

[FreeBSD] TrueType fonts without X11

意外に手間がかかったのでメモ。

背景

Webサーバをサンドボックス(SB)上で運用する環境の管理をしているのですが、このWebサーバで、グラフィックを扱うCGIを設置する必要が出てきました。このCGIは、GDというグラフィックライブラリを使っていて、GDは文字を扱うためにfreetypeというTrueTypeフォント用エンジンを使っています。freetype自体は単独でインストール可能だったので問題なかったのですが、エンジンだけでは当然駄目で、フォントもSBにインストールする必要があります。ところが、Portsのフォント類は、実際には必要ないのに、X11ライブラリのインストールを大前提としていて、WITHOUT_X11オプションも効きません。SBに不要なライブラリをインストールするのはディスクの無駄な上、余計なものがSB内に存在するのはセキュリティ上好ましくないので、X11ライブラリをSBに入れるのは避ける方向での解決を図ります。

フォントのインストール

要点を先にまとめると、インストールしたいフォントのportsを展開だけして、フォントファイルをSB内にコピーするというやり方です。例として、Portsに収録されているwebfontとIPAフォントのインストール手順を書きます。

  1. インストール先のディレクトリを作成する
    # mkdir -p /[sandbox]/usr/local/share/fonts/TTF_en
    # mkdir /[sandbox]/usr/local/share/fonts/TTF_ja
  2. webfontを展開して、コピーする
    # cd /usr/ports/x11-fonts/webfonts
    # make extract
    # cp work/webfonts-0.30/*.ttf /[sandbox]/usr/local/share/fonts/TTF_en
    # make clean
    インストールされるフォントはこんな感じ。基本的な書体はこれで一通りそろいます。
    andalemo.ttf    comicbd.ttf     fonts.scale     timesbd.ttf     verdana.ttf
    arial.ttf cour.ttf georgia.ttf timesbi.ttf verdanab.ttf
    arialbd.ttf courbd.ttf georgiab.ttf timesi.ttf verdanai.ttf
    arialbi.ttf courbi.ttf georgiai.ttf trebuc.ttf verdanaz.ttf
    ariali.ttf couri.ttf georgiaz.ttf trebucbd.ttf webdings.ttf
    ariblk.ttf fonts.cache-1 impact.ttf trebucbi.ttf
    comic.ttf fonts.dir times.ttf trebucit.ttf
  3. IPAフォントをコピーする。portsにはjapanese/ipa-ttfontsがありますが、これはdatabases/grass-i18nをベースにフォントの設定を実行するだけのダミー(?)portsのようです。
    # cd /usr/ports/databases/grass-i18n
    # make extract
    # cp work/fonts/*.ttf /[sandbox]/usr/local/share/fonts/TTF_ja/
    # make clean
    インストールされるフォントはこんな感じ。ipag*がゴシック体でipam*が明朝体です。
    ipag.ttf        ipagp.ttf       ipagui.ttf      ipam.ttf        ipamp.ttf
  4. アプリケーションの設定
    設定はアプリケーション毎に違ってくるので、要点だけ。
    • フォントの探索pathに/usr/local/share/fonts/TTF_en(ja)を指定する
    • 書体とフォントファイルの対応付けを行う(ARIAL->arial.ttf, MINCHO->ipam.ttf, など)

余談

一番手間がかかったのは、フォント探しとライセンスの確認だったり。


2006-05-10 [長年日記]

ホームセンター偵察

近所に新しいホームセンターが出来たので、仕事上がりに見学。1Fがホームセンター、2Fがインテリアという構成で、かなりの床面積を持っているので期待していざ突入。

1Fについては、隣町の某ホームセンターとの比較で、工具:◎、ねじ:○、木材:≒、金物:×(無かったような…)、包装:◎、店舗用小物:○、塗料:≒、電材:△〜×、電化製品:?(興味なし)、日用品:○〜≒、アウトドア:≒、といった感じ。木材の加工場がなかったような気がするのと、金物系の印象が薄いのが気になりましたが、隣町のホームセンターに出かける事は大幅に少なくなりそうな感じでした。前から探していた電子レンジでスパゲッティをゆでられる容器があったので、トイレットペーパーその他と一緒に購入。

2Fは隣町の某ホームセンター隣にある某インテリア屋と比較。と思ったのですが、個人的にはぜんぜんダメ。下とのバランスからして、カラーボックスとかイレクターから高級家具までとかの品揃えを期待していたのですが、お手軽品はほとんど無し、高級品の方も百貨店の家具コーナーみたいな感じでした。椅子コーナーは特にひどく、当店オリジナルと書かれたアーロンチェアのバッタモンみたいなものをはじめ、どこかで見たような形をしているけど微妙にダサいものばかり。カーテンと時計屋はすこし良かったかも。クッションとかは売ってなかったかな。というわけで、2Fは10分で見学終了。

お店を回っていて、ネクタイを締めてるんだけど買い物籠を持っていない、偵察組と思しき男性2,3人のグループが3組ほどいたのにはちょっと笑いました。

電子レンジでスパゲッティ

さっそく挑戦。700Wで標準ゆで時間+4分。うん、ちょっと硬めで、いつも鍋でゆでているのとそん色ないパスタが出来ました。これだったら、朝にトーストと似たような感覚で、パスタとか出来そう。

今回は、あえ物系のソースを使ったので良かったのですが、問題はレトルト系のソースをどうやって暖めるかだな。

ホームセンター偵察(2)

石鹸のストックが切れていたので、今日も突入。

木材加工場は屋外ではなく、木材売り場の奥まった所にありました。金物もよく探せばそこそこありましたが、網棚とかスチールラックが見当たりませんでした。木材も含めて、棚類が充実していないというのが、昨日のなんか物足りない印象に繋がっていたのかも。

あと、屋上駐車場から標識に従って出口に向かったところ、店舗の裏から近くの幹線道路に直接出られるのを発見。正面出口は信号無しの右折になってやたらと時間を食われるので、この裏出口は助かります。地上から回り込む道があるのか、次の機会に探してみよう。

日記の日付

間違えた… orz

最初の2つのエントリは昨日のものです。

本日のツッコミ(全2件) [ツッコミを入れる]

- taru-k [1Fのコストパフォーマンスと現在の混雑具合の情報希望]

- hs [値段は隣町ホームセンターと変わらない感じでした。参考になりそうなものとしては、液体ミューズ詰め替え用:198円、エリ..]


2006-05-12 [長年日記]

インターネット接続不調

GWあたりから、どうも外部への接続が不調で、Nagiosがfalse positiveを出しまくったり、SSHで外部ホストにアクセスするとログインに妙に時間がかかったり。変だなぁと思って調べると、外から逆引きできなくなってる!何でじゃあと思ってさらに調べると、逆引きの権限委譲をしてもらっている上位プロバイダの設定がおかしくなってました。以前、同じ設定ミスをされていたのですが、何かの拍子にそれが復活した模様。DNSの逆引きの権限委譲なんてマニアックな設定なので、作業のお知らせなんかするまでも無いという判断だったのかもしれませんが、それだったら、なおさら完璧にやってもらわないと。

「オープンスペースでの携帯電話の使用禁止」は社内規定にすべきか

お昼ごはんを食べに行ったラーメン屋で、隣に座っていた男性が、店中の人たちが振り返るぐらいの大声で携帯電話で話しだしました。

で、その彼が

  • 建設会社の営業マンであること
  • 資材の手配ミスにより、建築中の物件の作業が遅れていること
  • ミスを起こした相手の名前
  • 物件の所在地
  • 現場の責任者の名前
  • 同僚(ないし上司)の名前
といったことがよく分かる内容を話しまくる訳です。いや、びっくりして目配せしたんですがお構いなし、というか、うるさいという抗議と勘違いしたのか、後半は私と目を合わさないようにして相変わらず大声で結構な内容の話をしまくります。これって会社的にもかなりまずいだろうと思われる内容が、聞きたくも無いのに耳に飛び込んでくるわけです。

会話の中には専門用語も入っていたので、私にはちんぷんかんぷんな部分もありましたが、建設業に明るい人であれば、もっと情報を取得できたに違いありません。自分の会社の業務内容に当てはめるとぞっとします。

いや、鬼に金棒…じゃないか。馬鹿に鋏と言うか、倫理観の無い人間に仕事で携帯を使わせるとこういうことになるんですね。表題のようなことを真面目に考えさせられる出来事でした。

本日のツッコミ(全1件) [ツッコミを入れる]

- taru-k [まぁそれは、携帯電話が悪いのではなく、社員教育の問題かと.]


2006-05-13 [長年日記]

[Ajax][IE][Firefox] 外部ファイルを取り込む際の文字化け対策

既存のCGI群をAjaxで書き直す作業をやってもらったところ、XMLHttpRequest()で取得したソースが、物によって文字化けしたりしなかったりするという報告が上がってきたので調査。IE6とFirefox(1.5.0.3)で試しました。私の調べた範囲では、Safari(1.3.2)の場合、IEやFirefoxで文字化けするページが、文字化けしませんでした。また、他のブラウザは調査する根性がありませんでした。あと、検証はEUC-JPでしかチェックしてません。本エントリは他で公開されている情報を補足するものであり否定するものではありませんし、JavaScript++かも日記bricklife.weblog.*(敬称略)による網羅的なまとめが無ければここまでたどり着くことは出来なかったでしょう。お二方をはじめ、本件に関する情報を先立って公開して下さった皆様に、まずは感謝の意を表します。

関連するページの記述によると、基本的な対策としては文字コードをUTF-8にすると言うことらしいのですが、静的なファイルはともかくCGIまで含めてUTF-8対応させる余裕はありません。また、手元のデータの中には、CGIであるのに文字化けするものとしないものがあったりして、既存の調査結果と一見矛盾していました。さらに、いくつかのページで書かれていた、CGIだと文字化けしないが静的なファイルだと文字化けする、という結果は、プロトコル、およびクライアントの実装手法的にどうしても納得できませんでした。こうしたことから、既存の実験には、なにがしかの条件が不足していたのではないかと考え、とりあえず手元のCGIの場合の文字化けの有り無しで、出力されるデータを比較しました。

結果、文字化けしないCGIでは

Content-type: text/html; charset=EUC-JP
と出力していたのに対し、文字化けするCGIでは、
Content-type: text/html;
とだけ出力していました。これを見たとたんにapacheの挙動に思い至り、文字化けの原因が「htmlかcgiか」の違いではなく、「HTTPレスポンスのContent-typeに正しいcharsetが記述されているかどうか」の違いであると仮定したところ、これまでの自身の実験結果や他のページでまとめられている、一見不可解な挙動がすっきりと説明できます。つまり、ルールとしては
responsTextの場合
  • HTTPヘッダーフィールドのContent-typeで指定されたcharsetは正しく解釈される。
  • HTMLヘッダーの<META>タグを使ってContent-typeで指定されたcharsetは無視される。
responseXMLの場合
  • HTTPヘッダーフィールドのContent-typeで指定されたcharsetは正しく解釈される。(←というのは検証の結果、IEでは間違いと判明)
  • encoding属性も正しく解釈される。
と言うシンプルなものに落とし込むことができ、実装についても妥当と思えるものが容易に想像できます。

あとは実験。apacheの設定を変更して、EUCで書かれた静的なHTMLファイルの取得時には、charset=EUC-JPを含むContents-typeを返すようにしたところ、IE、FirefoxともにresponseTextでも文字化けしないようになりました。一方、responseXMLの場合、IEでは、Content-typeの方は無視されて文字化けしましたが、FirefoxではContent-typeのcharsetが正しく解釈され、文字化けしなくなるという結果でした。表にまとめると、以下のような感じです。

responsTextresponseXML
Content-typeMETAタグ
IE×
Firefox×
Content-typeencoding属性
IE×
Firefox

というわけで、XMLHttpRequest()の文字化けに対するWorkaroundとしては、responsTextを使用する場合、単純にHTTPレスポンスのContent-typeで正しいcharsetを返すようにサーバを設定/CGIを実装する。responsXMLを使用する場合、encoding属性を指定する。という事で大丈夫なようです。

apacheで正しいcharsetを返すための設定方法

全てのレスポンスでcharset=EUC-JPを返すというのは乱暴なので、正しいcharsetを返すための設定方法について調べてみました。何通りかやり方があるようです。

ファイル名で区別する
mod_mimeが有効になっている(デフォルト)場合、ファイル名の拡張子の複数指定を使った設定ができます。例えば、設定ファイルの適切な場所(後述)に、
AddCharset EUC-JP .euc
という行を追加してapacheを再起動し、EUC-JPを含むファイル foo.html/bar.txt を foo.euc.html/bar.euc.txtのように名前変更すると、foo.euc.html/bar.euc.txtにアクセスがあった場合に、charset=EUC-JPがつくようになります。ファイル名とリンクの変更が必要になるので、既に大量のファイルがある場合、ちょっと嫌かも。
ファイル単位で指定する
取り込まれる静的なファイルが決まっていて、少ない場合は、ファイル単位で指定することもできます。
<Files /path/to/foo.html>
AddType "text/html; charset=EUC-JP" .html
</Files>
<Files /path/to/bar.txt>
AddType "text/plain; charset=EUC-JP" .txt
</Files>
ちょっとトリッキーですね。FilesMatchもありますが、アクセスの度にファイル名と正規表現の比較が入ることになるので、これを使うぐらいなら上か下の方法を使うのが良いと思われます。
ディレクトリ・ロケーション単位で指定する
未検証ですが、上記FilesをDirectory とか Location に置き換えれば、できるはずです。日本語ページと英語ページでディレクトリを分けている場合、一番お手軽な方法かも。
このぐらいのバリエーションがあれば、たいていの場合は正しいcharsetを返せるようになるんじゃないでしょうか。

で、上記設定ですが、apacheの設定ファイルで「AllowOverride FileInfo(だと思う)」が指定してあれば、.htaccessファイル内に記述することによって標準の設定を上書きできます。管理者権限が無い場合は、試してみる価値はあるかもしれません。が、ファイルアクセスのたびに.htaccessが読み込まれ、そこから条件比較という手順を踏むようになるので、パフォーマンスが落ちること間違いなしです。

超余談

で、ふと思ったのですが、これってCSSXSSで'{'や'}'に該当するコードを含む日本語文字の入ったHTMLファイルも脅威にさらされるという問題の、サーバ側でのWorkaroundになったりは…しないかな。


2006-05-15 [長年日記]

ソフトバンクモバイル

ボーダフォン改め、だそうです。

電話機にロゴを入れることを考えると、社名はせいぜい8文字までだと思うんですが。SBMとか略称使うつもりなら、なおさらもっと洗練された短い名前を考えた方が良いのに。あと、モバイルってどちらかというと携帯電話向けサービスの一般名称として定着しているので、かなり違和感があります。お、sbm.ne.jpは未登録ですね。今すぐダッシュだ。というか、この辺を押さえずにリークしているって事は、世間の評判を見極めたいだけかな。

ブランド名も統一するそうですが、「ソフトバンク」という字面は統一ブランドの冠言葉としては、あまりにも偏りすぎな気がします。コンピュータソフトウェア流通会社としては、センスの良い名前だとは思いますが。ヤフーはアメリカ法人傘下のように見えてしまうので却下として、いっそのことグランド・サン(grand-son)グループとかにすれば、洒落もきいて良かったのに。

本日のツッコミ(全1件) [ツッコミを入れる]

- taru-k [“グループJUSTICE”も良いね.ソフトバンクって、年配の方には“新手の銀行”だと思われていないのだろうか.モバイ..]


2006-05-17 [長年日記]

なんだなんだ

本業の方がちょっとした山場に入ったと思ったら、個人的な依頼やら前職のフォローアップやらがぽこぽこと。

ひー。


2006-05-18 [長年日記]

仰天

ルノーF1→ニッサン F1へと名称変更という憶測があるそうです。「将来の話」としながらもチーム代表が否定していないところがなんとも。

開発に日産側の技術者が入っていくという話なら、引っかかりは残るもののまだましかなと思いますが、単なるバッジ・ネームだと悲しい話ですね。一般的には知名度が上がるのかもしれませんが、ファン心理的にはむしろ日産に、「あなたは堕落しました」とか言いたくなりそうです。

本日のツッコミ(全3件) [ツッコミを入れる]

- mak [以前より有名な話でルノーのスタートシステムは日産の技術者が開発してます。すでに技術者交流はしてるのよね。]

- hs [なるほど。そうすると現状でも共同開発状態みたいなもんか。 いずれにせよNISSANのバッジをつけるなら、それなりの..]

- taru-k [アロンソの後釜に本山を使うしかない.]


2006-05-19 [長年日記]

ガソリン価格

いつも入れているシェルがハイオク139円/L(レギュラー128円/L)でがんばってました。5月頭の一斉値上げに乗らなかったようです。観察していると、他は軒並み142-3円になっていたので、ちょっとうれしい。

本日のツッコミ(全2件) [ツッコミを入れる]

- taru-k [私が入れているJOMOは、表示はハイオクが\142だけど入れてみたら\139でした.特に会員でも何でもないのだが、こ..]

- hs [実際より高い価格を表示する理由が分かりませんね。カード価格? カルテル破りの偽装工作とかいうのは、陰謀論者的過ぎま..]


2006-05-23 [長年日記]

も〜いや。今日は寝る。

デスマーチから抜け出せない… もうちょっとだと思ったのに。


2006-05-24 [長年日記]

Google AdSense導入

お仕事方面で少し前から関心があったのと、表示される広告によってそのページがどういう風に判定されるかを見るという楽しみ方があるというのを知り、ちょっと入れてみました。いや、お金が入れば正直うれしいですが、そんなにビューの多いページではないので、過剰に期待せずに。このページのgoogleによる評価と思って読む人にも楽しんでもらえれば。

と書いたところで、さっそく表示されたまともな広告は、「商品先物」と「迷惑メール対策」でした。後者は納得いきますが前者はどこからきたんでしょう?あと、英語の広告が混ざるのはなぜ?それに、Firefoxの紹介バナーを付けたつもりなんですが、表示されません。時間差があるのかな?

さて、現実逃避もほどほどにしないと。