ImageMagickが壊れた?

WindowsVistaにインストールしてあるImageMagick6.3.2 Q8をPerlから呼び出すときのお話です。
少しの間、開発を停止していた部分を手直しすることになって画像を生成する部分が正常に動かなくなっていました。
ログをみると次のようなエラーが表示されていました。

Can't load 'C:/Perl/site/lib/auto/Image/Magick/Magick.dll' for module Image::Magick: load_file:再帰が深すぎます。スタックがオー
バーフローしました。 at C:/Perl/lib/DynaLoader.pm line 230,  line 855.


呼び出し元も、呼び出し先も階層がそんなに深いわけでもなく、動いていたときのままです。
何かのパッチでおかしくなったのかもしれないです。
そういえば、最近CPANの一括updateをしたような・・・
いろいろ調べてみましたが、これだという原因は見つかりませんでした。

結局、ImageMagickを一度アンインストールしてから入れなおしたところ、正常に動作しました。
ちなみに、上書きで更新した場合は同じメッセージが表示されて動きませんでした。
お仕事用のシステムなので、ヒヤヒヤしました。ほっと一安心です。

インクスケープでトンボを作成する方法

少々前の話なのですが、運営中のサイトでプリントライがあるのですが、データ入稿用のトンボの作成方法のページをがんばって作ってみました。
Inkscape(インクスケープ)でトンボを作成する
Inkscape(インクスケープ)のデータでもEPSにすれば入稿できますので、ぜひご利用ください。

OpenOffice.orgの妙日本語訳

OpenOfice.orgのCalcで妙な違和感を覚えたのでよくよく見てみると漢字が間違っていました。
書式設定のセルのフォーマット、分類にソレはありました。
通過→通貨です。
まぁ、意味はわかりますが。

だったらお前が翻訳しろなんて言わないでください。
高校3年間英語赤点なんですから。

ちゃんちゃん♪

Inkscapeの矩形はサイズに線の太さも含んでいた

Inkscape0.47での話です。
矩形を描いて線の太さを設定して、EPSに変換すると大きさが微妙にずれる。
なぜかと思っていじっていると、線の太さを変えると大きさも変化しているではないか。
つまり、Inkscapeの場合、パスのサイズではなく、実際の描画イメージのサイズだったらしい。
今まで散々いじってきたのにぜんぜん気が付かなかった。
EPSでは通常パスを基準にするため、てっきりそうだと思い込んでいたというわけだ。
0mmでサイズを指定して線の太さを指定すればずれないだろうけど、画面上から消えてしまうの。
プリントライのデータも全部作りなおしだぁ~

OpenOffice.orgの3.2を使ってみた

2010年02月11日にOpenOffice.orgの3.2が公開されました。
14日に気がついたので早速落し、3.1から入れ替えて使い込んでみました。

普段から使っている機能には更新がないので、個人的には変化なしといったところです。
保存のプロセスが重いのはまだ改善されませんね。

excelと比較して・・・といいたいところですが、Microsoftのoffice2000を最後にOpenOffice.orgに乗り換えたので、比較しようがないのをおもいだしました。

Inkscapeがいつのまにか0.47になっていた

Illustrator要らずのパス系ツールのInkscapeです。
お仕事でEPSを描くときもInkscapeで充分です。
むしろ汚いEPSを吐き出すIllustratorよりも美しいEPSを吐き出すInkscapeのほうが、コーダにとっては評価は上です。

2009年の11月24日にバージョン0.47がリリースされていたようなので、早速入れ替えてみました。
メニューが一部変化したのと、日本語化されている場所が増えました。
操作面ではそんなに違いはなかったのですが、マスクやクリップがEPSで出力されない不具合が修正されていました。とても助かります。
あとはCMYKで出力できれば言うことなしなのですが。RGBを単純に変換しただけでもかまわないんですけどね~

IE8でデザインが崩壊する

Windows XP、Vista、7で利用できるブラウザのInternetExplorer8では、スタイルシートの実装が今まで以上にいい加減に実装されているらしく、IE6,7向けに調整されたものですらデザインが崩れます。
つくりが悪いといってもOSにはじめから入っているブラウザなのでどうしてもユーザ葉多いため対応せざるを得ません。
この仕様(不具合)を回避するためのIE7と同じレンダリングを行う「互換モード」なるものがIE8には用意されていますが、ユーザ側でいちいち切り替えなければなりません。
しかし、それすらも想定の範囲内のようで、互換モードを強制するmetaタグが用意されていました。
次のようなおまじないを唱えておきましょう。

<meta http-equiv="X-UA-Compatible" content="IE=emulateIE7">

これで安心。

MySQLで特定のデータベースをダンプする

MySQL Ver14.12 Distrib 5.0.45, for redhat-linux-gnu (i686)での話です。
データベースをコピーしようともって、cronで保存してあったDUMPファイルをインポートしようと思ったらファイル形式が違うといわれてショック。
これじゃバックアップの意味ないじゃん?
原因は・・・なんだろ?
とりあえず目先の問題を解決することにして、mysqlをダンプします。

mysql -u root database > dump.sql


データベースがでかいほど時間がかかるのはお約束です。

さて、お次はインポート。
正確にはインポートとは言わないらしいけど。

mysql -u root database < dump.sql


これもデータベースが大きいとそこそこ時間がかかります。
つまり、<と>を切り替えるだけでok。

これで、めでたしめでたし。

Firefox3.5が酷い

最近3.5にバージョンアップしたのですが、、3.5は重くて使えません。
ロケーションバーをコピペしようとしても文字が消えたり、「履歴とブックマークを検索」に変わったかと思うと、URLが二度と表示されなくなったりします。
JavaScriptが高速になったらしいですが、そのぶんメモリを食うようになってOS(Vista)がFirefoxにロックをかけて、画面の再描画に1分ぐらいかかることがあります。
3のころにはそういうのはまったく発生しませんでした。
アドオンもなかなか対応してくれず、マウスジェスチャ系も全滅です。

パッチがこれば直るだろうとダウングレードもせず、Firefox3の使い勝手に気をよくして封印していたOperaを再度引っ張り出して使うのでした。

イラストレーターのEPSデータを考察

イラストレータといっても、手持ちのは古いままで7でのお話です。
EPSで保存すると、プレビューとサムネールを保存するかどうかの確認がありますが、これはいったいどのように格納されているかを調べてみました。

調べるといっても、サムネイルもプレビューも含まないで保存したEPSファイルと、サムネイルまたはプレビューを含んだEPSファイルを比較しただけです。

保存したファイル名と保存日時のデータは無視して、それ以外を比較します。

まず、サムネイルを含んだEPSファイルを比較しました。
違っていたのは、以下のとおりです。
46行目にある
%AI7_Thumbnail: 128 128 8
から
%%EndData
これが、サムネイルデータのようです。
バイナリが16進で格納されているようです。
どの画像形式かはわかりませんが、おそらくTIFFではないでしょうか。

次に、プレビューを含んだEPSファイルを比較しました。
違っていたのは、以下のとおりです。
1行目の先頭にバイナリデータが含まれています。
その後に通常のEPSデータが始まります。
%!PS-Adobe-3.0 EPSF-3.0
そして34行目に、
プレビューを含まないEPSファイルでは
%AI3_DocumentPreview: Header
となっているところが、
プレビューを含むEPSファイルでは
%AI3_DocumentPreview: PC_ColorTIFF
となっいます。
そして一番最後にまたバイナリデータが含まれています。
通常のEPSデータの末尾である
%%EOF
の後に、バイナリデータが追加されています。

他のイラストレータのバージョンでは、また違うかもしれません。
比較に使用したファイルをおいておきます。
サムネイルもプレビューも含まないEPSファイル
サムネイルを含むEPSファイル
プレビューを含むEPSファイル