2012/02/21(火)perl で PDF ファイルのサムネイルを表示
2017/10/12 4:52
perl にて「ＰＤＦ文書の１ページをサムネイルのように表示させたい」という場合、そのままでは出来ないため、ImageMagick本体、Image::Magick、Ghostscript 、vflib といったようなものを使い、PDF 文書の特>定のページを png か jpeg に変換してブラウザに出力するような CGI を使うことになります。
Image::Magick は Perl モジュールですが、ImageMagick を構築する際、 --with-perl オプションをつけると、一緒にインストールされます。
また、PDF 文書から jpeg や png に変換する際は、Ghostscript と vflib を予めインストールし、ImageMagick を構築する際に
--with-gslib
--with-gs-font-dir=/usr/local/share/ghostscript/fonts
を追加すると確実です。
こうして
use Image::Magick
my $pdffile = "sample.pdf[0]" ; # [0] で最初のページという意味になる。
my $tmbfile = "sample.png" ;
my $image_width = 500 ; # 横幅をpx 数 で。縦は同じ比で拡縮する。
my $pdfobj = Image::Magick->new ;
$pdfobj->Read($pdffile) ;
$pdfobj->Transform(geometry => $image_width) ;
$pdfobj->Write('png:' . $tmbfile) ;
のようにすると出来るはずだが・・・
実際には何も表示されず、サーバのエラーログに
gs: command not found
が出る始末。
どうも /usr/bin/gs へアクセスしようとして、その実体は FreeBSD のポリシー的な内容からして、 /usr/local/bin/gs にあるのが原因らしい。
おそらく、構築時か実行環境の問題なのだろうが、root になって、
# cd /usr/bin
# ln -s /usr/local/bin/gs
とすると、回避する。
すっきりしませんが、これで稼動できたのでとりあえずこのまま。
2011/12/01(木)[Perl5] 騙されたなぁorz
2017/10/12 4:44
use IO::Socket;
unlink "/tmp/mysock";
$server = IO::Socket::UNIX->new(LocalAddr => "/tmp/mysock",
Type => SOCK_DGRAM,
Listen => 5 )
or die $@;
$client = IO::Socket::UNIX->new(PeerAddr => "/tmp/mysock",
Type => SOCK_DGRAM,
Timeout => 10 )
or die $@;
しかし、はっきり言って騙されました。
見かけ上は起動するけれど、実際はソケットファイルが作成されないです。
これが、現行で正しい例：
use IO::Socket
my $socket_path = '/tmp/wibble';
unlink($socket_path);
my $server = IO::Socket::UNIX->new( Type => SOCK_STREAM,
Local => $socket_path,
Listen => 5 )
or die("Can't create server socket: $!\n");
my $sock = $server->accept() or die("Can't accept connection: $!\n");
my $client = IO::Socket::UNIX->new( Type => SOCK_STREAM,
Peer => $socket_path, )
or die("Can't connect to server: $!\n");
LocalAddr ではなく Local 、 PeerAddr ではなく、Peer です。今更ながら気付いたのですが、Perl CookBook 第一版 は、2001年刊行の本でした。
Perl 4 から Perl 5 に移行して間もない頃で、確かにハッシュパラメータ名などは違っていたかも・・・です。
2011/10/02(日)PDFJ は perl5.12 では動作しない模様
2017/10/12 4:40
日本人による日本語の解説などあって重宝 ← 英語判らない者にとって重要
していた訳だが、perl 5.10 用にパッチあてても駄目ぽい。
どこかで無限ループになっているようで、いつまでたっても処理が終わりません。
世の中は PDFJ よりは、PDF::API2 を使わせたいらしいが、どれも定型フォーマットを別途PDF にて作成し、それに差し込みする形態の事例ばかりで、適用したいシステムでは全く参考にできない。。
項目数にあわせて罫線を動的に引く形ですが、定型フォーマット方式では、これが出来ないというわけです。
かといって、日本語の説明があまり無くて、結局使い方がよく判らずという状況。
ぢゃあ、PDFJ を改造すれば？ という話になるのでしょうが、そういう時間取れないというわけで。。orz
どうにかしたいですが、どうしようも出来ないので、PDF 出力できないのを我慢してもらうしか・・・
〔追記 2012/02/02〕
このあとすぐに気づいて、無限ループに対処する内容として、 「Safe に対するパッチ」というものを入れましたが、これは Safe 2.27 に対するもので、最新は 2.29 になっており 、このバージョンにおいては、対処されており、パッチは必要ないです。
ですが、無限ループしなくなっただけで、今度は、不明なエラーを吐かれる状況。
原因を追いかける時間は全く取れないので、ほったらかし状態になっていますorz
2011/09/27(火)perl CPAN ExtUtils-MakeMaker のインストール時ハングアップ
2017/10/12 4:38
同じ環境による同じ現象のバグ報告(#70232)が上がってはいます。
https://rt.cpan.org/Public/Bug/Display.html?id=70232
英語がダメダメなσ(^^) はこういう場に出れないのだが。。orz
--- ここから
Manifying blib/man3/ExtUtils::MM_Any.3 MSTROUT/ExtUtils-MakeMaker-6.59.tar.gz /usr/bin/make -- OK Running make test PERL_DL_NONLAZY=1 /usr/local/bin/perl "-Iblib/arch" "-Iblib/lib" "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib','blib/arch')" t/*.t t/00compile.t ............. ok t/arch_check.t ............ ok t/backwards.t ............. ok t/basic.t ................. ok t/build_man.t ............. ok t/cd.t .................... ok t/config.t ................ ok t/dir_target.t ............ ok t/FIRST_MAKEFILE.t ........ ok t/fix_libs.t .............. ok t/fixin.t ................. ok t/hints.t ................. ok t/INST.t .................. ok t/INST_PREFIX.t ........... ok t/INSTALL_BASE.t .......... 1/20--- ここまで
t/INSTALL_BASE.t のところで、こんな感じでハングアップし、crtl+C でテストを中断する羽目になります。
このモジュールが 6.58 になったときからの現象で、perl のバージョンは 5.12 でも 5.14 でもこの現象は発生。現在の公開バージョンは 6.59 ですが、一向に解決されていません。
とりあえず、当方は、 force install ... で凌いでいます。
2011/09/12(月)携帯向け音声ストリーミングファイルの形式
2017/10/12 4:36
docomo
3gpファイル
AAC LC モノラル ビットレート＝22kbps サンプルレート＝16kbps
ファイルの最大サイズ 10Mbyte
au
3g2ファイル
AAC LC モノラル ビットレート＝22kbps サンプルレート＝16kbps
ファイルの最大サイズ 2Mbyte
softbank
3gpファイル
AMR-NB モノラル ビットレート＝ 8kbps サンプルレート＝8kbps
ファイルの最大サイズ 300kbyte
上記でないと、どうも上手く再生できないことが多い。
一番制限が厳しいのはソフトバンクで、このパラメータ以外では再生がまともに出来ない。
音質も極限まで落とす形になります。
特にファイルサイズが致命的で、約４分以上の音声ストリーミングは不可能です。
その点、docomo は 10Mbyte で AAR LC であれば、ステレオで 128kbps でも再生できます。但し、10MByte の制限に注意が必要です。
2011/01/17(月)CGI に使う言語
2017/10/12 4:16
日本では、
PHP , Java というのがもてはやされている模様。
ですが、これはちょっとガラパゴス化している可能性が最近出てきた感ありです。
元々当方は、メンテナンスの点で PHP は否定的、 Java は無駄に高性能なハードウェアを要求する点で否定的。
当方的に推奨できるのは Perl です。あと、ruby。Ｃ言語や Ｃ＋＋，Ｃ＃ もありです。
こう書くと、嘲笑の対象なんですな、、しかしです。嘲笑するような奴らは、はっきり言ってＩＴゼネコンに洗脳されています。
Java は、ＩＴゼネコンのひとつである、富士通が主に推進し、ごり押ししました。
それが実体。資金力に任せてＡＰＩを提供してきたので、そこそこ使えるのでしょう。
しかし、無駄にハードウェアを高性能化することを要求されるため、ハードウェアの売り上げに繋がる、という商業的な理由があります。
だから、当方はそういうのは承服できないのです。
PHP は、バージョンアップの度に、過去の互換性検証を強要されます。
これだけでもうメンテナンス性がダメダメです。
作りっぱなしなら問題ないけれど、ここでも「互換性検証」という名目で売り上げ増や維持に繋がる、という商業的理由があります。
PHP もＩＴゼネコンが半ばごり押しした言語。
一方で、Perl は１０年前に作成したものであっても、セキュリティ問題等さえなければ、何の問題もなく、さくっと動作するのです。こういうのを「後方互換性が優れている」と評価します。Windows で言えば、 Windows 95 の時代に作ったアプリケーションが、Windows 7 や Windows XP でも何の問題もなく、さくっと動作するという感じです。
ruby 、C++、C# なんかも、そんな傾向です。
perl であれば、商業的なことで、無駄なことしなくて済むのです。
だから、米国やインドなどの日本以外の国では、Perl や ruby が見直されてきています。
だが、商業的には都合が悪いかもしれません。
日本のＩＴゼネコン達は Perl や ruby を使うことは否定的です。
若干話題から脱線しますが、「フレームワーク」というプログラム制作上の枠組みを設けることが、均質で質のよいプログラムを作る礎と思い込んでいる勘違いマネージャーもおり、ますます日本のソフトウェア産業 の未来は懐疑的です。
無駄削減を従業員に強要する企業が、顧客に無駄を強要しているのです。
システム開発は、ウチのような中小の方がいい仕事できます。
ただ、ＩＴゼネコンの下請け会社のようなところは避けましょう。
弊社は、ＩＴゼネコンの下請けはしていません。下請けになれば、技術者は育たない。それが体感として判っているからです。
だから、最初からプロジェクトを任された場合に限るのですが、ある程度の能力的自信はあります。
2010/12/20(月)原因は M$社なのに、、、
2017/10/12 4:14
当初、原因判らず、挙句の果てには、当方が同時期に提供したシステム更新のせいでは？
との話しもあったが、原因は、Windows Update によって、IEでiso-2022-jp (JISコード) な文字コードが判別出来なくなったもの。
参考資料→ [MS10-090] Internet Explorer 用の累積的なセキュリティ更新プログラム
なので、 12/15 以降公開の Windows Update を行い、IE にて iso-2022-jp なサイトを閲覧しようとしたときのみ文字化けが発生するわけです。
弊社サイトは、この条件で見事に文字化けするようになりました、、
Firefox や Chrome では、この問題は起きません。
本来、サーバサイドにて対応すべき問題ではありません。
しかし、IE ユーザ層は自力解決困難なユーザ層が大半なので、完全に無視するわけにもいきません。
結局、兼ねてから予定していた弊社サイトの UTF-8 化を前倒しでやってしまいました。
損害賠償をＭ＄社からもらえるわけではありません。
しかし、損害を被っています。
尖閣諸島近海で、中国籍の漁船が海上保安庁の巡視船に意図的体当たりして明らかな「公務執行妨害」なのに無罪放免され、その様子を撮影した動画を政府の意図に反して公開した公務員が罪に問われるということに 似ています。
ユーザサイドに立てばかなり大きな問題ですが、殆ど騒がれませんでした。
ここからして、思考回路の何かが変だ。
権力か覇権あれば、何やっても許されるんですか。おかしな社会だ。
2010/11/25(木)javascript なクロスフェード表示
2017/10/12 4:13
音楽でも曲が入れ替わる時に使う常套手法です。
散々既出ですが、メモ代わりということで、、
提供時期は少し古いですが、最新のIE8,Firefox 3.6,Chrome で動作確認しました。
先ず、クロスフェード Javascript をダウンロード し、Ｗｅｂサーバにアップロード。
次に、対象がある HTML ファイルに以下の一文を <head> - </head> の間に追記。
<script type="text/javascript" src="bsn.Crossfader.js"></script>
次に、実際にクロスフェードさせたい内容を記述。
<span id="disp1">文字列１</span>
<span id="disp2">文字列２</span>
<span id="disp3">文字列３</span>
<div> 要素を使う説明が多いらしいですが、id 属性が付与できる要素であれば、何でもいいようです。
最後に、上記記述を行った直後の位置に、以下のような記述を行います。
<script type="text/javascript">
var cf = new Crossfader( new Array('disp1' , 'disp2' , 'disp3'), 1800, 4500 );
</script>
外部ファイルにしても良いです。
最後の２つの数値はフェードエフェクトの時間と、要素の表示時間の設定です。
この例だと、
* フェードエフェクトの時間 ： 1800ms
* 各要素の表示時間 ： 4500ms
のようになります。
まぁ、特定の要素だけ長く表示するようなことは、スクリプト改造でもしないと出来ません。あとはお好みで。
2010/10/13(水)SoftBank 3G携帯はある意味デリケート
2017/10/12 4:07
UTF-8 いわゆるUnicode で制作する場合に特に注意すべきこと。
<meta content="text/html; charset=utf-8" http-equiv="content-type">と、最初記述していました。
これだと、シミュレータ上では、きちんと表示されるのに、いざ実機確認すると、文字化けしたり、全く表示されなくなったりするのです。
すなわち、この <meta> タグは無視されます。
ページのコードが Shift_JIS の場合は、特に問題起きません。
保証はしていないようですが、多くの SoftBank 携帯は、ページの文字コードは、デフォルトで Shift_JIS であると決め打ちする挙動のようです。
文字コードを指定する <meta> タグは以下のとおりに記述しないと、正しく認識されないようです。
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">パラメータの順番・値はこの通りにしないと駄目です。
このことについて携帯キャリアに質問しても『仕様です』と突っぱねられる（少なくとも Vodafone時代は そんな対応だった）ので、時間の無駄です。
なぜ Unicode で制作しているか。
それは、比較的近い将来に多言語共存環境が予測できる為です。
ということで参考にどーぞ。
2010/04/20(火)Javascript での画像情報取得
2017/10/12 3:53
function check_image(uri) {
imgobj = new Image() ;
imgobj.src = uri ;
var iwidth = imgobj.width ;
var iheight = imgobj.height ;
var sparam = 'width=' + iwidth + ',height=' + iheight + ',toolbar=0,menubar=0,scrollbars=0' ;
subimg = open(uri, "imgdisp", sparam) ;
}
上記のように記述したら、子ウィンドウがパラメータ uri で指定する画像のサイズに合わせて開く計算だったのだが、１回目に所定より小さいサイズの子ウィンドウが開き、そのウィンドウを閉じた上でもう一度実行させると、やりたいことが出来るという現象。uri に指定するのは、画像のＵＲＬを指定するようにしていますが、これがフォームでアップロードさせた画像ファイルなせいか、適切な拡張子をつけないせいか、どうにも上手くいきません。
結局、CGI 側にて、アップロードした画像ファイルのサイズを抽出し、上記の Javascript にそのサイズを指定するようにすることで回避しました。こんな感じ。
function check_image(uri,iwidth,iheight) {
var sparam = 'width=' + iwidth + ',height=' + iheight + ',toolbar=0,menubar=0,scrollbars=0' ;
subimg = open(uri, "imgdisp", sparam) ;
}