今回のアップグレードにはなんとなくついていけなくてまだメインマシンは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を含むいろいろなショートカットが書かれてある。便利そうなものもあるけれど、やっぱり怖い？ような気がする。

Ubuntu 11.04の目玉機能といえばなんといっても新UIのUnityなのだけれど、どうもこれが相性が悪い。世間的にはあんまりそんな話も聞かないので私のマシン、もしくは環境の特異的なことだと思うのだけれど、以前にはCPUの暴走でほとんど操作ができなくなったことがあった。それ以来、以前から使い慣れているOpenBoxに戻って、ずっとOpenBox ＋ Xfce用のパネルという変則デスクトップ構成で運用してきている。これが軽快だし、安定しているからだ。とはいえ、Unityの話題があちこちで聞かれるようになると、時代に取り残されたような気持ちになってくる。あれ以来、かなりいろいろアップデートが入ったから、そろそろ大丈夫かなと思ってUnityに移行してみた。そして数時間使って、原因不明にデスクトップが終了した。
いや、やっぱりUnityは私には合わない。OpenBoxに比べると、やっぱり反応がもっさりとしている。というのは、もう三次元デスクトップの描画をやるのに要するほんの僅かのタイムラグが気になるぐらいに、新しいマシンに馴染んでしまっているからだ。これが、以前の低スペックのネットブックからこのCULVマシンに移った直後なら、そうは感じなかっただろうと思う。とにかく人間は横着なもので、快適さにはすぐに慣れてしまう。そして、わずかの遅れに不平たらたらとなってしまう。
結局、またOpenBoxに舞い戻ってしまった。これはこれで、最近ちょっと以前よりも安定度が下がっている気がする。具体的には、ポインタの動きが止まってしまうエラーが、この数週間で2回ほど出てしまった。いずれもメモリの消費が多すぎてスワップを食っているときに発生している。あまり横着な使い方をするものではないなと思うのだけれど、ついついメモリに負荷をかけてしまう。楽だから。
そういうハングアップ時に以前ならCtrl+Alt+Delが使えたのだけれど、2年ほど前からこれはデスクトップ環境上では無効化されるようになっている。有効化する方法もあるようなのでそれを調べはじめたら、Alt+SysRq+Kで強制終了がかかることを知った。やってみると、見事にデスクトップ環境が強制終了される。アプリケーションの強制終了ではないけれど、これだけでもずいぶん役に立ちそうだ。トラブルのおかげでひとつ賢くなったようだ。

PDFのページ順入れ替えにはWindows版もあるpdfsamでも十分なのだけれど、私はPDF-Shufflerを愛用している。どちらもリポジトリにあるので好みでしかないのだけれど、PDF-ShufflerのほうがサムネイルのあるGUIで直観的に操作できるから気に入っている。まあ、一長一短はあって、PDF-Shufflerのほうがサムネイル表示をする分だけやや時間がかかるし、操作画面も占有する。場合によってはそれが面倒に感じるかもしれない。ともかくも、PDF-Shufflerは割と気に入って使っているのだけれど、シンプルで、機能は多くないように見える。ただ、先日使ったとき、サムネイルを右クリックすると90°の回転やページのクロッピングが指定できることに気がついた。シンプルなメニューになかったからそれまで気がつかなかったわけだ。これは、複数ページを選択しておいても使えるので、たとえば一括でページのタテヨコを変更することなんかもできる。そして、余白の調整も一気にできることになる。これは使えるかもしれない。
たまたま昨日、8ページの中折り冊子を自宅プリンタでつくろうということになった。これはふつうにページ単位で出力したPDFをPDF-Shufflerで入れ替え、印刷ダイアログで1枚の紙に2ページずつ印刷するように指定して両面印刷すれば、簡単にできる。PDF-Shufflerを使わなくても最初のPDF出力時に印刷順の指定で対応することもできる。ともかくも、印刷ダイアログの「ページの設定」で「段組印刷」を利用すればいいわけだけれど、ただ、ここにちょっと問題があるのは、段組印刷だと余白がやたらと大きくなることだ。そういう意味ではこれはかなり間に合わせの方法で、やっぱり本格的にはScribusできちんとしたデータをレイアウトしてやるべきだということになる。
しかし、そこまで大げさにすることもない場合、PDF-Shufflerのクロッピングを使えばうまくいくことがわかった。「段組印刷」の問題は、余白が大きくなりすぎること。だったら、PDF-Shufflerであらかじめこの余白を削っておけばいい。
ということで、ひと手間余分になるけれど、段組印刷をする段階で直接プリンタには出さず、ファイルに出力して2ページ1面のPDFを中間出力として出しておく。このPDFの余白を（クロップする大きさはパーセント指定なのであらかじめ測っておいて）、PDF-Shufflerで一気に削除する。その上でふつうに両面印刷すればOK。
ポイントは、クロップしたPDFは本来の用紙の大きさより小さくなっているので、印刷時に「ページの取り扱い」ダイアログで「印刷可能な領域に合わせる」を選択すること。そして、そのため、余白が新たに設定されてしまうから、そこまで見込んで余白を削っておくことだろう。このあたり、ちょっと試行錯誤が入ってしまうかもしれない。そういう意味では、すっきりしたソリューションではない。あくまで間に合せの方法。
続きを読む

一昨日のWineで動作中のアプリケーションからPDFを出力する方法というエントリで強引にWine上のMS Word ViewerからPDFファイルを出力する方法を書いたのだが、その冒頭に、「こういうバッドノウハウはすぐに古びて不要になるとは思う」と書いた。ほとんど言い訳に近いのだけれど、早速それが不要になる方法をmasashi.Mizuno.chestnutさんにコメントで教えていただいたので、改めて記事に。これはcups-pdfというパッケージをインストールするだけの極めて単純なソリューション。cups-pdfは、リポジトリの説明によると「CUPS-PDF provides a PDF Writer backend to CUPS. This can be used as a
virtual printer in a paperless network or to perform testing on CUPS.」つまり、仮想プリンタとして使えるということだから、WindowsでPDF出力のために配布されているPrimoとかPDF Creatorとかとほぼ同じ。
そういう便利なソフトなのになぜいままで知らなかったのかという言い訳は、これを使わなくてもUbuntuではPDF出力がデフォルトでサポートされているからだ。印刷ダイアログで「ファイルに出力する」というオプションが最初から用意されている。cups-pdfは、完全にこの機能と重複するわけで、だから不要なわけだ。
しかし、Wine上で動作するWindowsアプリケーションでは、この「ファイルに出力する」というオプションが表示されない。ということで先日のバッドノウハウになったわけだけれど、何のことはない、cups-pdfを使えばこれがあっさり解決する。
続きを読む

こういうバッドノウハウはすぐに古びて不要になるとは思うのだけれど、当面は必要なので備忘として。WineはUbuntuでWindowsのアプリケーションを動作させてくれる便利なものだけれど、実際にはそれほど使う場面は多くない。
Wineで動作するアプリで重宝させてもらっているのが、MS公認のWord ViewerとPowerPoint Viewerだ。WordやPPTの書類は、最近では私の仕事の基本的なフォーマットになっていて、しょっちゅう受け取る。ただ、最近はOpenOffice（LibreOffice）の互換精度がいいので、ほとんどLibreOfficeで処理して問題はない。MS Officeでなければどうしようもなくて仮想環境を立ち上げるというようなことは、ごく稀にしか起こらない。
けれど、もらった文書がその「稀」なケースに当てはまるかどうかはきちんと判断しなければならない。そんなとき、いちいち互換環境に入らなくても、WineでMS公認のViewerを起動すれば、ほぼ完全にWordやPowerPointの表示が再現される。これを見て特殊な作りこみがされていないかどうかを確認するわけだ（もっともこれらViewerは基本的にはOffice 2003の仕様なので、Office 2007や2010と100％互換と言えないところがあるのは否めないのだけれど）。
ということでこの話は終わりなのだけれど、たまにこのOfficeのViewerからPDFが出力できたらなと思うことがある。せっかくレイアウトが再現されているのだから、そのままPDFを出力すれば、MS環境の人が出力するのと同じ結果が得られることになる。けれど、これがなかなかうまくいかなかった。
Windows環境でPDFを出力するには本家であるAdobeのAcrobatを使えばいいのだけれど、有料のそのソフトでなくとも、さまざまなPDF出力用のフリーウェアがある。むかしWindowsを使っていたときには、そういうのを愛用していた。基本的にはLinuxで使われているのと同じGhost Scripの応用らしい。
ところが、こういったPDF出力用のソフト（たいていは印刷ダイアログから使う）が、Wineではうまく動作しない。たぶんUbuntu本来の印刷機能とバッティングするのだろう。回避策があるのかもしれないが、わからない。
最近のMS OfficeにはPDF出力がネイティブで備わっているが、古いMS OfficeやそれをベースにしたViewerには、そういう機能はない。出力用のフリーウェアも機能しないとなっては、八方塞がりで、以前に少し悩んで「これはできないんだな」と諦めていた。
続きを読む

ちょっと思うところがあって仮想環境にWindows Vistaを構築しようと思った。本体にプリインストールされていたOSを消してUbuntuを入れ、そのUbuntu上にもともとプリインストールされていたOSを入れて使うのは、ライセンス的にはどうなのかよくわからない。本来のマシンで本来のOSを使うという意味では何の問題もないように思う一方で、ハードウェア構成は完全に変わっているわけで、アウトのような気もする。ライセンス的な意味だけでなく、多くのプリインストールマシンがリカバリー用のメディアをディスクイメージで提供している関係上、技術的にできないことになっている。ただ、Dellその他の一部のメーカーではちゃんとしたインストールディスクを添付してくれているので、やろうと思えばOSを仮想環境に移すことはできる。ということで、使っていないもともとのVistaを仮想環境にインストールしようと思った。Ubuntuだと、新規インストールに最低でも4GBの空きディスクは必要になる。XPの場合6Gぐらいないとうまく動かない。Vistaだから余裕をもって10GBの仮想イメージを作成し、インストール。ずいぶんと長時間はかかったけれど、大きな問題もなくインストール完了。この時点で、ディスクは6GBぐらい消費されている。10Gにしたのは正解だったなあと思った。さて、Windowsはここからが長い。アップデートで再起動の嵐になる。もうこのあたりは何度も経験済みなので、さして驚かない。
で、最初のアップデートが終了し、再起動したら、何故か処理が途中で止まる。おかしいなあと思っていたら、「構成に失敗しました」というようなメッセージ。指示に従って再起動すると、どうも表示がおかしい。
いったいどうしたことかと思ったら、なんとディスク容量がほとんど残っていない。ついさっきまで4GBも余っていたのに。
どうやらこれは、Vistaに備えられたバックアップ用のファイルがディスクを消費しているようだ。クリーンインストール直後に公式のアップデートを導入しただけだから何もわざわざ復元ポイントなんかつくってくれなくてもいいのに、どうやらそういうことをやらかして、そしてディスク容量を消費したらしい。
たかがOSひとつ、何のアプリケーションも導入しないで10GBも占領してまだ足りないというのかと、この時点で呆れかえってしまった。いや、Vistaがなければ困るわけでもないので、もうこの時点で修復は諦めた。そりゃ、方法はあるんだろうと思うけれど、これじゃああんまりだ。
続きを読む

先日、pdfposterでタイリング印刷という記事を書いたのだけれど、たまたま続けてこのプログラムを使う機会があった。ちょっと状況が違うので、備忘がわりに書いておく。タスクは、A3に見開きで出力されたページものをA4プリンタで出力できるようにすることだった。レイアウトソフトで校正を出すときには、よく見開きでPDFを出力する。これは仕上がりの2ページがPDF上では1ページになっているので、校正に限っていえば便利なのだけれど、冊子として出力するには非常に扱いにくい。たとえばこれを両面印刷すると、どう綴じたって本の形にはならないページ順に印刷されてしまう。仮にA3やA2に対応した大判プリンタがあったとしても、いったん1ページ単位にばらして面付をやり直さないとまともな出力にならないわけだ。今回は、たまたま家庭用のプリンタなのでそういう事情ではないのだけれど、A3見開きをそのままでは、縮小されてしまう。原寸で出力したければ、やっぱりページ単位にばらさなければならない。
先日は、小さなPDFを拡大し、拡大した分だけタイリングするという目的でpdfposterを使った。A3をA4の2ページに分割するのはタイリングのようなものだから、pdfposterが使えるだろうと踏んで、やってみたわけだ。
ところが、いろいろやってみてもうまくいかない。やっぱりプログラムの趣旨がちがうみたいなのだ。
最終的に成功したのはこの方法。まず、evinceの印刷ダイアログからファイルに出力をして、A3サイズのPDFをA4サイズに縮小する。印刷出力が縮小されただけで、画質に変化はない。これを、A3のポスターにするのだとpdfposterで指定してやれば、再度拡大され、2分割される。コマンドとしてはこんな感じ。

pdfposter -mA4 -pA3 input.pdf output.pdf

続きを読む