2008 11月 » TECH Matari

11月 26

PDFからJPEGやPNG画像を作成

例）hoge.pdfの表紙（1ページ目）から解像度72dpiのout.pngを作成

Ghostscriptの場合

#gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pngalpha -r72 -dFirstPage=1 -dLastPage=1 -sOutputFile=out.png hoge.pdf

解像度とかを指定したりできるしねー。

ImageMagickの場合

#convert hoge.pdf[0] out.png

こりゃ楽だなぁ。

PHP + ImageMagick ⇒ pecl :: Imagick の場合
※最新バージョンを利用するにはPHP5.1.3以上、ImageMagick6.2以上が必要です。
インストールはpecl install imagick

$img = new Imagick('hoge.pdf');
$img->setImageIndex(0);
$img->writeImage('out.png');
//$img->writeImages('out.png');とすると全ページを画像にしてくれる
$img->destroy();

もちろんリサイズとかもOK。

ImageMagick以外にもGraphicMagickとかあるのね。ImageMagick2もあるらしい。

Popularity: 22% [?]

written by joy-pop

11月 26

[あえて]concrete5が残念な4つの理由

CMS, ウェブサイト 14 Comments »

話題沸騰wのconcrete5。至る所でべた褒めなので、あえて、ここは他のCMSに劣ってたり、そこんどこどうよ？的な点について考えてみることにした。

反論・異論・サジェスチョンなどありましたら、遠慮無くどうぞ。

1.テーマファイルの少なさ（皆無）

ビジュアルを切り替えるための機構、concrete5の場合はThemeという。WordPressのTheme(テーマ)や他Blog,CMSでのスキン、テンプレートに該当する機能。
要するにデザイン部分をフルスクラッチせずに、ｶｯﾁｮよくさくっと切り替えるためのデータファイルが、有志のデザイナーさん達によって作られ、配布されていたりして、それを利用できるか否か。

デフォルトでconcrete5には、２つのシンプルなテーマが内蔵されているが、今のところ、それ以外が皆無。WordPressと比較してもしょうがないが、WordPressには膨大なThemeファイルが配布されており、中にはかなりイケてるものもあり、カスタマイズのドキュメントも割と豊富。後発のconcrete5はこのあたりが圧倒的に不利。（まぁ、後発なので仕方ない？）

既存CMSと互換性があれば最高なのだろうが、どうなんだろう。常識的に考えて難しいよね。

配布されているテーマファイルが少ない＝見た目が他のサイトと同じ（選択肢がない）＝ダサい＝採用しずらい

もっと豊富にテーマファイルが無ければ、個人および企業で採用されずらいと思う。

個別にテーマファイルを作るのも、正直、大変そう。積極的にはやりたくないが、逆に考えると、今ならアドバンテージを取れる？？

2.完全日本語対応がややこしい

マルチリンガルに対応するためのメッセージファイルの、日本語版を用意すればさくっといけるかな？と思いきや、そうは問屋が卸さない。編集画面などAjaxで処理を行ってる場合、JavaScriptとのからみで、日本語がエスケープされ符号化された状態で表示される場所がある。また、メール送信その他もろもろ、このあたりは全ての動作を確認しながら日本語化に対応していくしかない。メッセージファイルのみでは対応できないので、本家にコミットしていける知力・体力がある人に他力本願的に頼らざるを得ない。ちょうどいい案件があれば、独自にやってもいいけど…。

3.拡張性の低さ(プラグインが皆無)

またもやWordPressとの比較になってしまうが、テーマよろしく、WordPressにはプラグインも膨大に存在する。また、日本語による開発ドキュメントも容易に入手できる。

現時点のconcrete5には、配布されているプラグイン的なファイルが見つからない。（僕が見つけきれないだけ？）
concrete5には、ブロックタイプとアプリケーションという２種類のタイプでの機能拡張が存在するようだが、いずれもサードーパティというか、外部で配布されているファイルが皆無だし、ドコまでのことができるのかすら、見えてこない部分もある。NucleusやWordPressのプラグインは、ちょっと調べれば作るのは簡単だし、割と何でも出来てしまう。（逆にそれが良くない場合もあるけど）

concrete5のように機能がある程度完成していると、ローレベルのAPIというか、コアの機能にアクセスするためのAPI当は無かったり、制限されてたりするんじゃないだろうか。

4.直感的な編集操作が良い、とは限らない

これについてはまだ意見を絞り込めてないのだけれど、直感的な操作というのは、突き詰めていくと、反比例的に非効率的になると思う。
ミクロなレベルで申し訳ないが、textareaをGUI的に編集できるFCKEditorやTinyEdit？などあるけれど、希望通りに編集できなくて、ものすごくイライラするときがある。それがサイトレベルになると、いかに機能を充実させようと、素のHTMLには適わない。もちろん、CMSなのでそれをやってしまったら意味がないのだが、中途半端に直感的に変更できると余計にストレスが溜まるというのは、皆さんも経験則としてありませんか？

まぁ、ここを否定してしまうとconcrete5の存在意義すら疑うことになってしまうがｗ

ところで、既にいくつか日本語化についての動きがある模様。いいぞー！やれやれー！やったれー！父の敵討ちのつもりでやったれー！

Google Analytics(アナリティクス)でリンクをトラッキングする方法

Javascript, tips, ウェブサイト 1 Comment »

ページ毎のデータは、普通にアナリティクスさんから提示されたコードを埋め込めばよいけど、内部リンク／外部リンク、たとえば、画像やPDFへリンクした場合、その画像/PDFそのものには解析コードを埋め込めないため、表示数がカウントできない。

そういう場合は、そのリンクにトラッキングコードを埋め込めば、データを解析できる。今回はその方法など。

大きく分けて、urchinのバージョンによって２パターンあるので要注意。
バージョン判別方法は、こちら→トラッキングコードのどのバージョンを使用しているか教えてください。 – Google Analytics ヘルプセンター

旧バージョンの場合(urchin.js)

基本的には、onClickに、urchineTracker関数をコールすればOK。引数はジャンプ先のURLと思われがちだが、かならずしもURLである必要はない。アナリティクス内で識別するためのIDと思えばOK。
たとえば、１ページなりに、同一ページへのリンクが複数あり、それぞれのリンクをトラッキングしたい場合、

<a href="/promo/hoge.html" onClick="javascript:urchinTracker('hoge1');">
（コンテンツ）
</a><a href="/promo/hoge.html" onClick="javascript:urchinTracker('hoge2');">
</a>

とすれば、それぞれのリンクからのデータを解析対象にできる。

参考：JavaScript イベントをトラッキングするにはどうすればよいですか。 – Google Analytics ヘルプセンター

新バージョンの場合(ga.js)

基本的には上と同じだけれど、呼び出す関数が違うので注意されたし。

<a href="/promo/hoge.html" onClick="javascript:pageTracker._trackPageview('hoge1');">
（コンテンツ）
</a><a href="/promo/hoge.html" onClick="javascript:pageTracker._trackPageview('hoge2');">
</a>

参考：JavaScript イベントをトラッキングするにはどうすればよいですか。 – Google Analytics ヘルプセンター

Popularity: 31% [?]

written by ANN

11月 18