自分用のメインマシンではついに11.10をスキップしてしまった（ついでに12.04へのアップグレードもまだ予定に入れていない）私だけれど、少し前から12.04 Precise Pangolinを使っている。これが非常に調子がいい。ひとつは「Inspiron mini 12にPrecise Pangolinをインストールしてみた」で書いたとおり、小学生の息子のために用意した古いマシンにインストールしたもの。もうひとつは、半年間の予定で一日おきに顔を出すことになったある事務所のパソコンにインストールしたもの。私が使うために専用のノートパソコン（Fujitu）を用意してくれていたのだけれど、これがVistaマシン。改めて遅さを実感すると、Ubuntuを入れたくなった。どうせメールとブラウザ、オフィス系のソフトを使うぐらいだし、ソフトのインストールに関して特に規定はないということなので、普段使い用としてデュアルブートでインストールした。ふつうに起動すればVistaになるようにしておいたから、ほかの人が使う場合にも問題ないし、Windowsでなければ処理できないような共通ファイルがあったら再起動すれば済む。こういう運用にして感じたのは、たかがブラウザひとつ使うだけでも、Ubuntuの方がスピードを実感できるということ。もちろんVistaでもチューンナップすれば速くなるのだろうけど、やっぱりデフォルトの力は大きい。
さて、Precise Pangolinの印象だけれど、これは実に完成度が高い。実のところこれまでは（仮想環境で使った11.10を含めて）デフォルトのUnityではもどかしくてデスクトップ環境をOpenBoxに入れ替えていたのだけれど、今回はその必要をまったく感じなかった。だから、デフォルトのUnityの設定だけ少しカスタマイズして使っている。ほとんどデフォルトのままと言っていいかもしれない。
どこがどうと細かいことはいえないのだけれど、使っていて違和感がないのが完成度の証拠だと思う。LibreOfficeのバージョンも上がって、少しUIが変わったように思う。たとえばWriterで境界線がマウスオーバーで現れるUIは、以前にはなかったように思う。
これは11.10からなのだけれど、geditの検索が「検索・置換」と完全に別機能になったのは嬉しい。これはかなり使いやすい。
ぼんやりした印象だけれど、もうちょっと使い込んでいきたいと思う。

はじめに続きを読む

Linuxには、経理関係のソフトが大きく欠けている。英語環境ならいくらかあるようだけれど、日本語環境だとぐっと少なくなる。それでも、妻が愛用しているExcel BというソフトはOpenOffice上でも稼働するテンプレートなので、Ubuntu 上でも動作する。これは小規模事業所の経理に強い味方だろう。この辺りの詳細は、こちらの記事に書いた。ただ、ビジネスまわりのソフトが少ないのは無理もないのかなあと最近気がついた。というのは、多くの事業がそれぞれなりにユニークなので、実は汎用のパッケージソフトというのは案外と使いにくい。それでも法律上の要件がかっちりしている企業会計なんかはパッケージソフトが非常に役立つわけだけれど、商品管理や原価管理、伝票類の作成に関しては、それぞれの事業のそれぞれの特性に合わせてカスタマイズしなければならない部分が多くなる。となると、パッケージソフトよりも「エクセルで作っといてよ」という世界になりがちで、使えるソフトが少ないのはなにもLinuxの世界だけではないのかもしれない。
実際、世の中に見積書や請求書のエクセルテンプレートはあふれかえっているが、実用的なものは案外少ない。ひとつの理由はそれが必ずしも自分のニーズにぴったりあった書式ではないからだ。明細の書き方や単価の書き方など、それぞれの事業にはそれぞれの癖がある。汎用のものがうまくあてはまるとは限らない。
もうひとつの理由は、たいていのテンプレートがデータ間のリレーションを想定していないことだ。見積書に単価と数量を記入すると確かに請求金額や消費税を自動で計算してくれる。けれど、その数値は納品書や請求書には反映されない。まして、請求書の数値を積算して月間の売上を計算してくれるようなことはしない。それはスプレッドシートの役割ではなく、データベースの役割だからだ。そして、データベース型のアプリケーションは基本的には事業ごとに開発すべきものであって、テンプレートが転がっているようなものではない。
それはそうなのだけれど、データベースを利用した伝票処理システムの開発はたいへんだ。だから、私のところのような小規模な個人事業ではおいそれと手を出せるものではない。ということで、開業から5年ばかりは、エクセル上の手作業でこれら伝票発行の管理を行っていた。ただし、派遣でいろんな事業所での経験が豊富な妻が巧妙な運用形態を考案してくれていたので、プロジェクトの管理を専用のシートで行って納品書・請求書はそこからデータをコピー＆ペーストして作成する方式になっていた。この方法だと明細や単価をいちいち個別に入力する必要がないので、誤りも発生せず、手間もそれほどかからない。そして売上の管理は元台帳の集計で確実に行える。小さな事業にはこんな方式が確かに似合っているのかもしれない。
けれど、本来こういった処理はデータベース的に行うべきだというのは明らかだ。本格的な開発でなくとも、たとえばアクセスやファイルメーカーのような簡単なパッケージソフトを導入して素人が構築するレベルでも、相当に使いやすいものができる。それはまだWindowsが3.1だった頃にAccessを使った経験や、その後、Macのバンドルで付いてきたFileMakerで会社の経理を組んだ経験から確実にいえることだった。だから、機会があれば少なくとも見積・納品・請求の3点の書類に関しては一括して管理できるデータベースを組みたいとずっと考えてきた。たまたま去年は受注があまりとれず、その分だけ仕事が暇だったので（笑い事ではないが）、このあたりのデータベース化にとりくんだ。このときの覚書は、過去記事の「LibreOfficeのBaseで販売管理」にメモしてある。
それから1年近くこのデータベースを使ってきたのだけれど、いろいろと不便なところが目立つようになってきた。たまたま今年のはじめにデータベースをいじる機会があって、その際にSQL文の基礎なんかも少しはわかるようになって、どこを改訂すればいいのかようやく見当がつくようになった。そこで3月になってから大規模な改訂をやったのだけれど、だんだん形ができてくると同時に、OpenOffice（LibreOffice）のBaseそのものに内在する欠点が障害になり始めた。続きを読む

もう10日ほど前になるのだけれど、次期Ubuntu 12.04のPrecise Pangolinをリタイア中のDell Inspiron mini 12にインストールしてみた。このマシン、1年ほど前に友人に引きとってもらう約束をしていたのだけれど、去年は本当にいろいろあった年で、結局その約束はキャンセルになってしまった。そこで、間もなく小学校4年生になる息子に初めてのPCとして渡そうかと計画し、クリーンインストールを試みたわけだ。Ubuntu を使うことはほぼ既定ではあったのだけれど、どのバージョンにするかは実のところちょっと悩んだ。このマシン、ハードディスクが死んでいるので、外付けのUSBメモリにインストールすることになる。去年の5月に4GのUSBメモリにインストールしたときには（「Inspiron mini 12をUSBメモリで復活」）、10.04で成功した。言い換えれば、その段階での最新バージョンである11.04ではうまくいかなかった。さて、こんどはどうするかということだ。
ここで参考になるのが、Ubuntu 公式のPoulsboドライバのページだ。かつてPSBドライバを苦労して導入した頃とはうって変わって、GMA500には、EMGD driver、PSB-GFX driver、PSB driver、IEGD driverという4つの選択肢が用意されている。ただ、厄介なのは、それぞれのドライバによって対応できるバージョンが変わってくることだ。私が知っている伝統的なPSBドライバは、ネイティブでは10.10までしか対応しない。カーネルのダウングレードでどうにか11.04が対応するという時代遅れの代物になりつつある。IEGDドライバはさらに時代遅れで9.10のみの対応。EMGDドライバは2D、3Dだけでなくビデオアクセラレーションも使えるという優れものだけれど、ネイティブで対応するのは10.10のみで、それ以後はカーネルのダウングレードが必要になる。将来性を考えれば12.04がネイティブで対応するPSB-GFXドライバなのだけれど、これは2D機能しか対応しない。
ここはかなり悩んだ。悩んだけれど、結局は将来性にかけることにした。EMGDドライバなら、追加インストールせず、ドライバが12.04にもともと組み込まれているという。ということで、Ubuntu のバージョンも12.04 Precise Pangolinに決定。ちょうど最新版を追いかけるのいいタイミング、ベータ版が出たばかりということでもあった。
続きを読む

Ubuntuがどれほど成熟しているかは、そもそもOSなんぞに興味のない人にUbuntuをインストールしたマシンを渡してみてその反応を観察してみるのがいい。ということはわかっているのだけれど、なかなか機会がなかった。ちなみに、数年前に妻にそうやったときには、まだUbuntuが発展途上段階だったせいか、かなりサポートに手こずらされた。それ以後はそういう機会がなかったので、「さて、どのくらいOSを意識せずに使えるようになったか」興味はあっても確認する機会はなかった。それが、今日、たまたまあるオフィスでそういう機会があった。
このオフィスのボス、ネットショップを運営しているということで相当年季の入ったパソコンユーザーではあるのだけれど、その一方でIEとFirefoxの区別もあんまりつかない、と、技術面にはとことん興味のない人物。つまり、パソコンでやりたい目的、彼の場合はインターネットでモノを売ること、には強烈なほどの関心があるが、その裏側でどういうことが起こっているのかということはどうでもいい。彼ほど極端ではなくとも、多くのパソコンユーザーがそうだろう。
そのボスが、長年愛用していたパソコンの調子が悪くなって、最新のマシンに新調した。新調してすぐに古いパソコンは起動さえおぼつかなくなったので、いいタイミングだったと言えるだろう。
ところが、運が悪いことに、この新しいマシン、初期不良を起こしてしまった。メーカー保証の範囲内なので修理に出すことになり、それはいいのだけれど、修理中の代替機がない。古いマシンは、不安定で、とても使えたものではない。
たまたまそこに居合わせた私は、「じゃあWindowsを再インストールすれば数日使う分には何とかなるんじゃないですか」とアドバイスした。アドバイスした手前、再インストールを引き受けた。だが、どうやらシステムディスクがちがっていたようで、再インストールでエラーが発生。これではどうしようもない。
とにかくWebが見れなければ、彼は仕事に困る。そこで私は、説明もせずにUbuntuインストールをやってしまうことにした。彼の性格なら、WindowsだろうがLinuxだろうが、仕事さえできれば文句は言わないはずだ。ちなみに、機種が古くメモリが512MBしかないので、Ubuntuは苦しかろうとXfceを追加インストールして、そちらをメインにすることにした。
私の読みは的中し、「これがブラウザで、これを開いたらネットが見えます」と説明しただけで、「OK、ありがとう」の返事。さて、どうなるか。
確かに質問は来た。一度は、「外付けHDが読めない」というもの。見てみると、デスクトップにアイコンは上がってきている。これが開けないという。不思議に思って操作を見ていると、ダブルクリックが遅い。これはマウスの設定を変更して問題解決。
二度目の質問は、「メモ帳はないのか？」。これはgeditをランチャーに仕込んで解決。
三度目の質問は、文字化け。これは.eml形式の過去メールをgeditで開いたら文字化けするというもの。Thunderbirdで開くようにアドバイスして解決。
四度目は、メールアカウントの設定。もともと「メールまでは要らないよ」ということだったのだけれど、使っているとやっぱり欲しくなるもののようだ。これも設定だけのサポート。
最後は、「このパソコンは家でも使おうと思うんだが、無線LANの接続はどうやったらいい？」。これはパネルのアイコンを教えて解決。
ということで、普通の使用では、普通に新しいパソコンを使うときに遭遇する程度の疑問が発生するだけでUbuntuは普通に使えるようだ。実際、やりたいことが明確にあって使っている人からは、Ubuntuでも文句は出ないのだと思う。目的があれば手段はどうでもいい。そんなふうに感じた午後だった。

「お使いのフォントに合わせたいので、環境にインストールされているフォントを教えてください」というようなことを言われた。これがけっこう面倒臭い。まさかいちいち書き出すわけにもいかない。オボロな記憶だと、MacのDTP環境なら三種の神器のいずれかのアプリケーションで「フォント一覧の取得」みたいなダイアログがあった気がする。Ubuntuだとどうやっていいのか、ちょっと戸惑った。原始的にやってのけるとしたら、フォントフォルダ内のファイル名を複数選択してテキストエディタで編集すればいいような気もする。ただ、フォント名とフォントファイル名は同じではないので、この方法はあまりよくないかもしれない。
順当にいくなら、そのためのコマンドか、ユーティリティを使うべきだろう。探そうと思ったら、こちらのブログにお手軽なWebアプリが紹介されていた。
AULTA FONTS VIEWER
使ってみると、一発でフォントの一覧が取得できた。ただ、難点は、順番がてんでバラバラに表示されること。手当り次第に取得するのだろうか。あるいはなにか順番があるけれど、それがわからないだけかもしれない。これでは不便なので、表計算ソフトで文字の昇順に整形。そこまで含めてもごくかんたんにできた。
探せばたぶん、ローカルで実行できるコマンドやアプリもあるのだろうけれど、とりあえずこれで十分かなという気がした。世の中、なべてWebアプリ全盛だ。

今回のアップグレードにはなんとなくついていけなくてまだメインマシンは11.04のままなのだけれど、別マシンのWindows環境上に仮想Ubuntu環境を設定することになって、そこは素直に最新版の11.10を選んだ。ということでようやく11.10に触れることになった。今回は（前回からそうだったかもしれないが）、Synapticパッケージマネージャがデフォルトからなくなっていて、プログラム管理はソフトウェアセンターに一本化されている。これはこれでいいのだけれど、Mozcをインストールしようとしたらソフトウェアセンターから見つけられなかった。振り返ってみたら検索のしかたが間違っていただけのようなのだけれど、そこはあまり考えず、手慣れたSynapticをインストールした。こういうことをしていると、だんだん一般ユーザーの感覚から離れてしまうと自戒。さて、インストールをバックグラウンドで処理しながらほかの作業をしていたら、英語環境で立ち上がってしまった。言語設定がインストール時に選べたように思うのだけれど、どうもそこをパスしてしまったらしい。とはいえ、日本語環境に設定するのは何の難しいこともない。と、環境設定（11.04からシャットダウンメニューのところにある）を開いて、language settingをクリック。ここで言語の追加で日本語を追加するところまではうまくいった。ところが、そこから先、どうにも日本語を選択できない。ちょっと焦った。
なんのことはない。説明をよく読んでいなかっただけだった。「日本語」と書かれたバーを「English」と書いてあるバーの上にドラッグしていけばOKだった。そして、Appplyを押せばいい。それだけのことがわからず、一時は「英語環境で行くか」などと思っていたのだから実にいい加減なものだ。
UIの説明はよく読みましょうという教訓だった。

LinuxでレイアウトソフトといえばScribusにトドメをさすのだけれど、あいにくなことにScribusは日本語対応が完全ではない。それでも以前に比べたらだいぶとマシになってきていて、カーニングに目をつぶり、禁則処理を手動でするという面倒なことさえがまんすれば、ルビをふらない横書き日本語文書ならレイアウトできるようになっている。けれど、日本語DTPでは縦書き文書だって出てくる。ということで本格的な日本語DTPはLinuxではうまくいかない。それでも、簡易な間に合わせなら、OpenOffice、あるいはほぼ同等のLibreOfficeでレイアウトから出力までごまかすことができる。要はPDFを出せばいいわけだ。そしてOpenOfficeは一応は日本語対応が整っている。細かいことをいうならルビの設定が使えないのだけれど、それ以外は縦書き文書でもなんとかなるし、まあひと通りのことはできる。ただし、あくまで簡易DTPであるのは、たとえばトンボの出力とか版面外への画像配置とかCMYKの処理とか、印刷に必要な機能がないからだ。どうしてもそこまでやりたければ画像的に無理にできなくもないだろうが、そこまで無理するならInkscapeで1ページずつつくるほうがマシかもしれない。
ともかくも、これまで私は何冊もの本をOpenOfficeでレイアウトしてきた。冊子づくりが私の主なDTPの目的なので、そういうことになる。ちなみにペラものだったらInkscapeの方がいいとは思う。文字が延々と続く冊子ものの場合、OpenOffice、最近のUbuntuならLibreOfficeのWriterでレイアウトするのが最も簡単だ。
ところがあちこち見ていると、同じOpenOffice（LibreOffice）でもDrawをレイアウトソフトとして勧めている記事に出くわすことがある。そこで以前もちょっと試してみたのだけれど、テキストボックスの連結ができないので使いものにならなかった。文字屋である私にとって、テキストを複数ページに一気に流し込めないようでは実用的ではない。
ところが今回、図版を主体にしてその間に縦書きテキストが混在する冊子をつくることになった。最初はInkscapeで1ページずつつくってPDFを合体させようかと思ったが、それはそれで面倒だ。60ページのPDFを1つずつつくる手間は、ちょっと想像するだけで気が遠くなる。そこで、久々にDrawを試してみようと思った。
やってみると、これがうまくいく。Writerだと読み込んだグラフィックの配置がかなり面倒なのだけれど、Drawだとかなり融通がきく。それだけでもWriterより使いでがある。ヘッダ・フッタが入れられないのだけれど、私がこれを使うのはノンブルとハシラだけのことで、これらはテキストボックスとして配置して各ページに複製することで難なく処理できる。ノンブルに関してはページ番号の自動入力を挿入することは普通のテキストボックスでも可能なので、それを使えばOK。
ただ、グラフィックが重いので、10ページずつぐらいの文書に分ける必要があった。処理能力の高いマシンなら、その必要もないだろう。最終的に各パーツをPDFで出力しておいて、PDF Shufflerで合わせて完了。
縦書きで開きが違うので、さらに最後のPDFからページ逆順で印刷用のPDFを出力しておく必要があった。これは60, 59, 58, ..., 2, 1という数列を印刷ダイアログの「ファイルに出力」に入力してOK。この逆向き数列は、同じLibreOfficeのCalcで一瞬でつくれる。
Drawはダメだと思っていたけど、適材適所、用途によってはずいぶん使い勝手があると再認識した。

昨日、BitNamiでModxをインストールしていろいろと試し始めたのだけれど、パソコンを再起動したらローカルホストに接続できなくなった。これはMySQLとApacheが稼動していないかららしい。BitNamiのサイトには起動スクリプトでこれを解決する方法が書いてあるが、いつもいつもBitNami - Modxで作業するわけではない。その都度利用するほうが都合がいい。そこで、適当に見ていたら、インストールしたディレクトリにmanager-linux.run
という実行ファイルがあるのに気がついた。これを右クリックから実行すると、MySQLとApacheが停止していると示される。ここからGUIで起動できるので、この2つを起動すると、無事にローカルホスト環境に接続ができた。
ちょっとしたことでも、わからないと困るものだと思った。

昨日、BitNamiでWordPressがローカル環境で動いたという記事を書いたが、WordPressだと機能的にどうも不足することがわかってきた。これまできちんと使ったことのあるCMSはWordPressだけなのでとりあえずそれをインストールしてみたのだが、やっぱりこれはブログメインのエンジンだ。もうちょっと本格的なCMSが必要なようだ。同じBitNamiにはいろいろなCMSがある。Alfresco、Drupal、eZ Publishなんてのが使えそうなので試してみるが、本格的なものほど簡単ではなさそうだ。
サイト構築の管理までやったことはないけれど、コンテンツ管理者としてはModxなら使ったことがある。Modxはどうかと思ってみたが、BitNamiにはModxのスタックは用意されていない。けれど、いったんBitNamiでローカル環境を整備すれば、ほかのCMSも割とかんたんにインストールできる。以下の私のやった方法は、どう考えても邪道だけれど、邪道なりに何も悩まずに進めることができるので、備忘を兼ねて書いておく。
まず、BitNamiでWordPressのスタックがインストールされているところからスタートする。ここで、http:／／127.0.0.1:8080/wordpress/を打ち込めばWordPressで作成したブログのトップページが開くことは昨日書いた。ちなみに127.0.0.1はBitNamiが設定したローカルホストのアドレスで、8080はデフォルトのポート番号ということらしい。このあたりはカスタマイズできる（というよりもカスタマイズしておいたほうがいい）のだろう。何もわからずにやったので、ここはいい加減になってしまった。今回は練習なので、本番でやるときにはもうちょっとよく考えようと思う。
さて、このトップページはどこにあるのか？　WordPressをインストールするとき、デフォルトでユーザーフォルダ直下にwordpress-3.2.1-4というフォルダが生成される（もちろんこれもカスタマイズ可能）。この中にローカルホスト環境に必要なデータ一式が詰まっているのだけれど、では、いわゆるホームページはどこにあるのかというと、~/wordpress-3.2.1-4/apps/wordpress/htdocs/index.phpにある。つまり、~/apps/wordpress/htdocs/が、ウェブサイトのルートにあたるわけだ。
これだけわかれば、CMSを追加インストールするのは簡単だとわかるだろう。
Modxの場合、普通は、ダウンロードした圧縮ファイルを解凍し、一括してサーバーのパブリックな場所にアップロードする。そしてそのディレクトリにブラウザでアクセスすれば、インストール画面が現れる。ということなら、この~/apps/wordpress/htdocs/に解凍ファイルの一式を置けばいい。今回は既にWordPressのファイル一式が存在するから、~/apps/wordpress/htdocs/modxというフォルダをつくって、そこに解凍する。そして、ブラウザからhttp:／／127.0.0.1:8080/wordpress/modx/setup/を開くと、インストール画面が出る。あとは指示に従えばいい。
最初は本家版を使ってみたが、日本語化で悩むより鳩、日本語化されたローカルバージョンをインストールした。こちらのもの。
http://modx.jp/
インストール時にひとつ躓くのが、MySQLの設定だろう（いや、わかってる人は躓かないかな。私は躓いてしまった）。これは、まずMySQLの設定を予めしておかなければならない。そのためには、WordPressインストール時にいっしょにインストールしたphpmyadminを使う。これはhttp:／／127.0.0.1:8080/phpmyadmin/にブラウザでアクセスすればログイン画面になる。
ここでまず、私はユーザー名とパスワードがわからず苦労した。結局のところ、ユーザー名はroot、パスワードはWordPressインストール時に設定したパスワードと同じものになる。WordPressのユーザー名とは違うのにパスワードだけは同じということで、わからないままにけっこう時間を食ってしまった。phpmyadminにログインしたら、MySQLの設定ができるから、このデータベースタブで新規データベースを作成する、というところに新しいデータベース名を入れて作成しておく。
この下準備ができたら、Modxのインストールを進めることができる。「データベース接続とデータベースユーザーの指定」のところで、でターベースホストにローカルホスト名である127.0.0.1を入れ、ユーザー名はroot、パスワードはWordPressインストール時に設定したもの、データベース名に先ほどphpmyadminで作成したデータベース名を入れ、「→ ここをクリックしてMySQLサーバへの接続をテストしてください」というリンクをクリックすると、OKが出て、先に進める（わからなかった私は、ここで何度もエラーメッセージを出した）。その上で、「指定のデータベースが存在しない場合は新規作成を試みます。」をクリックして、データベースを自動作成。そして、管理者のユーザー名とパスワードの設定ダイアログが出るので適当に設定して「次へ」をクリックすると、確認画面が出てインストールに進むことができる。初回ログイン画面に進んで先程の管理者ユーザー名とパスワードを入力すると、利用が可能になる。
以上で、BitNamiで超簡単にローカル環境にModxをインストールすることができた。これは使えるかもしれない。ちょっといじってみよう。

ちょっと経緯があって、Webショップの開発・運用の端っこに関わることになった。といっても、システム側のことではなく、出店者側のサイト構築の話。既存のショップを改善し、同じ商品ラインナップを別のモールにも新規出店するという企画だ。細かいことはまだまだ進行中でもあるしデリケートな部分もあるから省略するとして、サイト構築の手段としてCMSを利用したらどうかというアイデアが浮かんだ。ただ、モールの内部にCMSをインストールすることはできないようだ。もしも無理矢理に使うとしたら、CMSで構築したデータを吐き出して、それをFTPでアップロードという力技になるだろう。けれど、それでもCMSを利用する価値はありそうだ。
しかし、そうなるとローカルでCMSを動かさなければならない。なにか方法はないかとGoogleに聞いたら、BitNamiというアプリケーションがあることがわかった。
BitNami
ここで、インストールしたいCMSのスタックをダウンロードする。たとえば、WordPressの場合bitnami-wordpress-3.2.1-4-linux-installerというのがダウンロードされる。これを実行可能にプロパティを変え（Nautilusの右クリックから可能）、端末にファイルの場所を指定して実行するとインストーラーが走る。これでインストールが完了。完了後のダイアログで、WordPressの初期設定もやってくれるから非常にイージーだ。
その後、WordPressにはブラウザのアドレスバーにhttp:／／127.0.0.1:8080/wordpress/を打ち込んで開いてやる。これが最初わからずにちょっと戸惑った。あとは、普通にWordPressがローカルで動く。
これはすごいなと思った。

あるWebサービスでPDF形式の文書を出力してくれるところがあるのだけれど、これがUbuntuでは文字化ける。いまどきPDFで文字化けを起こすのは珍しいのだけれど、どうやらこれはサービスの仕様らしい。というのは、このPDFをWindows環境に持って行ってAdobe Readerで開くとちゃんと文字が表示されるのに、Windows環境のInkscapeで開くと文字を認識しないからだ。おそらく、サービスが使いまわされることを避けるためにこういうことをしているのだと思うけれど、ユーザーから見れば余計なお世話ということになる。
で、Ubuntu環境で読めるようにする方法を考えた。要は文字をアウトライン化するかビットマップ化すればいい。そこで、PDF CreatorをWindows環境でインストールし、Adobe Readerから改めてPDFを作成した。この際、オプションの奥のほうにあるポストスクリプト設定で、アウトライン化もしくはビットマップかが選択できるので、ここをチェック。こうやって出力したPDFをUbuntu環境に戻すと、無事にUbuntuで読めるPDFが得られた。
こういう手間をかけるぐらいなら、Webサービスなんか使わずにローカルで文書を作ったほうがよかったのかもしれないとも思う。とりあえず備忘録として。

以前、Ubuntuのリポジトリにはベクター系のグラフィックソフトとして定番のInkscapeのほかにSkencilというのがあった。いつの間にか見なくなったなあと思っていたのだが、どうもプロジェクトがあまり進展していないらしい。その代わり、sk1というフォークがあって、むしろこちらのほうが活発らしい。AdobeのIllustratorの代替ソフトとしてかなりいいセンをいっているらしい。公式サイトに.debファイルが用意されていたので、インストールしてみた。こちら。http://sk1project.org/modules.php?name=Products&product=sk1&op=download
ちょっといじってみた。以前はほとんどInkscapeと同じような印象しかなかったのだけれど、だいぶ別の方向に進化している。プラグインやフィルターが充実してきたInkscapeに比べてそのあたりはシンプルで愛想のない感じだけれど（プラグインはメニューではなくプラグインブラウザというので表示されているが、これがよくわからない）、強みはCMYKを扱えることだ。
InkscapeはほとんどIllustratorの代用になるのだけれど（というか、私はずっと代用として使ってきているけれど）、惜しいことにはCMYKにデフォルトで対応していない。先日、久しぶりにオンデマンド印刷を使う機会があってカラー原稿を入れたのだけれど、RGBデータだったから少しくすんでしまった。あまり品質にシビアな仕事ではなかったので問題ないといえば問題なかったのだけれど、やっぱりできることならCMYKに変換して入れられるようになっておきたい。ということで、InkscapeでCMYKに変換するプラグインを探していたら、ごく簡単に見つかった。それが、こちら。
http://wiki.inkscape.org/wiki/index.php/ExportPDFCMYK
ところが、これがうまく走らない。エラーメッセージで「処理ができませんでした」みたいに空振りをする。どうもuniconverterというプログラムがうまく走らないようで、それについて調べていたらsk1に行き当たったというわけだ。
実は、sk1は最初からプリプレスを意識したプロジェクトらしい。だからAdobeのIllustratorのファイル形式やCorel Drawのファイル形式を扱えるようなトランスレータを開発した。それがuniconverterというわけだ。
Illustratorは、最近のバージョンからこのuniconverterを組み込むようになっている。そして、どうやらその整合性がうまくとれていない。しばらく前のバージョから発生しているコピー時にエラーメッセージが出る問題は、このuniconverterの不備から発生しているらしい。
ということで、InkscapeのCMYKのプラグインを動かすと同時にコピー時のエラー解決ができないかと、uniconverterの最新バージョンをsk1のプロジェクトページからダウンロードしていれてみた。
http://sk1project.org/modules.php?name=Products&product=uniconvertor&op=download
けれど、効果なし。というか、エラーメッセージの種類が変わっただけで、コピー時のエラーメッセージは出るし、CMYKのプラグインもうまく走らない。やっぱりこのあたりは、正式にバグが解決しないと、私レベルではどうにもなりそうにない。ちなみに、このバグは既にLaunchpadに報告があがっているようだ。pythonの動作に関係する様子なので、コードが読める人ならもうちょっと何とかなりそうな雰囲気はあるのだけれど。
さてさて、話が長くなったけれど、その点、sk1はuniconverterもちゃんと動いているようだ。だったら、印刷絡みのデータは最初からsk1で扱えばいいのかもしれない。Inkscapeと特に大きく使い勝手がちがうのは、PDFを直接開くことができないこと。開けるのはsk1の形式だけで、PDFはインポートもできない。SVGやpsデータはインポートできるので、PDFを細工するために使うのであれば、svgかps形式に予めInkscape等で書きだしておく必要がありそうだ。ただし、やってみると、svgはあるていどうまくいくけれど、psはうまくいかない。このあたりははっきりいってよくわからない。
PDFへの書き出しは、exportでもPrint to PDFでもいけるようだ。Inkscapeほどメジャーではないけれど、ひょっとしたらこの先、Inkscape以上に使えるソフトになるのかもしれない。

iPadが発売されるちょっと前あたりから、タブレット型の端末に非常に興味を惹かれていた。iPadそのものはいろいろ制約があるのでAndroidかなあと、まともな製品が発表される以前のいわゆる中華パッドなんかの情報を一生懸命漁っていたりもした。そんな状態が1年近く続いていて、去年の秋から冬にかけて各社からまともなAndroidタブレットが発売されるようになって、急速に興味が薄れてしまった。できること、苦手なことがだいたい明らかになってきて、「その程度のことなら無理して買うことはないな」という感じで。特に、タブレット端末の用途の中で重要なのは、電子書籍だろう。第一に電子書籍閲覧端末としてのタブレットという位置づけのものも少なくない。AmazonのKindleとか、シャープのガラパゴスとか。そして、電子書籍に対する興味は尽きないものの、当面読むだけならパソコンで十分かなという感じもして、「まあ、タブレットは後回しでいいや」と思うようになっていた。
ところが、昨日、たまたま電車に乗って出かける用事があった。ふだんは自宅事務所だから、あんまり電車には乗らない。そして乗るときには、だいたいはノートパソコンを持参して、膝の上で広げることにしている。仕事の続きを電車の中でというのは、意外にはかどるものだ。環境が変わることが気分をしゃっきりさせてくれるのかもしれない。
そして、昨日もやはり、愛用の11インチのノートパソコンを持って出た。そして仕事なのだけれど、これがちょうど依頼があったばかりの原書の下読みだった。下読みだから、キーボードに触る必要はない。読みやすければいい。
そこで、PDF書類でもらっている原書をevinceで開いて読み始めたのだけれど、ふと気がついて画面を90°回転させて、ノートパソコンを本を開くような形で持って読んでみた。これがなかなか読みやすい。
ほとんどの本は、1ページが縦長の紙だ。だから、モニタ画面を縦にするのは、読書ということからいうと非常にいい感じになる。これは、やってみるまで気がつかなかった。
もちろん、その昔、DTPをやっていたころには、縦長モニタの使いやすさは十分に感じていた。だが、それはそれだ。本をつくるのと読むのとではまたちがう。DTPの作業ではパレット類を散らしておく関係上、横長は横長で価値がある。読書の場合、そういう都合もないから、ほんと、縦長画面は予想以上にユーザビリティに優れている。
そうか、タブレットの利点は、タテヨコに切り替えて使えることなのかと、頭ではわかっていたつもりの理屈が、実際にやってみてようやく体感できた。こうなると、ノートパソコンで擬似的にそういう環境を作るよりも、やっぱり軽量のタブレットが欲しくなる。だいぶ安くなってきたなあと、懐具合も考えずに物欲が頭をもたげてしまう。

ファイルマネージャは、ふつう、どんなパソコンにも存在するプログラムだ。けれど、そういうものが存在するということすら、Ubuntuを使い始めるまでは知らなかった。フォルダをダブルクリックしたらその中にあるファイルやフォルダを見ることができるというのは、パソコンそのものの機能、OSそのものの機能であって、それを司るプログラムがあるなんてことは考えもしなかった。実際、MacでもWindowsでも、これはOSの一部として提供されている。Ubuntuだってそうだけれど、ただ、UbuntuのようなLinuxの場合、その気になればデフォルト以外のファイルマネージャを使うこともできる。Ubuntuのデフォルトはnautilusだけれど、私はこれに関してはXfceのThunarを使っている。そういう変更ができることが使っているうちにわかるようになるのも、Linuxの面白さのひとつだと思う。ということで、現在私はふだんはThunar、たまに必要があってNautilusを使うのだけれど、自分のシステムの中にそれ以外のファイルマネージャが入っているとは夢にも思わなかった。いや、以前にはもっと別のものをインストールしていたこともあるし、ブラウザの中にはファイルマネージャ的な機能を持ったものがあったりするので、「夢にも思わなかった」は言いすぎかもしれない。けれど、思いがけないところにひとつファイルマネージャが入っていた。それはWineだ。
Wineは、Windowsのエミュレータ的なソフトだけれど、仮想環境ではなくLinux環境下で動作する。だから、Wineを使うときに、特にWindows側のデスクトップ環境は必要がない。だからファイルマネージャもLinux側のものでOKだ。具体的には、たとえば.docファイルをword viewerで開いてやるなら、NautilusなりThunarなりのLinuxのファイルマネージャでそのファイルにたどり着いて、そこから右クリックでword viewerを指定してやればそれでOKだ。あるいはWineでインストールしたプログラムを開くのに、そのプログラムの実行ファイルまでNautilusでたどり着いて、ダブルクリックで実行することもできる。
だから、ファイルマネージャはLinux側のもので十分なのだけれど、WineにもちゃんとWinefileというファイルマネージャが最初からセットされているのだという。詳細はこちら。
http://wiki.jswindle.com/index.php/Winefile
何かの拍子にこれを見つけて、起動してみた。かなり古めかしい感じだけれど、確かにファイルマネージャがWineで動作している。例の.docファイルなどは、ここからWineアプリケーションで開くことができる。
ただ、これはあくまでWine側のアプリケーションなので、ここからLinux側のアプリを起動することはできない。だから、対応するWineアプリケーションのないファイルをダブルクリックしても何も起こらない。さらに、機能の多くが未実装ということで、実用的にはあんまり価値はなさそうだ。
それでも、こういうプログラムがあるということを知っておくのは悪いことではないと思う。特に、それが自分が気づかないままに自分のシステムにインストールされているのであれば。Wineを使っている方は、いちど起動して確かめて見られてはどうだろうか。

数日前に面白いブログエントリを見つけた。こちら。私も、5年前にUbuntuを使いはじめて、いろいろ設定がいじれるようになったときに、まっさきにしたのがUIを使い慣れたMac（それもOS8.6時代のMac!）にカスタマイズすることだった。そのぐらい、自分に馴染んだUIというのは重要。当時のMacユーザーなら付き合いでWindowsも少しぐらいは触ったことがあるからUIがマシンによって異なるということは理解できたと思うけれど、Windows一本で来たユーザーにとっては、左隅にスタートボタンのないUIは、どう使っていいかわからなくて「毛嫌い」というのも、あながちないことではないと思う。
ということで、UbuntuをWindows風にカスタマイズする方法なんかも数多くWeb上で出回っているわけだけれど、一方の開発者の側からすれば、「より理想的なUI」を求めるのは当然だろうと思う。これは、「真似をしない」という次元ではなく、「もっといいものがあるはずだ」という向上心だと思う。私なんかはわりとそういうのを好ましいと思うのだけれど、相性問題もあって今回のUnityにはついていけず、結局は昔ながらのカスタマイズしたOpenBox環境を離れられない。これもまた、ひょっとしたら保守性のなせるわざかもしれないと思う。
ということで、いったん「パソコンとはこういうものだと」と思わせたWindowsの強みは変わらないだろうなあと思う。ただ、デバイスが異なればそのあたりはOKという人も多いわけで、モバイル時代に突入したいま、そのあたりからバランスが崩れてくるような気もする。ということは、モバイルを睨んだUnityは、方向としては正しいんだろうなと、そんなことを思った。

しばらく前からどうも常用しているTwitterクライアントのChoqokの調子がよくない。認証しているはずなのに「認証が必要です」みたいなメッセージが出る。強行すると普通に使えたりもするが、そのあとで突然落ちたりもする。いったん落ちると連続して落ちる。設定ファイルを捨ててうまくいく場合もあるけれど、使っているうちにまた同じようなことが起こる。そこで、Choqokを諦めて別のクライアントを使ってみようと思った。試してみたのはQwitとGwibber。ちなみにGwibberは、デフォルトで入っている。Qwitはリポジトリに入っているのでSynapticパッケージマネージャでインストール。
Qwitは、以前は、たぶん私がTwitter初心者だったせいで、よくわからずに使えないと思った。今回ちょっと使ってみた感じでは、それほどわるくない。シンプルで、必要なものが必要なだけあるという感じ。これでいこうかなと思った。
ただ、Choqokで慣れてしまっているせいで、Choqokと違うところが気になる。具体的には、一覧性が低いことだ。Choqokだと、ポストの長さにもよるけれど、6〜8ポストぐらいは縦長の1画面で読める。未読のポストは一覧できたほうが嬉しいのだけれど、よっぽど賑わっているときでもない限り、1回の更新でこの程度に収まる。たまたまだけれど、これが使いいい。ところがQwitでは4〜6ポストぐらいでいっぱいになる。わずか1〜2程度のちがいだけれど、これが意外と気になる。
設定でなんとかならないかなと思ったけれど、UIの詳細は設定できない。何か方法がないかなと思って探していたら、QwitではなくGwibberにテーマが導入できることを見つけた。ならば、Gwibberでシンプルなテーマを導入すればうまくいくのではないかと思った。
Gwibberを使っていないのは、多機能なクライアントなのが仇になってUIが込み入っているように感じたからだ。上記の一覧性もよくない。けれど、こういったことはテーマで調整可能かもしれない。
Gwibberのテーマは、
というフォルダをつくっておいて、そこにインストールする。いくつかネットに上がっていたのをダウンロードしてそこに展開。Gwibberを起動すると、テーマが適用できるようになっている。Qwit風のテーマというのもあって、なるほどという感じ。
けれど、意外と検索でダウンロードできるテーマは多くない。もうちょっとシンプルなのがいいのだけれど、そういうのが見つからない。ならば、既存のテーマをもとに自分で調整するかと思った。幸い、テーマの設定はHTML（あるいはCSS？）に書かれているようだから、素人なりになんとか手を加えられそうだ。
けれど、少しやってみて袋小路にはまった。そのうちに、Twitterクライアントの不調はChoqokだけの問題ではなく、いろいろなクライアントで発生している問題だという噂を聞いた。どうもTwitter本体のAPIの仕様が変わったせいで発生していることらしい。となると、慣れないクライアントに移るよりは、バグの修正を待ったほうがよさそうだ。
ということで、探索は終了した。ここで深追いしないところが、いつまでたってもシロウトのUbuntu使いを抜けられない私なのだろうと思う。

スマートな方法ではないのだけれど、一昨日、OpenOffice（LibreOffice）とテキストエディタの改行コードで書いた問題をとりあえず回避する方法を書いておこうと思う。単純な話で、OpenOfficeでもテキストエディタでもないアプリケーションを経由してコピー＆ペーストするだけ。たとえば、ホームページビルダー式ののHTMLエディタとしてSeaMonkeyのComposerがあるが、ここにテキストファイルを貼りつけると、改行コードは<br />もしくは<p></p>として反映される。これを改めてコピーしてOpenOfficeに貼りつければ、改行マークはそれぞれ正しくLFもしくはCR+LFとして認識されるから、以後、保存時におかしな変換が行われて「行が増える」問題は発生しない。
これはたぶん、SeaMonkeyではない他のアプリケーションを経由しても同じ結果が得られるのではないかと思う。たとえばブログエディタのようなものでもいいと思う。なんならテキストエディタで\rや\nを<br />に一括変換しておいてそれをHTMLとしてブラウザに読み込ませておいてからコピー＆ペーストしてもだいじょうぶだと思う。ただ、手間がかかるので、それよりは他のアプリケーションを経由するほうが簡単だろうと思う。
こんな変なことをしなくてもOpenOffice（LibreOffice）の方で.doc保存時に変なことにならなければいちばんなのだけれど。とりあえずは、ベタな回避策で運用するとしよう。

以前から、OpenOffice、最近ではLibreOfficeを使っていて困ることがひとつある。それは、テキストエディタで処理した文字列をOpenOfficeのワープロWriterにコピー＆ペーストして.doc形式で保存したあと、再度開くと、改行が増えてしまうことだ。具体的には、1つの改行マークが2つになる。だから、各段落の間に1行の空白ができてしまうことになる。これはちょっと都合が悪い。OpenOffice上で作成したテキストなら、こういうことは起こらない。なぜよそから持ってきたテキストでこういうことが起きるのか、不思議で仕方なかった。これを防止する方法も思いつかず、どうしてもまずい場合には、改めてOpenOffice上でいちいち手作業でいったん改行を削除し、再び改行してやるという面倒なことをしていた。これは面倒で、ときにはやっていられないと思うこともある。
OpenOffice上で改行マークの一括置換でもできればこういう問題は起こらないのだけれど、OpenOfficeはこういう特殊コードを検索対象にしてくれない。一方、テキストエディタでは、たいていは改行やタブストップなどの特殊コードも検索・置換の対象になる。だから、たとえば本来1つのはずの改行が2つになってしまったとしたら、それをテキストエディタに持っていった上で、2つの改行マークを検索対象にして1つの改行マークに一括置換してやれば、修正する処理はできる。けれど、この修正済みのテキストをコピー＆ペーストでOpenOfficeに持っていったら、また同じことが起こるだけ。どうにもうまくいかない。
それでもこういう絡みの試行錯誤を続けていると、少しだけ見えてきたことがあった。それは、実際の改行コードと、テキストエディタ上で扱う改行コードが微妙にちがうということだ。
詳細はWikipediaのこちらに書いてあるのだけれど、テキストエディタ（少なくともgedit）上の検索置換では、改行マークは\n、\rもしくは\r\nで入力することができる。いずれでも改行になるのだけれど、これは概ねCR、LF、CR+LFに相当する。ただし、これは「概ね」であって、Wikipediaに「しかし一般的な認識に反して、これらのエスケープシーケンスは一般的にはLFやCRと等価ではない」と明記されている。どうやらこのことが、改行コードが増えてしまう原因のような気がしてきた。
詳しいメカニズムはわからないけれど、ペースト時と保存時にそれぞれ\n、\rからCR+LFへの書き換えが行われているのではないだろうか。そしてそれが重複してしまう。だから改行コードが倍増するのではないだろうか。ちなみに、\n、\r、\r\nのいずれに置換しても結果は同じなので、ここは一律の変換が行われているのだろう。このあたりにもヒントがありそうだ。
試しに、\nや\rに置換するのではなく、<br />と、HTMLの改行に置換してやり、これをHTMLとして読み込むと、改行マークの倍増は起こらなかった。このあたりにも別なヒントがありそうな気がする。
ちょっと厄介な問題だけれど、こんなふうに解決の糸口が見えてきたのには希望が持てる。うん、希望は失わずにいたいものだ、何事にせよ。

昨日、デスクトップがフリーズしたときの緊急脱出キー操作として、最近のUbuntu環境では無効化されているCtrl+Alt+Delの代わりにAlt+SysRq+Kが使えるらしいということを書いた。いままで知らなかったことなのでもう少し詳しく知りたいと思ったら、こちらに詳しい解説があった。Linux Shortcuts and Commands
これによると、私が緊急用のショートカットと思っていたCtrl+Alt+Delは実は再起動のコマンドで、Xを含むウィンドウシステムの強制終了はCtrl+Alt+BkSpcであるらしい。一方、現在開いているウィンドウを強制終了するのはCtrl+Alt+Escで、こちらのほうが役に立ちそうな気はする。が、いずれにしても最近のUbuntuでは無効化されている。
で、Alt+SysRq+Kの方だけれど、こちらは、「現在アクティブな仮想コンソール上で実行中の全てのプロセス（Xを含む）をkillする」ということで、一般的なUbuntuのシステムだとログインマネージャのGDMの画面に落ちる。ここからGUIで再ログインすればOKだし、なんなら普通に再起動をかけることもできるから、緊急時の脱出法として覚えておくのは悪くないだろう。
もう少し読み進むと、Alt+SysRqには、Alt+SysRq+eとかAlt+SysRq+iとかAlt+SysRq+lというのもある。いずれも、実行中の全てのプロセスを終了させるようだが、少しずつやっていることがちがうようだ。
Alt+SysRq+lは、「システムが動かなくなります」と書かれてあるので、さすがに試す気にはなれない。そこでまず、Alt+SysRq+eを試してみた。すると、GDMさえ終了して、コンソールに落ちる。私のようなGUI派は、こうなるとCtrl+Alt+Delで再起動するしかないだろう。一方のAlt+SysRq+iは、そのままフリーズしたような状態になる。一応、Ctrl+Alt+Delは有効なようだけれど、こうなるとかなり不安になる。
ということで、Alt+SysRqから呼び出すコマンドは、実はかなり怖いものだということがよくわかった。私のような素人はAlt+SysRq+Kぐらいなら使ってもいいかもしれないが、それ以外のものは下手に手を出すとシステムがぐちゃぐちゃになりそうだ。この他にも上記のページにはAlt+SysRqを含むいろいろなショートカットが書かれてある。便利そうなものもあるけれど、やっぱり怖い？ような気がする。