ある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

続きを読む

久しぶりにワープロのフォーマットの問題が発生した。かつては「読めませんか？」「ウチのワードじゃちゃんと表示されるんですけどね」といった問題はけっこう多発していたのだけれど、最近はあまりそういう問題は発生していなかった。特にOpenOfficeの進化によってMS Wordとの互換性が高まって以後、とりたてていうほどの問題はほぼなくなっていた。それが、どうもMS Officeのバージョン違いの問題のようなのだけれど、こちらで確認した内容が先方でうまく表示されないという問題が発生した。私が確認用に使っているMS Officeがえらく古いものなので、そのバージョン問題だろう。これはこちらに非がある。ぼちぼち確認用だけにでも新しいバージョンのOfficeを入手する必要があるかもしれない。
ただ、今回に関しては納品にかかわることではなく内容の確認を相互にとれればいいだけなので、Webアプリをうまく使えないかと考えた。たとえばGoogle Docsなんかで文書を共有すれば、互いのOfficeのバージョン問題を気にする必要がなくなる。そこでいろいろ調べてみた。Google Docsのほか、MS OfficeのSkyDriveにあるWindows Live Office、Zoho Officeを試してみた。いずれもずいぶん以前にアカウントはつくっていたので、久々の試用ということ。ただ、今回はいずれも目的とうまく合わなかった。以前、事実上OpenOfficeなので「使えるな」と思っていたulteoは、Webアプリ方面からは撤退してクラウドサービスに方向転換したようで、事実上使えなくなっていた。これは残念。
ということで結局は問題は解決せず、文書のつくりかたを変更するというベタな方法で解決せざるを得なかったのだけれど、久々にOffice Suiteを調べて、「ああ、こういうのがあったなあ」と懐かしく思った。Wikipediaのこの記事のリストなのだけれど、Linuxを使いはじめた前後にはあれでもない、これでもないといろいろ試用したことを思い出す。そんななかに、見慣れない名前があった。Calligraだ。クロスプラットフォームのオープンソースソフトウェアだという。
続きを読む

もともとが滅多に日本橋界隈なんて歩くことはなかったのだけれど、それでも十代の頃にはオーディオ製品を求めて、二十代の頃にはワープロを探して、そして三十代以後はMacを求めて、靴底がすり減るほど電気屋街を歩くことがたまにあった。特に田舎のほうで編集プロダクションをやっていたときには、大阪や東京に出張するたびに時間を見つけては情報収集を兼ねて電気屋を歩いた。それが、ほとんどの用事がネットで片付くようになって以来、そして同時に私のライフスタイルがあまり出歩かなくなって以来、ほとんどそういったところには行かなくなった。この10年間で数回、ごく短時間歩いた程度だろう。それももう何年も前だ。それが、昨日、久しぶりに難波から大国町までの電気屋街を歩く機会があった。といっても目的があったわけではなく、たまたまもう少し先の施設に行く用事があったので、回り道をしただけのことだ。そして、「ずいぶん変わったなあ」と思った。そんな雑感を少し。
いや、変わったのは私の方かもしれない。確かに、昔から続いている店も何軒も見かけた。コスプレの呼びこみはずいぶんと目立ったけれど、以前から同人誌系の店が多かったのは確かだろう。少し食い物屋系が増えたかなとか、コンビニが多いなとか、そういうのはある。たぶん、小売系の電気屋は減っている。それでも、「こんなものだった」といえなくはないかもしれない。
印象として、「あそこに行けば訳のわからないものがある」という奇妙なワクワク感がなくなった気がする。いや、いまでも十分に怪しげな品物はある。例えば、MS純正Office XPが3,000円（ただしジャンク）とか。いや、Officeが3,000円は十分に安いし、こういうのは日本橋ならではだろう。ただ、「いまさらOffice買うかよ」という感じが私の中にある。同様に、以前は熱心に見た中古PCだって、たしかに同じようにずらっと並べられてはいるのだけれど、奇妙に輝きを失っている。必要以上のパワーをもった新品が4万も出せば手に入る時代に、同じような値段帯で中古品を展示されていても、気持ちが惹かれないわけだ。積み上げられたDVDの山にしても、「いまさらDVDに焼きたいデータなんてないよな」と。
続きを読む

昨日、引っ越しでアクセス半減。勘定は合うのだけれど…という記事で「新ブログの方のユーザーは旧ブログを経由してきている方も多いはずで、ということは、両方にカウントされているはずだから、これだけの減少はおかしいという気もする」と書いたたけれど、よく考えたらこれは何の不思議もないことだった。というのは、旧ブログの記事本体は、全てCMSであるWordPress上のものではなく、引っ越し案内を掲載した実ファイルのものが表示されるようになっている。ということは、WordPressのアドオンであるアクセス解析ツールには引っかからないわけだ。そして、個別記事にアクセスした人々がそのままこちらに流れてきてくれているとしたら、「減った分がちょうど増えた勘定」というのが合理的に説明できる。
考えてみたら、このブログへのアクセスは、トップページ経由ではなく、検索やリンクから個別記事へのダイレクトの訪問が圧倒的に多い。「読者」といっても一般的な人気ブログの読者のように更新をずっと追っかけているわけではなく、必要があって飛んでくるわけだ。それはそれで凄いなあと、われながら感心する。その割に、役に立つ情報が少なくて、ドジな顛末やらグチに終始しているのは情けないけれど、背伸びをしても仕方ないだろうとも思う。
続きを読む

このブログの引っ越しをしてから数日が過ぎたが、おかげさまで早速、新ブログの方に多くのアクセスをいただいている。さすがGoogleのインデックス化は素早く、引っ越しの翌日にはもう新旧のブログが並んで検索結果に上がるようになっていた。旧ブログを削除すれば、少なくともGoogleに対してはいつでも引越し完了宣言を出せる。ただ、このブログの読者は検索エンジン経由ばかりではないようなので、そういう方々に対してもうしばらくの間、新旧並立で進めておこうと思う。で、旧ブログのアクセスが、引っ越しの翌日に一気に半減した。カウントの方式はアクセス解析のツールによってちがうようなので一概には言えないのだけれど、旧ブログで使っていたWordPressのアドオンによると1日あたりのユーザー数（PVではない）は、だいたい700〜800程度あった。それが350〜400ときれいに半減。
そして、新ブログが、しょっぱなから好調に約300程度のユーザー数を稼いでいる。減った分がちょうど増えた勘定で、そういう意味では新旧合わせて増減なし。確かに勘定は合う。
続きを読む

何を隠そう、私はけっこう昔からの反原発教信者である。これは私がMac信者になる以前からの話だから、ずいぶんと古い。正確に言うと、反原発は私の主義主張の中のごくマイナーな部分であって、他の主張をしていたら、「だったら原発にも反対しなけりゃ筋が通らないじゃない」という図式に過ぎない。ともかくも、そういう人間にとって今回のような災害が発生しているのは痛恨の極みで、「ああ、ついでのように反原発なんて言うんじゃなくて、もっと大声を上げといたらよかった」と、後悔することしきりなわけだ。ということで、地震から3ヶ月を気に開かれる今週末のデモには家族で参加しようと思うのだけれど、そのときプラカードに使う画像の印刷を妻に頼まれた。A2ぐらいの厚紙を買ってきて、それに貼りつけてつくるという。プリンタはご家庭用のA4インクジェットだけれど、なに、タイリング印刷をすればいい。
タイリング印刷というのは、大判サイズの文書を途中で分割して何枚かの紙にプリントすることで、確かMacではデフォルトになっていた。デフォルトになっていたせいで、わからないうちはよく1枚の文書のつもりが何ページにも分かれて印刷されて驚いたりもした。という記憶があるのだけれど、実際はどうだったのだろうか。なにせ、えらい古い話だ。
ともかくも、タイリング印刷なんてごくありふれた機能だろうと思ったのだけれど、これが案外とない。画像ファイルなので画像ビューアから印刷しようと思ってもタイリングがないし、ならば万能ツールのGimpと思っても見当たらない。PDFならどうかとPDFに出力してもそういうオプションはないし、仕方ないので1枚はScribusで画像の位置をずらして手動でタイリングをやったけれど、これはどう考えてもスマートではない。
続きを読む