8月 242011
 

Firefox が 12 週間に一回バージョンアップするというとんでもない所業に出て、つい最近 Firefox6 が出たんですが、こいつがなんかむちゃくちゃ CPU を食いまくる。起動直後なんて一人で一個の CPU を使いやがる。ってんで Firefox の利用は最近断念しつつあります。

と、言うことで何か別のブラウザを捜すべ。とか思って色々調べてみたのですが、 QT ベースのブラウザってのは結構色々あるんですね。 arora だとか rekonq とか QtWeb (これは ports になってない) とか。

けど、結局 QT ベースブラウザってどうあがいても emacs キーバインドが利用できないみたい。

ちょっと話はそれますが KDE4 のアプリケーション群の中で emacs キーバインドが設定できるのは kwrite だけなんですよね。で、こいつの設定の「ショートカットを設定」を見ると 「Kateコンポーネント」ってのがあって、これが編集時のショートカットキーの変更を可能としている。

ちゅーこって KDE4 ではショートカットの設定のところで「Kateコンポーネント」を全てで編集できるようにすれば emacs キーバインドが可能になるのになぁ。と思うのでありました。どっかで呼びたせたりしないのかなぁ。

 
で、ここで話はブラウザ全般のネタに戻るのですが、以下ちょっと色々書いてみます。

 
・chromium
QT ベースのブラウザは emacs キーバインドが利用できないので www/chromium をインストールしてみました。 Chrome のオープンソース版と言えば良いのかな? こいつは Firefox6 よりも CPU 利用率が低いみたいなのでまぁ常用できるかもしれない。

それにしても chromium で emacs キーバインドはできないのかな?とか調べたら GTK2 側で emacs キーバインドの設定をすれば良いと言うことが解ったので早速やってみました。

% cd /usr/local/share/themes/Emacs/gtk-2.0-key/
% cp gtkrc ~/.gtkrc-2.0

 
これだけ。普段 KDE4 とか利用していると GTK2 のこととかほんとにわかんない。僕だけかもしれないけど。で、この設定を入れるとほぼ全ての GTK2 アプリは emacs キーバインドになるみたいです。Firefox の場合はアドオンで firemacs 入れているので気にならないのですが、 Thunderbird3 とかも emacs キーバインドになってくれたりします。すげー;-)。

 
・midori
GTK2 的なブラウザとしてはもう一個 www/midori を試してみました。インストールしてから起動すると・・。ふむー。随分と前時代的な雰囲気を醸し出していますf(^^;;。細かい設定は「設定」→[エクステンション]として全て項目にチェック付けてと・・。とかします。

ツールバーの設定などはブラウザではできなくて、~/.gtkrc-2.0 に項目を追加していくと言ういかにも UNIX ライクな設定方法ですf(^^;;。そして、見かけは本当に”GTK2 ベース”って感じです。多分常用はしないと思われますが pkg_delete もしていません;-)。

 
・arora
QT ベースのブラウザです。まぁ、非常に質素である意味 midori に通じるものがあるかもしれません。konqueror の不要な部分を全部削ぎ落して軽量化したって感じのブラウザです。けどもまぁ、QT ベースなので KDE4 上で利用する分には割としっくり来ますかね。

フツーに問題なく利用できます;-)。

 
・QtWeb
QT ベースのブラウザです。Windows 版もバイナリで配布されています。arora と一緒で本当に質素・軽量なブラウザです。 FreeBSD では ports になってないので自分で make して、チロッと起動して動作確認などをしただけです。

FreeBSD で make するには QT4 の CJK なプラグインが必要になります。 japanese/qt4-codecs-jp 相当の中国・韓国・台湾版をインストールします。まぁ、ソースを変えて libqjpcodecs.so しか呼ばない(リンクしない)ようにすれば良いだけなんですけどね。 一応 make は通って起動はできます。ただ、 ports する意味あるの?って感じがするので僕は ports を作ってませんが;-)。

 
・rekonq
僕的には本命のブラウザですなぁ www/rekonq 。名前的に「konqueror よ再び。」みたいな感じ、車輪の再開発とか。 konqueror の悪いところを削ぎ落して再度作り直しましょう。みたいな感じのブラウザらしいです。

とりあえずキャプチャなどを。下が konqueror 、上が rekonq です。

rekonq.png

見た感じ・使った感じは Safari と Chrome の良いところを取り込んで konqueror の悪いところがちょっと残った。と言うような感じでしょうか;-)。

機能も konqueror 程度にはあるし、何よりも konqueror よりも安定している感があります。 kubuntu では rekonq が default ブラウザになったんだっけか?

FreeBSD では ports からインストールしても日本語対応していません。 ja な mo ファイルが無いんですな。あいや・・。しょーがないので kubuntu のを持ってきてしまいましょう;-)。

以下の URL から language-pack-kde-ja-base_10.10+20110618_all.deb を拾ってきます。

http://pkgs.org/ubuntu-10.10/ubuntu-proposed-main-i386/language-pack-kde-ja-base_10.10+20110618_all.deb.html

そのあとは以下の要領でインストールすると rekonq の日本語化ができます。

% mkdir deb
% cd deb/
% mv ~/language-pack-kde-ja-base_10.10+20110618_all.deb ./
% ar -vx language-pack-kde-ja-base_10.10+20110618_all.deb
% tar xvzfp data.tar.bz2
% cd usr/share/locale-langpack/ja/LC_MESSAGES
# cp rekonq.mo /usr/local/kde4/share/locale/ja/LC_MESSAGES/

 
一部翻訳されていないところも有りますがほぼ問題ないほどに利用できるでしょう。

利用した感想ですが、konqueror よりは遙かに良いと僕は思います。これが default ブラウザでも問題無いと思います。「KDEシステム設定」の中の「デフォルトのアプリケーション」のブラウザとして設定しましたが、各アプリの URL をクリックするとスルスルっと konqueror よりも軽やかに起動するみたいな感じでしょうか。

ただ、本当に KDE4 のアプリと言うか QT ベースなのでやはり emacs キーバインドは利用できないですね。長文書く時、僕はダメです。

と、言うことで Firefox6 と言うか、 Firefox がこれからドンドン変な方向に進んで行きそうなのでそろそろ潮時かぁ? とか思いブラウザを試してみましたが、サイトを見るときは rekonq 、文章を書く時には chromium 。って感じになりそうです。

あ。最後にですが、筆者は Flash などいうのはまるで見ません。プラグインインストールしていません。ブラウザの設定で「プラグインはロードしない。」をわざわざ選択しています。iOS ユーザにとって Flash プラグインは必要無い。みたいな;-)。

8月 212011
 

僕的には久しぶりの「CPU コレクション」の第 41 回目。Socket370 の最後の CPU を掲載しましょう。前回の VIA CyrixIII の後継 CPU になりますね。

VIA が Cyrix を買い取って、だけど、技術者はみんなやめてしまって残ったのはブランド名だけだったんだけど、そのブランド名さえもはずしてしまった CPU。と言う感じでしょうか。

Socket370_VIA_C3_1.jpg

デザイン的には VIA CyrixIII と一緒なのですけども “Cyrix” と言う文字が見当たりません。

こちらが CPU の裏側。基本的には Socket370 なので Intel の CPU などと一緒ですね。

Socket370_VIA_C3_2.jpg

そしてちらが二つの CPU を並べた写真。一応、比べるために撮ってみました。

Socket370_VIA_C3_3.jpg

この後 VIA は Intel のソケットのライセンスを購入せずに(できなかった?) AMD と同様独自路線を歩むようになります。組み込み省電力へと特化していくため、Eden として CPU を作り続けていくのでありますが、Intel の Atom シリーズに手痛い目に遭うんですなぁ・・。まぁ、この辺りの話になると「つい最近」の出来事になるのでその点については皆さん既にご存じかと思われますが;-)。

さてと。これで手持ちの前世代の CPU は全て終わりました。ここから先、Intel は Pentium4 へ、 AMD は Athlon X2 へと進んでいくわけであります。この辺りになると皆さんもうきっと僕よりも詳しいと思うのですけどもね。

それにしてもこのカテゴリー、Socket7 から話しが始まり随分と長い間続きました。が、もうしばらく続きますf(^^;;。と、いうことで次回からは非 x86 な CPU について何回か掲載して行きたいと思います。

手持ちの CPU は実はまだまだたくさんあるのでありますよf(^^;;。

8月 172011
 

僕は 「Microsoft TechNet サブスクリプション」の会員なので Microsoftの Windows Live のアカウントとか持っていて Windows Live にもアクセスするし SkyDrive も利用したりしています。

Windows Live の中には「ダウンロード」と言う項目があって、Windows Vista 以降で利用できるアプリケーションが無料でダウンロードできたりするのですが、今回はその中の一つである Windows Live Mesh についてちょっと書いてみようと思います。

Microsoft のダウンロードサイトにおける Windows Live Mesh の説明文には以下のように書かれています。

「写真とドキュメントをコンピューター間および SkyDrive 上で同期します。お使いのコンピューター上のすべてのファイルやドキュメントにリモートで接続します。」

これだけだと「特に利用する必要ないかなぁ。」とか思ってしまうのであります。だって、写真は「フォト ギャラリー」でアクセスできるし、ブラウザから SkyDrive でアクセスすれば共有もできるしねぇ。みたいな。

けど、色々「Windows Live Mesh」について調べていたら恐ろしいことができることを発見してしまいました。今回はそっちをメインにちょっと書いてみます。

まずは http://live.jp/ にアクセスしてアカウントが無い人は作成し、持っている人はそのままログインします。

左上の “Windows Live” って文字をクリックするとプルダウンメニューが現れるので[ダウンロード]を選択し、Windows Live Essentials から Windows Live Mesh をダウンロードしすかさずインストールします。
あ。ちなみに Windows Live Essentials を利用できるのは Windows Vista 以降の WindowsOS のみとなります。WindowsXP にはインストールできません。

Windows_Live_Mesh_1.png

Windows Live Mesh のインストール後、起動して Windows Live ID でログインします。あとは基本的にはバックグラウンドで動作している状態でしょうか。表示されるメニューには「状態(S)」と「リモート(R)」の二つがあります。今回は「リモート(R)」のほうが重要になってきます。

左上のほうに「このコンピュータへのリモート接続」という項目があると思いますが、そこで「このコンピュータへのリモート接続を許可」をクリックします。権限などを聞かれますがとりあえず許可してみましょう。

Windows_Live_Mesh_2.png

でもってここで http://live.jp/ にログインしているブラウザに戻ります。

やはり左上の “Windows Live” の文字をクリックしプルダウンメニューを表示させ、今度は [Devices]というのをクリックします。するとここには Windows Live Mesh をインストールした PC の一覧が表示されるようになります。

自分が持っている PC がたくさんあり、そのほぼ全ての PC 上で自分の Windows Live ID で Windows Live Mesh が起動されているとその一覧が表示されるようになります。

別の PC からブラウザで live.jp にアクセスし [Devices] メニューをクリックすると Windows Live Mesh でリモート接続を許可された PC は「このコンピュータに接続」という項目が表示されるようになります。

Windows_Live_Mesh_3.png

あとは「このコンピュータに接続」をクリックすると Active-X がインストールされ RDP みたいに画面が飛んできてリモート接続で作業が行えるようになります。

上にも書いたとおり Windows Live Mesh をインストールできるのは Windows Vista 以降の WindowsOS のみです。 WindowsXP では Windows Live Mesh がインストールできないのでリモート接続の対象機器にはなれませんが、クライアントとしては動作します。WindowsXP でブラウザから live.jp にアクセスし [Devices] から PC を選択し、リモート接続することは可能です。

さてさて。以上が Windows Live Mesh を利用したリモート接続の方法と言うか機能になります。それにしてもこれはちょっと驚きますね。例えば自宅から会社の自分が利用している WindowsOS にアクセスできる。ということになります。

企業ではファイアーウォールを設置し、そして外部からのアクセスには VPN などを利用したりしての接続、また、部署・人によってのアクセス権限などを行っているかもしれませんが、そんなの一切お構いなし。 Windows Live Mesh 経由でズドーンっとリモート接続してしまうのでありますなぁ。

企業の IT 部門は VPN 装置必要なくなるけど、セキュリティ・情報持ち出しなどに気を使うようになります。すると Windows Live Mesh のリモート接続を L4,L7 レベルで止める(実質的には SSL なので多分無理だとは思いますが)か PC 側に Windows Live Mesh にインストールできないもしくはされていた場合削除するなどの対応が必要かもしれないですねぇ。

どっちにしてもすごい技術だとは思うのですが、企業の IT 部門にとっては頭の痛いネタ(技術)が増えたと言うかんじでしょうか。

#最後の終わり方、ITmediaチックかな?;-P。

8月 102011
 

以前、このブログのエントリで「mozc-emacs(mozc.el) な ports 作りました。」ってのを書きました。でもってノラ pors を作って置いておいたのですが、NakataMaho さん が commt してくだり、ports として組み込まれました。ありがとうございました。

で、前回の記事とコメントに書いているのですが、 FreeBSD の ports になっている mozc は随分とバージョンが古い。おかげで mozc-el はかな入力に対応していない。など書いていたのてすが、本日 csup したら japanese/mozc-el が mozc の最新版になりましたね。うれしーっ!!

ってんで、早速 japanese/mozc-el を make install したのですが、なんとなっ!! mozc-server のバージョンが古いので mozc.el と一緒にインストールされる mozc_emacs_helper が mozc-server と通信できない・・。orz。

daichi さん はいつ japanese/mozc-server をバージョンアップしてくれるのだろう・・。とか思いつつ、やっぱり ports ができる(リリースされる)まで待ってられないのでとっとと自力で最新版を make してしまいましょう。

その手順を今から書きます。

1. フツーに ports から japanese/mozc-server、 japanese/mozc-tool 、japanese/mozc-additions をインストールします。この段階では mozc は 0.13.523.102 がインストールされます。
2. インストールが完了したら mozc_tool とか mozc_tool_config などを起動して、入力設定とか全部の設定を済ませてしまいます。

以上が前準備です。続いていよいよ mozc-el のインストールです。

3. japanese/mozc-el をインストールします。これで mozc の 1.1.773.102 のバージョンのソースコードを持ってきて mozc.el と mozc_emacs_helper の最新版がインストールされます。
4. japanese/mozc-server の環境を以下のように整えます。

# cd /usr/ports/japanese/mozc-server
# mv files files.orig
# cp -pr ../mozc-el/files ./
# cp -pr ../mozc-el/distinfo ./
# vi Makefile

 
5. japanese/mozc-server の Makefile の以下の行を変更します。

    :
PORTVERSION=    1.1.773.102
#PORTREVISION=   1
    :
${PYTHON_CMD} build_mozc.py build_tools \
-c ${BUILD_MODE} ; \
${PYTHON_CMD} build_mozc.py build \
-c ${BUILD_MODE} \
server/server.gyp:mozc_server
    :

 
ちょっと説明すると、
・PORTVERSION は最新版のバージョンにします。
・PORTREVISIONの行は削除します。
・–qtdir=${QT_LIBDIR} オプションを消します。

後は make NO_CHECKSUM=yes (distinfo をコピーした場合は NO_CHECKSUM=yes は必要無し) して make 、 その後は make deinstall;make reinstall すれば mozc-server も最新のものになって mozc.el と通信できるモノがインストールされます。

今回は japanese/mozc-tool はインストールしてないので古いバージョンのままとなっていて、多分正常に動作しないと思われます。なので、一番最初に mozc の設定をばっちりとやってしまいましょう。となるのであります;-)。

さてさて。mozc が最新版のバージョンになると mozc.el が動作し、emacs ではミニバッファで文字の選択ができるようになります。また emacs -nw の状態でも日本語入力ができるようになるので、 WITH_CANNA のときみたいに emacs が非常に嬉しく使えるようになるのであります。

それにしても mozc-server の ports は、メンテナの方、早く更新してくれないかなぁ。と思うのでありますが、今回のインストール方法は ports の japanese/mozc-server のバージョンがアップするまでの一時的な策ということで;-)。

それにしても NakataMaho さん。ありがとうございました。

8月 082011
 

現在、自宅のサーバは 7.4-STABLE でデスクトップ PC と NotePC は 8.2-STABLE にしています。そして、IPv6 ルータとして動作しているちょっとワンパクな EeePC は 7.4-STABLE だったんだけど、これを 9.0-BETA1 にしてみました。

このブログでは過去に何回か EeePC について取り上げていたのですが、8 系 STABLE もちょっと怪しい動作だったので 7.4-STABLE にしていたのだけど、それでも動作が怪しいので今回自宅内の FreeBSD の中ではいち早く 9.0-BETA1 にしてみた。という感じです。まぁ、インストールされている ports の数が一番少ない。ってのもあるんですけどね;-)。

では早速 9.0-BETA1 をインストールした感想などを書いてみたいと思います。

0. EeePC のシステム構成
EeePC は内蔵の SSD が 4GB しかないので 60GB の外付け USB HDD を接続し、そこに FreeBSD をインストールして起動しています。

ルータなので NIC は二個利用しています。一個は内蔵 NIC の ae0 です。もう一個は USB の BUFFALO LUA2-TX LUA2-TX と言うヤツで、これは 7.4-STABLE では aue0 として認識されていました。

内蔵無線である ath0 は今回利用していません。

1. インストーラ変わったね
最初、9.0-BETA1 を CD-R に焼いて、母艦に EeePC で利用する HDD を接続して久しぶりにクリーンインストールしようかと思ったのですが、インストーラが大きく変更されていて焦りました。母艦の HDD をケーブルからはずせば良かったんだけど、接続したまま CD で起動したら母艦の HDD しか認識してくれない。
USB HDD は通常 /dev/da0 とかで認識されるんだけど、見えなかったのでシューリョー。って感じ。結局、CD-R からのクリーンインストールは諦めました。

2. csup からバージョンアップ
EeePC は 7.4-STABLE の状態で起動するのでこの状態で csup して一気に CURRENT に持って行きます。 EeePC の CPU は遅いので make buildworld+make buildkernel は大体 14 時間位かかりました。orz。

9.0-BETA1 の起動後に注意する点としてはやはり USB 回りですね。以前に書いた「FreeBSD RELENG_8 で USB 機器からブートする。」って設定が必要です。
あと、7.4-STABLE からのバージョンアップの場合、すっかりと忘れていた(8 系 では既にそうなっいる)のですが、USB コントローラもカーネルモジュールになっていたのですね。カスタマイズカーネルを利用する場合には /boot/loader.conf に uhci.ko ohci.ko ehci.ko をロードするようにしないと、USB が一切認識してくれないです。

とまぁ、こんな感じで /usr/src/Makefile の中に書いてある手順に従うとバージョンアップが終わります。

あ。一点書いておきましょう。make delete-old とか make delete-old-libs するとひたすら “y” と打たなければならずかぁなりしんどい。そんな場合は以下のコマンドを;-)。

# yes | make delete-old

 
ドドドと削除してくれます;-)。

4. ports のインストール
ports の make config のときの青い画面の動作がちょっと変わってビビリました。[X] hoge でメニューを選択したあとに TAB キーを押すと [ OK ] から [ CANCEL ] にカーソルが動いてしまう。選択したら TAB キーを押さずにそのままリターン。みたいな感じになりました。

それにしても emacs のインストール時、全てのオプションを WITHOUT_hohe=true にしたのに X をインストールしようとしてしまう。 /etc/make.conf には WITHOUT_X11=yes って書いてあるのにねぇ。なので emacs は結局 ports からインストールせずノラビルドでインストールしました。

ちなみに サーバの場合、/etc/make.conf には以下が書いてあると良いかと思われます。

WITHOUT_X11=yes
WITH_THREADS=yes

 
WITH_THREADS=yes を書くと perl とか python は -threaded でインストールされます;-)。

3. 起動後の各種設定
/etc/rc.conf のネットワーク設定がガラリと変わりました。これはじっくり見て正しい設定をしたほうが良いかと思われます。

IPv6 回りで気がついた点として ipv6_enable=”YES” が無くなり ipv6_activate_all_interfaces=”YES” になりました。

でもって ipv6_activate_all_interfaces は “YES” でない場合は ifconfig_IF_ipv6 で判断して、 “_IF_” のインターフェースにしか link local アドレスが付加されません。今までは全てのインターフェースに link local が付いていただけに「すげー。」とか、ちょっと思います;-)。
ちなみに link local が付加されないインターフェースってのは「IPv6 を利用しないインターフェース」って認識で良いと思います。

あとは、alias アドレスの設定方法が変わりましたね。 IPv4/IPv6 で同一の設定になりました。

ipv6_prefix_IF=”” の設定も驚きました。今までは最後に “::” とか付けていたのですが、これを付けるとダメみたいです。

以下、簡単な例です。

defaultrouter="192.168.1.254"
gateway_enable="NO"
ipv6_defaultrouter="NO" ipv6_gateway_enable="YES"
ifconfig_ae0="inet 192.168.1.192 netmask 255.255.255.0" ifconfig_ae0_alias0="inet 192.168.1.253 netmask 255.255.255.0"
ifconfig_ue0="DHCP"
ipv6_activate_all_interfaces="YES" #ipv6_network_interfaces="auto" #ipv6_default_interface="ae0"
ipv6_ipv4mapping="NO"
ipv6_prefix_ae0="3ffe:3e0:a71:fee1"
ifconfig_ae0_ipv6="inet6 3ffe:f3e0:fa71::1 prefixlen 64"
ifconfig_ae0_alias1="inet6 3ffe:f3e0:fa71::ffff:2 prefixlen 64" ifconfig_ae0_alias2="inet6 3ffe:f3e0:fa71::22:1 prefixlen 64"
rtadvd_enable="YES" rtadvd_interfaces="ae0"

 
あ。aue0 名前が変わりました。8 系からかな?僕は 8 系で aue0 使ったことないので解らないのて゛すが ue0 になりました。wlan0 と一緒で USB NIC は全て ue0 になるのかなぁ? USB NIC は一種類しか持ってないので良く解らないのですが。

4. はまり道
上記 IPv6 のネットワーク設定をしたのですが、一番はまったのは gif0 に link local アドレスが付加されない。ってところでしょうか。gif0 に link local が無いので IPv6 ルーテイングができずにかぁなり焦りました。

で、詳しい方に irc で教えてもらったのですが、 /etc/rc.d/auto_linklocal があるとダメらしいです。合わせて /etc/rc.d/network_ipv6 も残っていたりする。この二つの rc ファイルは 8 系までのファイルで 9 系というか、現在の CURRENT では不要なファイルになっています。

/usr/src/Makefile 内に書かれている内容でバージョンアップするのですが、そのとき 9. mergemaster ってのがあって、それを実行します。この時、以下のように聞かれます。

*** Checking /etc/rc.d for stale files
*** The following files exist in /etc/rc.d but not in /var/tmp/temproot/etc/rc.d/:
auto_linklocal network_ipv6
The presence of stale files in this directory can cause the dreaded unpredictable results, and therefore it is highly recommended that you delete them.
*** Delete them now? [n]

 
ここで「削除するのはイヤ。」とか思いとどまって “n” などと叩いてしまうと gif0 に link local アドレスが付加されることは無いのであります。上記二つのファイル (auto_linklocal と network_ipv6) は CURRENT では既に不要なファイルなので、サクッと “y” を叩いて削除してしまいましょう;-)。

あとは ipfw の設定とかまだもう少し残っていたりしますが、一応ここまでがこの週末に行なった作業なのであります。
あとはもう少し使い込んでみてから色々やってみたいと思います。 ath0 なんかも試してみたいですね。

CURRENT に慣れてきたら NotePC とかデスクトップ PC に導入したいと思います。

それにしても /etc/default/rc.conf はじっくりと眺めたほうが良いかもしれないです;-)。あ。あと man rc.conf(5) も;-)。

8月 042011
 

okular というのは KDE をインストールすると利用できる PDF を閲覧するためのソフトです。Acroread よりも軽いので僕は Acroread をインストールせずにこればっかり利用しているのですが、時々日本語が表示できない PDF ファイルが存在するのでちょっとコマリモノなのでありました。

最初はほっといてそー言う PDF ファイルはあきらめることにしていたのですが「まぁ。いっちょ調べてみるか。」と言う気になったのでありました。

あ。今回は多分、FreeBSD に特化したネタになると思います。 ubuntu には多分、まぁるで関係の無いお話だと思います。

で、調査を開始したのですが、まずは「敵」つまり PDF ファイルを知るところから始めます。 okular で日本語が表示できない PDF ファイルを Windows 版の Acroread10 で表示させ色々情報を取得するのですが、大体以下のようなことが解ってきました。

o. iText と言う PDF プリンタを利用した PDF ファイル。
o. どうやら PDF 自体にフォントが無いようだ。
o. Windows 版 Acroread では代替フォントで表示してくれるねぇ。
o. PDF ファイル自体のフォントは HeiseiKakuGo-W5 と言う名前ですねぇ。

iText というのは今回ちゃんと調べてないんですけども、Java ベースの Acrobat4,5 互換の PDF プリンターってイメージです。出力された PDF ファイル自体にはフォントは埋め込まずビューワのほうでフォントをマッチさせるみたいですね。

さてと。以上が日本語表示できない PDF ファイル自体の調査ですが、ここからは okular の調査の開始です。

そもそも、okular が代替フォントに日本語を含むフォントを指定できないのが問題でないの?と思うわけです。[設定]のところに「代替フォント」とか項目があれば簡単に話は済んでしまうんですけどもそんなのはありはせんのです・・。orz。

で、 okular の調査は更に続くのですが、PDF ファイルの表示には poppler というのが深く絡んできていてこいつは fontconfig とも密接に絡んでくる。ということが解りました。 poppler というのは xpdf からの派生と言うか発展形のモノらしいです。こいつは graphics/poppler や graphics/poppler-data とからみ合って日本語を表示してくれるらしいんですな。

けれど、その poppler が okular とどこで結びついているのか全く解らない。okular のコード見ると Qt と絡んでいるは伺えるんだけどもね。あー。Qt 的には graphics/poppler-qt4 というのもありますねぇ。

okular を起動して [ファイル]→[プロパティ]から表示されるダイアログの「フォント」タブに現在利用しているフォントが表示されます。

このキャプチャは日本語が表示できないときのフォント。

Okular_font1.png

HeiseiKakuGo-W5 に対応するフォントとしては Bitstream Vera が選択されたことが解ります。この Bitstream Vera は日本語を持ってないので日本語が表示できない。ある意味納得。けど、そしたらどうしてそのフォントが選択されるんだろう?と悩むわけです。

そーこーしている間に「これはどうやらまじめに ~/.fonts.conf を書かなければならない。」と思えるようになってくるわけです。

色々調べて書きましたよ。fontconfig の設定は /usr/local/etc/fonts/ になるんですけども、この中に conf.avail/50-user.conf と言うファイルがあるんですね。このファイルの中を見ると、参照先が書かれているのでそこにファイルを一個用意してあげます。

僕の場合、 mkdir ~/.fonts.conf.d/ したあとにこのディレクトリの中に以下のフアイルを置きました。ファイル名は 51-HeiseiKakuGo-W5.conf にしました。 50-user.conf の次の番号ということで 51 にしました。そのあとの HeiseiKakuGo-W5 の部分は好きな文字列を指定できます。数値と .conf は変更することができません。

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
    <dir>/usr/local/lib/X11/fonts/sitefont</dir>
    <alias>
        <family>HeiseiKakuGo</family>
        <prefer>
            <family>MS ゴシック</family>
        </prefer>
    </alias>
</fontconfig>

 
さてと。設定が終わったので再度 okular を起動します。どうだっ!! あやや・・。orz

実は family の部分ですが、 HeiseiKakuGo-W5 と書いてもダメでした。上のように HeiseiKakuGo と書いたら Bold フォントは MS ゴシックになったのですが Regular フォントは相変わらず日本語が表示されない。

上記のダイアログはこんな感じ・・。そんなバナナ・・。orz。

Okular_font2.png

上二個のフォントは MS ゴシックを利用できるようになりましたが、下の二個のフォントは今まで通り Bitstream Vera を参照しているようです。orz。ダメだこりゃ (c)いかりや長介。

もう一度仕切り直し。各種設定を眺めます。また、ウェブで探し回ります。で、思ったのが、ubuntu のほうは日本語環境ちゃんとできているのねぇ。ってこと。それなら ubuntu の設定をちょっとパクってしまえ。ってんで、 /usr/local/etc/fonts/conf.d/ 辺りを眺めます。

ubuntu 的に言うと「default のフォントの設定を削除するパッチ」ってのがあるので「あれ? FreeBSD 的だと default が Bitstream Vera の設定なので、それを削除すれば良いんじゃね?」と思いつくわけです。それが解ればあとは簡単。 /usr/local/etc/fonts/conf.d/ で grep “Bitstream Vera” * します。で、その結果、 60-latin.conf を改修すれば良いわけねー。というのが解りました。

以下の URL に /usr/local/etc/fonts/conf.avail/60-latin.conf に適用すべきパッチを置いておきました。

http://icmpv6.org/Prog/KDE/okular_ja-60-latin.conf.patch

まぁ、パッチなんてたいそうなものは必要無いとは思うのですが、簡単に説明すると、60-latin.conf では一番最初に利用されるフォントが Bitstream Vera になります。こいつは日本語を持たないフォントですね。それならば、それよりも上の行に ume フォントを追加してしまえーっ!! って感じです。

なので、上記パッチを適用した場合には japanese/font-ume をインストールする必要があります。自分の好みのフォントに設定したい場合には “Ume Gothic” の部分を好きな文字列に変更すればそれで OK です。

で、このパッチを適用したフォントのダイアログはと言うと、

Okular_font3.png

んー。ちゃんと ume フォントが利用されていますね。そして okular でも日本語がバッチリ表示できるようになりました。いやー。良かった良かった。

もしかしたら /usr/local/etc/fonts/conf.avail/60-latin.conf はそのままで、パッチ適用後の 60-latin.conf を ~/.fonts.conf.d/ の下に置いても同じ動作をするかもしれません。が、私は試していません。

それにしてもこれで okular が無事にちゃんと利用できるようになりました。良かった。

8月 012011
 

僕的には久しぶりの「CPU コレクション」なのですが、記事的にはそんなに久しぶりではないですねぇf(^^;;。さてさて、 AMD の CPU は SocketA まで、Intel の CPU が Soecket370 まで来たらいよいよ旧世代の CPU に一段落付いたかなぁ。とか思ったら、それはまだまだ甘いですねぇ;-)。

あのメーカの Soeckt370 を忘れてもらっては困ります。ってかぁ?;-)。 Socket7 LOVER な僕が忘れるはずがありません。VIA が Cyrix を買収して CPU を作っているんですが、その Cyrix の技術(と、言うか Socket370 のライセンスを買収した権利) で VIA が Socket370 互換の CPU を出しているんですねぇ。

VIA CyrixIII。 Socket7 の CyrixII は僕の一番のお気に入りの CPU なのですが、Socket370 の CyrixIII は使ったことがありません。

こんな感じの CPUです。

Socket370_VIA_CyrixIII_1.jpg

うひょーっ!! デザイン的には Socket7 のCyrixII を彷彿とさせてくれますねぇ。嬉しいです;-)。しかし、実は VIA の CPU なんですなぁ。

こっちが裏側です。

Socket370_VIA_CyrixIII_2.jpg

さてさて。この CPU、上にも書きましたが、僕は見たことも使ったこともありませんでした。ヤフオクで CP パーツの CPU の一覧を眺めていたら売りに出されていたのでついつい購入しました。こーいうのがコレクションとして蓄積されていくわけでありますが;-)。

アキバで探したらジャンク屋さんの一店舗で売っていますが、それよりもちょっと安く購入することができました。まーコレクションアイテムとは言いつつ買いたい人は本当に少ないのでほぼ売値で購入できたのでありますね;-)。

しかし、このカテゴリー見て「僕も私も CPU 集めてみよう。」と言う人がどれくらいいるのか解りませんが、そー言う人が多くなるとヤフオクでもどんどん値段が上がっていくのかなぁ?

使ったことないし使っている人やところを見たことが無い CPU なので、どれくらいのスペックなのか、全く解りませんf(^^;;。てーか、今回初めてですね。そーいう CPU。