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

少々前の話なのですが、運営中のサイトでプリントライがあるのですが、データ入稿用のトンボの作成方法のページをがんばって作ってみました。
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ファイル

mod_perlでライブラリが見つけられない

通常のCGIでは問題なく動くスクリプトを、いざmod_perl環境下に置いたとたんに動かなくなるのはよくある話。
変数や配列などの初期化がいい加減で、どんどん肥大化してしまうのは、日ごろから心がければ何とか回避できるものの、いまだに良くわからないエラーが次のもの。
「Undefined subroutine &ModPerl::ROOT::ModPerl::Registry::」
Registryの後には実行されるスクリプトのパスが入る。
つまり、mod_perl環境下で実行ファイルはモジュールとして扱われる。
このため、ライブラリやモジュールの読み込みまわりで順番がおかしくなり、ファイルが見つからないといわれることになるのだ。

この文字を検索すると以下のようなサンプルが表示される。

LoadModule perl_module modules/mod_perl.so

PerlRequire "/path/to/startup.pl"


SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI


# in startup.pl, i have this:
use lib "/path/to/webObjects";
use Apache2 ( );
use ModPerl::Registry ( );

use Carp;
use CGI;

use lib_webObjects;
1; 


startup.plを読めばいいらしいのだが、そのとおりにやってもサーバーエラーになる。Apacheのエラーログを見ても同じメッセージか載ってないので、構文エラーという前に効果がないのかもしれない。
日本語のサイトがひとつも見つからないときは、英語が苦手でなければと常に思う。
しかし、このエラーも.htaccessと、httpd.confにディレクトリで指定したときでは挙動が違うような気がする。
Apache起動時に読み込ませた環境では、実行時に読む.htaccessと違うのはもちろん当たりまえなのだが、解決方法が見つからなければいくら原因がわかっていてもしょうがないのである・・・

さてはて、いったいどうしたものか。
最悪の場合、ライブラリをやめて1つのファイルに全部詰め込む荒業に出るか?