ai保存・大流行
最近おのみちの会社のデザイナー・オペレータの間では、illustrator_CS2で作ればeps保存しなくていいんだっ、という噂が蔓延しています。
「拡張子がaiのままだけどepsにしなくていいの？」と訊くと
「あっ、いいのいいの、aiのままだって受け取ってくれるし、文句言われたことないし。それにCS2で作ったから大丈夫だよ。epsは重くてMOに入らないから、やなんだよ」
ほ、ほんとか？
これまで長らく入稿データはeps保存でね！を金科玉条にしていた営業職の身の上からすれば、にわかには信じがたい。
そのくせillustrator_CS2に配置する画像データだけは、
かたくなにEPSバイナリ保存を守り通している（このへんが妙に保守的）。
というわけで弊社の制作現場は毎日のように入稿データ.aiを量産しつづけているのである。
印刷屋さんの現場の人に迷惑かけていなければ、
それでいいんだけど・・・。
IllustratorCSデフォルトで入稿してきた物をInDesignCSに貼って流したら、出力時に「スジ」が入ったりしたようです。RIPはTFPですけど、なんか出し方が変なのではと思ったりもしますが、うちの場合は、EPS保存して貼り込んでねといわれています。私はTFPの方はまったくといっていいほど知らないので、CSレベルではPS書き出しをして、CS2からPDF書き出しをしていたような様子が関係しているのかな？出力側は驚くほど保守的で呆れることもありますけど、他の会社の方々の意見希望！！
確かAdobeでは.aiを推奨していたような？
最近オペレータの事情はあまり知りませんが、うちでは特に決まりはないように思います。
私はデータ作る側です。
CSで作業してる印刷会社とは、ai、psdのままでInDesignに配置。
出力はPDFです。
2年くらいこれでやってますが事故が起こったことはないです。
ここ最近 AI 入稿も受け付けるようになってきた背景には、データの重さがあると思います。特に、Illustrator 9 からの改悪で、AI 形式ですら重たいデータになりがちですから、オンラインで入稿するとかいう場合は、EPS を強制できない場面が多々あります。
おかげで、出力側のオペレータは AI 入稿の時と、EPS 入稿の時の両方の場合の作業手順を覚える必要が生じました。
＞確かAdobeでは.aiを推奨していたような？
確かにアドビのセミナーでのトレーナーの方は、AI を推奨していました。また、僕の blog でコメントを書いてくれた Illustrator の開発者の方も、やはり EPS はレガシーであるというニュアンスのことをかかれていました。
しかし、アドビがどういうのではなくて、印刷事故を起こさないのが第一なので、アドビがどういったから、ていう根拠で判断するのは誠に危険で、新しいバージョンがでるたびに、どのような危険性があるかを検証するという姿勢で望むのがあるべき姿だと思います。
さて、本件のポイントは、最終出力形態が、PS ワークフローか、PDF ワークフローか、によって、変わってきます。
最終が PS ワークフローであれば、EPS 保存の方向がベースになるし、PDF ワークフローであれば、PDF 保存になります。
保存形式が決まれば、配置する画像形式も自動的に決まってきます。PS 保存するならば、配置するのは EPS は OK、PDF 保存するのならば、配置する画像は EPS は NG です。
あと、InDesign CS と同じ世代の PDF Library を持っている製品は捨ててください。誰かが不幸になります。InDesign CS に AI 形式（内部は PDF）を貼ると運が悪いと事故ります。
～～～
というわけで、出力先に聞けっていうことになります。いつもの話なんですが。
～～～
補足ですが、入稿先（出力側）で EPS で保存し直したり、PDF で保存し直したりしていることも考えられますから、入稿時の形式をいくら注意しても印刷事故を回避できない場合もあります。南無～
>最終が PS ワークフローであれば、EPS 保存の方向がベースになるし、PDF ワークフローであれば、PDF 保存になります。
⇒おー、なるほど。そこがポイントですか。
>保存形式が決まれば、配置する画像形式も自動的に決まってきます。PS 保存するならば、配置するのは EPS は OK、PDF 保存するのならば、配置する画像は EPS は NG です。
⇒つまり、
【PSワークフローの場合】イラレ：EPS保存／配置画像：EPS保存
【PDFワークフローの場合】イラレ：ai保存／配置画像：psd保存
というわけですね。うーむ、かなり勉強になるなー。
でもウチの制作現場のようにai保存で配置画像：EPS保存（バイナリ）してる場合はどうなっているのでしょうねえ。どなたか不幸になってるのでしょうか。
>あと、InDesign CS と同じ世代の PDF Library を持っている製品は捨ててください。誰かが不幸になります。InDesign CS に AI 形式（内部は PDF）を貼ると運が悪いと事故ります。
⇒はい、すでに捨てました。
＞でもウチの制作現場のようにai保存で配置画像：EPS保存（バイナリ）してる場合はどうなっているのでしょうねえ。どなたか不幸になってるのでしょうか。
出力先がPDFワークフローの場合、おそらく出力先のオペレータが、泣く泣く埋め込みし直しているんだと思います。
PDF ワークフローの場合、AI だとそのままでは出力できないと思うので、PDF に保存し直すわけですが、そのときに EPS 配置画像に悲劇がおこります。悲劇を回避するには、PDF 保存前に埋め込みをしておくことになります。
～～～
なんてさんざん言いましたがここら辺のルール、シビアに運用しているかどうか謎なんですよね。最近各社のオペレーションが秘密主義すぎて困る。
出力先がPDFワークフローの場合、おそらく出力先のオペレータが、泣く泣く埋め込みし直しているんだと思います。
⇒そのようなご迷惑をおかけしていましたか。
ai保存にEPS保存（バイナリ）画像を配置するなら
埋め込んで渡してあげた方が親切のようですね。
入稿側はCS/CS2になってから、画像の保存形式に対して非常に臆病です。
これまでずっとEPS保存（バイナリ）を信奉していたのに、
CS/CS2ならEPS保存はASCII85にして！と言われても、
なかなか切り替えることができないでいます（ウチだけか？）。
理由は明瞭。両者の違いがよくわからないから。。。
不勉強と言われればそれまでですが、バイナリとASCII85の違いが
入稿先の印刷屋さんにとって、どの程度重要なものなのか、
それを掴むことができないでいるので、ai保存でありながら、
配置画像だけはEPS保存（バイナリ）という"ねじれ"データを作っています
（過去の膨大な画像データもそのまま使えなくなってしまいますし・・・）。
＞ai保存にEPS保存（バイナリ）画像を配置するなら
＞埋め込んで渡してあげた方が親切のようですね。
ところがそうとも言えず、FullPress や、HELIOS ImageServer などの FPO/FLO 画像置換サーバシステムを使う場合は、配置じゃないと困ってしまう場合があります。つーわけでやっぱ聞くしかないんじゃないですか？
ASCII85 は、PostScript の仕様ではもともと使えることになっていたエンコーディングらしいんですけれども、Adobe の製品としてそれを表だって吐き出すものってなかったんで、PostScript 対応とはいえ、ASCII85 エンコーディングに対応していなかった製品は少なからずあります。たとえば、先ほどの HELIOS ImageServer の前バージョンは対応していませんでした。
ASCII85 がでてきたのは、通信路にバイナリを流せなかった Mac OS 10.2 あたりの制約の解消のために掘り起こしてきたんじゃねーかなーていう節があって、それがたまたま Illustrator CS の、バイナリエンコーディング EPS を保存すると開けなくなることがあるというエンバグを生じたときに、いい機会だということで仕様ということにしたんじゃねーかなーておもっとります。これは僕の脳内の説なのであしからず。
で、バイナリかASCII85か、ていうことですが、結局、これらの画像を誰が解釈するかっていうことになるわけです。とりあえず性能のいい PDF 変換ソフトを１つ確保しておけば大丈夫ですよー
2007年6月28日木曜日
色調補正
http://palcon.air-nifty.com/tarcas/2007/06/post_05ce.htmlより
スクリプトで自動化すれば結構使えるかも^^
↓OS9環境のブラウザでは上記blogがまともに表示されないので、肝心のリンク先。
https://iiiro.jp/
あとこれも（7/8追記）
http://www.certiad.jp/index.htm
http://www.certiad.jp/pdfqa_m/pdf_basic.htm
サイト内の透明分割の記述はメモメモ ....φ(ﾟ∀ﾟ;）ｽｹﾞｽｹﾞ
■透明は分割・統合を行っておく
最近のアプリケーションは、ほとんどが透明効果を利用できるようになっています。しかし、透明はPostScriptにはない観念なので、出力時に問題が起こるおそれがあります。古いRIPではエラーが出ることもあります。
ただ、新しいRIPのプリンタドライバでは、実出力前に一定のルールで透明を一般のベクトルデータと、ビットマップデータに振り分けるものがあります。これによってユーザーは透明が出力できるものと勘違いすることもあります。この場合、運がよければ画面表示と変わらない結果が得られますが、そうでない場合もあります。
そこで、透明を含むデータを安全に出力するには、出力以前に分割・統合をやっておく必要があります。これは、透明を一般のベクトルデータと、ビットマップデータに振り分ける作業です。分割・統合は、以下の３つのプロセスのいずれかで行うことになります。
（１）アプリケーション上で行う
（２）PDF作成時に行う
（３）PDFにしてからAcrobat上で行う
これらの違いは、アプリケーションの機能に依存します。（１）ができるアプリケーションは、Adobe Illustrator 8.0/9.0/10.0/CS/CS2のみです。（２）は、InDesignが該当します。Illustratorでも可能です。（３）はオフィスアプリケーションです。これらのアプリケーションは透明を処理（分割・統合）する機能を持っていないので、PDF変換後にAcrobat上で行うしかありません。
これから発売されるQuark7は（１）になるのか（２）になるのか、そしてどちらの方が出力が安定しているのか？
スクリプトで自動化すれば結構使えるかも^^
↓OS9環境のブラウザでは上記blogがまともに表示されないので、肝心のリンク先。
https://iiiro.jp/
あとこれも（7/8追記）
http://www.certiad.jp/index.htm
http://www.certiad.jp/pdfqa_m/pdf_basic.htm
サイト内の透明分割の記述はメモメモ ....φ(ﾟ∀ﾟ;）ｽｹﾞｽｹﾞ
■透明は分割・統合を行っておく
最近のアプリケーションは、ほとんどが透明効果を利用できるようになっています。しかし、透明はPostScriptにはない観念なので、出力時に問題が起こるおそれがあります。古いRIPではエラーが出ることもあります。
ただ、新しいRIPのプリンタドライバでは、実出力前に一定のルールで透明を一般のベクトルデータと、ビットマップデータに振り分けるものがあります。これによってユーザーは透明が出力できるものと勘違いすることもあります。この場合、運がよければ画面表示と変わらない結果が得られますが、そうでない場合もあります。
そこで、透明を含むデータを安全に出力するには、出力以前に分割・統合をやっておく必要があります。これは、透明を一般のベクトルデータと、ビットマップデータに振り分ける作業です。分割・統合は、以下の３つのプロセスのいずれかで行うことになります。
（１）アプリケーション上で行う
（２）PDF作成時に行う
（３）PDFにしてからAcrobat上で行う
これらの違いは、アプリケーションの機能に依存します。（１）ができるアプリケーションは、Adobe Illustrator 8.0/9.0/10.0/CS/CS2のみです。（２）は、InDesignが該当します。Illustratorでも可能です。（３）はオフィスアプリケーションです。これらのアプリケーションは透明を処理（分割・統合）する機能を持っていないので、PDF変換後にAcrobat上で行うしかありません。
これから発売されるQuark7は（１）になるのか（２）になるのか、そしてどちらの方が出力が安定しているのか？
2007年6月25日月曜日
メモ（CS3）
http://blog.bitcafe.biz/?eid=657728より引用
Adobe®Creative Suite 3
Adobe Creative Suite3ファミリーが発売になりましたが、
いろんなパッケージがあってまるでMS-Officeみたいになっちゃった
Adobe Creative Suite 3 Design Premium：印刷、Web、インタラクティブ、モバイルパブリッシング用ツール
Adobe Creative Suite 3 Design Standard:プロフェッショナルな印刷デザインに焦点を絞ったツール
Adobe Creative Suite 3 Web Premium：WebデザインとWeb開発のための選りすぐりツール
Adobe Creative Suite 3 Web Standard：プロフェッショナルなWeb開発者向けツール
Adobe Creative Suite 3 Production Premium：ビデオプロフェッショナル向けの総合的なポストプロダクションソリューション
Adobe Creative Suite 3 Master Collection：印刷、Web、インタラクティブ、モバイル、映像など、あらゆるメディアのデザインに向けて、かつてないほど総合的なクリエイティブ環境を提供するツールコレクション
Adobe®Creative Suite 3
Adobe Creative Suite3ファミリーが発売になりましたが、
いろんなパッケージがあってまるでMS-Officeみたいになっちゃった
Adobe Creative Suite 3 Design Premium：印刷、Web、インタラクティブ、モバイルパブリッシング用ツール
Adobe Creative Suite 3 Design Standard:プロフェッショナルな印刷デザインに焦点を絞ったツール
Adobe Creative Suite 3 Web Premium：WebデザインとWeb開発のための選りすぐりツール
Adobe Creative Suite 3 Web Standard：プロフェッショナルなWeb開発者向けツール
Adobe Creative Suite 3 Production Premium：ビデオプロフェッショナル向けの総合的なポストプロダクションソリューション
Adobe Creative Suite 3 Master Collection：印刷、Web、インタラクティブ、モバイル、映像など、あらゆるメディアのデザインに向けて、かつてないほど総合的なクリエイティブ環境を提供するツールコレクション
2007年6月21日木曜日
アルツになりかけ
毎日、ルーチンワークをやっていると馬鹿になるというか覚えていたのも忘れてくる。
・ワードに埋め込まれた画像ってhtml保存すると取り出せる。
・Quark4からマルチインクで特色の掛けあわせができる。
あと今日、知ったこと
http://woman-life.jugem.jp/?eid=16より
クライアントから支給されるイラストレーターのデータが
時々「画像が埋めこみ」された状態であることがあります。
それを知らないクライアント担当者さんから
「この画像の色を直して欲しい」
なんて注文が入る。
手順としては
イラストレーターに埋めこまれた画像を取り出して
フォトショップで補正して
イラストレーターにリンクし直す。
埋めこまれた画像を取り出すのはちょっと前までは面倒でした。
ところがバージョンCSになってから簡単に取り出せるようになったようです。
今日、知りましたΣ(￣_￣；)
単純にイラストレーターデータをフォトショップ6以上で開くと
ラスタライズウィンドウで
プルダウンメニューから「画像」を選べます
取り出したい画像を選択すればその画像がそのまま（色・解像度）取り出せます。
追記：http://Illustrator-ok.com/main_bbs/joyful.cgi?list=pickup&num=16602#16602より
上記文章をフォトショップCSから6に変更しました（09/05）
・ワードに埋め込まれた画像ってhtml保存すると取り出せる。
・Quark4からマルチインクで特色の掛けあわせができる。
あと今日、知ったこと
http://woman-life.jugem.jp/?eid=16より
クライアントから支給されるイラストレーターのデータが
時々「画像が埋めこみ」された状態であることがあります。
それを知らないクライアント担当者さんから
「この画像の色を直して欲しい」
なんて注文が入る。
手順としては
イラストレーターに埋めこまれた画像を取り出して
フォトショップで補正して
イラストレーターにリンクし直す。
埋めこまれた画像を取り出すのはちょっと前までは面倒でした。
ところがバージョンCSになってから簡単に取り出せるようになったようです。
今日、知りましたΣ(￣_￣；)
単純にイラストレーターデータをフォトショップ6以上で開くと
ラスタライズウィンドウで
プルダウンメニューから「画像」を選べます
取り出したい画像を選択すればその画像がそのまま（色・解像度）取り出せます。
追記：http://Illustrator-ok.com/main_bbs/joyful.cgi?list=pickup&num=16602#16602より
上記文章をフォトショップCSから6に変更しました（09/05）
FizzBuzz(Perl)
以前の日記でFizzBuzzを書いたが、Perlでどう書くのか苦戦していました。
答えはググれば良かったのね。
http://d.hatena.ne.jp/harupiyo/20070707より
まずはとにかく動作するものを作ってみる。
for(1..100){
$a = !($_%3)?'Fizz':'';
$a .= !($_%5)?'Buzz':'';
print $a || $_ , "\n";
}
ポイント
for の中身を1..100のように書けるのはPerl の好きなところ。美し。
use strict; してないので、変数を宣言せずに使って、コード字短。（普段これは当然やらないので、コレだけでも新鮮に思いました）
FizzやBuzz を出力したら数字は出力しないようにするので、|| 演算子を使ってどっちかを表示というのをやっています。
8/26に修正
答えはググれば良かったのね。
http://d.hatena.ne.jp/harupiyo/20070707より
まずはとにかく動作するものを作ってみる。
for(1..100){
$a = !($_%3)?'Fizz':'';
$a .= !($_%5)?'Buzz':'';
print $a || $_ , "\n";
}
ポイント
for の中身を1..100のように書けるのはPerl の好きなところ。美し。
use strict; してないので、変数を宣言せずに使って、コード字短。（普段これは当然やらないので、コレだけでも新鮮に思いました）
FizzやBuzz を出力したら数字は出力しないようにするので、|| 演算子を使ってどっちかを表示というのをやっています。
8/26に修正
2007年5月29日火曜日
エンコーディング
ちょっと気になったことがあったので
http://www2.convention.jp/pdf/dictionary/j/01_e/encoding/encoding.htmより引用。
エンコーディング [一般]
フォントで文字の割り当てを決める文字コードの種類のこと。符号化方式とも言う。PDFファイルでは「フォント情報」を見ると、その文書のエンコーディングを知ることができる。主なエンコーディング方法は下記の通り。
Identity-H PDF独自のCIDエンコードに準拠してコード付けされたもの。縦書きは「Identity-V」 日本語
90ms-RKSJ-H WindowsでのMicrosoftのエンコード。縦書きは「90ms-RKSJ-V」 日本語
90pv-RKSJ-H MacintoshのTrue Type(トゥルータイプ)フォント標準のエンコード。縦書きは「90pv-RKSJ-V」 日本語
83pv-RKSJ-H MacintoshのPostScriptフォント標準のエンコード。縦書きは「83pv-RKSJ-V」 日本語
Windows WindowsのDistillerとPDF Writer、MacintoshのDistillerで変換された、欧文フォントのエンコード。 欧文
MacRoman MacintoshのPDF Writerで変換された、欧文フォントのエンコード。 欧文
例えば「90ms-RKSJ-H」を細かく見ていくと、次のような構造になっている。
文字セット 90ms WindowsでのMicrosoftの文字セット
90pv Macintoshの漢字Talk7で採用された文字セット。True Type(トゥルータイプ)フォント標準
83pv Macintoshの漢字Talk6で採用された文字セット。PostScriptフォント標準
Add 富士通のパソコンでの文字セット
Ext NEC PC98用の文字セット
符号化方式 RKSJ Romaji Kana Shift JISの略。シフトJISの文字コード
特に表記のない場合は、JISを表す
EUC Extended Unix Codeの略。Unixで使われる
組方向 H Horizontalの略。拗促音や括弧などの記号類が、横書き用の文字であることを表す
V Verticalの略。拗促音や括弧などの記号類が、縦書き用の文字であることを表す
http://www.namikawa.co.jp/namikawaset.pdfより
欧文TrueTypeはPDFにした時にエンコードがカスタムになっていないとáやà等の文字が抜けたり、化けたりする。
QuarkからPSに書き出す時に「TrueType」を優先にチェックを入れる。
「Type1」優先だと抜けと化けが発生する。
ちなみにTrueTypeをPSフォントに置き換えてPSに吐いたときのエンコードはMacRoman。
「Type1」優先設定の時はフォントはPSフォントになっているもののエンコードはWindows。
今後起こりうる事態として
http://blog.antenna.co.jp/PDFTool/archives/2007/05/29/#000702がある。
http://www2.convention.jp/pdf/dictionary/j/01_e/encoding/encoding.htmより引用。
エンコーディング [一般]
フォントで文字の割り当てを決める文字コードの種類のこと。符号化方式とも言う。PDFファイルでは「フォント情報」を見ると、その文書のエンコーディングを知ることができる。主なエンコーディング方法は下記の通り。
Identity-H PDF独自のCIDエンコードに準拠してコード付けされたもの。縦書きは「Identity-V」 日本語
90ms-RKSJ-H WindowsでのMicrosoftのエンコード。縦書きは「90ms-RKSJ-V」 日本語
90pv-RKSJ-H MacintoshのTrue Type(トゥルータイプ)フォント標準のエンコード。縦書きは「90pv-RKSJ-V」 日本語
83pv-RKSJ-H MacintoshのPostScriptフォント標準のエンコード。縦書きは「83pv-RKSJ-V」 日本語
Windows WindowsのDistillerとPDF Writer、MacintoshのDistillerで変換された、欧文フォントのエンコード。 欧文
MacRoman MacintoshのPDF Writerで変換された、欧文フォントのエンコード。 欧文
例えば「90ms-RKSJ-H」を細かく見ていくと、次のような構造になっている。
文字セット 90ms WindowsでのMicrosoftの文字セット
90pv Macintoshの漢字Talk7で採用された文字セット。True Type(トゥルータイプ)フォント標準
83pv Macintoshの漢字Talk6で採用された文字セット。PostScriptフォント標準
Add 富士通のパソコンでの文字セット
Ext NEC PC98用の文字セット
符号化方式 RKSJ Romaji Kana Shift JISの略。シフトJISの文字コード
特に表記のない場合は、JISを表す
EUC Extended Unix Codeの略。Unixで使われる
組方向 H Horizontalの略。拗促音や括弧などの記号類が、横書き用の文字であることを表す
V Verticalの略。拗促音や括弧などの記号類が、縦書き用の文字であることを表す
http://www.namikawa.co.jp/namikawaset.pdfより
欧文TrueTypeはPDFにした時にエンコードがカスタムになっていないとáやà等の文字が抜けたり、化けたりする。
QuarkからPSに書き出す時に「TrueType」を優先にチェックを入れる。
「Type1」優先だと抜けと化けが発生する。
ちなみにTrueTypeをPSフォントに置き換えてPSに吐いたときのエンコードはMacRoman。
「Type1」優先設定の時はフォントはPSフォントになっているもののエンコードはWindows。
今後起こりうる事態として
http://blog.antenna.co.jp/PDFTool/archives/2007/05/29/#000702がある。
2007年5月27日日曜日
プログラムの考え方 その2
引き続きhttp://blog.livedoor.jp/clausemitz/archives/50656193.htmlより引用
どうも、この問題、根が深いらしい。というのはプログラミングというのは
ある程度、「ひらめき」が要求されるもので、苦手な人はそもそも、その
ひらめきが生じないらしい。プログラミングは理数系という勘違いも拍車を
かけている気がする。聞くところによれば理数系の大学院まで行って
どう見ても私のような高卒ＤＱＮより、はるかに優秀な頭脳の持ち主が
簡単なプログラミングができなくて、頭をかかえている例もあるらしい。
ところで、あなたは理系ですか文系ですか、というつまらない質問があるが
私だったら「体育系」ですと答えるだろう。プログラミングしている時の
私の頭の中は動物的な勘がぐるぐる渦巻いているような感じで理路整然と
演繹的に問題を解いているのではなく、あっちこっち試行錯誤をしていて
言語として抜き出しにくい状態、いわゆる「暗黙知」が支配する感じだ。
このあたりの感触をわかっている、わかっていないが
プログラミングが得意か、不得意かの分かれ目のような気がするが、
他人の思考を覗き見できない（説明を求めても、うまく答えてくれた試しがない）
ので、今のところ、推測にすぎない。
で、FizzBuzz問題で、頭をかかえる人は、おそらく、ここでつまづいている
という「推測」はできるのだけど、他人の思考を覗き見できない
（なおかつ、できない人は、なぜできないかの説明すらできない）
ので、そのあたりをチクチク責めるよりも
私だったら、こう解いたという道筋を分解して説明しようと思う。
プログラミングの苦手な人は、この「分解」ができていません。
●1～100の数字を表示するプログラムを作る。
ダメな人の特徴として、いきなり「完成形」を作ろうとするのがある。
まず最初はできるところから、ラフスケッチから攻めるべきだ。
「3で割り切れるなら…」「5で割り切れるなら…」という仕様はまず無視。
1～100を間にカンマをつけて表示するから始めよう。ところがこの程度でも
いきなりつまづく人がいる。カンマのつけかたをどうするか。
int aIdx;
for(aIdx = 1; aIdx <= 100; aIdx++){
printf(", %d",aIdx);
}
printf("\n");
これだと「, 1, 2…」と表示するから、最初の1だけカンマをつけないなら
1だったらカンマをつけない、1以外はカンマをつけるという「条件分岐」を
ここで盛り込む。
int aIdx;
for(aIdx = 1; aIdx <= 100; aIdx++){
if(aIdx > 1)｛
printf(", ");
｝
printf("%d",aIdx);
}
printf("\n");
●3で割り切れるならFizzを出す
単純に考えれば、printf("%d",aIdx);を
if(aIdx % 3 == 0){
printf("Fizz");
}else{
printf("%d",aIdx);
}
に入れ替えだが、これが「ひっかけ」だと気づくか気づかないかで運命が決まる。
「5で割り切れるなら…」という仕様が控え、さらに「3と5で割り切れるなら…」
という仕様があるから単純に条件分岐するのはまずい。ではどうするか？
「状態」を保持しておき、分岐は剰余演算の直接結果ではなく、状態で行う。
「3で割り切れるか割り切れないか」の状態を示す変数、aFizzを導入する。
int aIdx,aFizz;
for(aIdx = 1; aIdx <= 100; aIdx++){
if(aIdx > 1){
printf(", ");
}
aFizz = (aIdx % 3 == 0);
if(aFizz == 0)｛
printf("%d",aIdx);
｝else｛
printf("Fizz");
｝
}
printf("\n");
●5で割り切れるならBuzzを出す
ここまで来れば、次のステップは
「5で割り切れるか割り切れないか」の状態を示す変数、aBuzzを導入する。
に気づくから（気づかないならプログラマーはやめたほうがいい、マジで）
int aIdx,aFizz,aBuzz;
for(aIdx = 1; aIdx <= 100; aIdx++){
if(aIdx > 1){
printf(", ");
}
aFizz = (aIdx % 3 == 0);
aBuzz = (aIdx % 5 == 0);
と、ここまでできれば数字を表示するのはFizzでもBuzzでもない状態だから
if(aFizz == 0 && aBuzz == 0)｛
printf("%d",aIdx);
とすりゃいいんだけど、ここで頭をかかえる人はFizz,Buzzの表示方法を
どうするかでしょうね。単純にaFizzでFizzを出す、aBuzzでBuzzを出すだと
両方が成立するケースでうまく表示できない（間のスペースをどう表示する）。
（switch(aFizz + aBuzz)で分岐すると短くなるけど、いかにもC言語だな…）
ここは変に技巧をこらさずにストレートに行きましょう。
}else{
if(aFizz != 0)｛
printf("Fizz");
｝
if(aBuzz != 0)｛
if(aFizz != 0)｛
printf(" ");
｝
printf("Buzz");
}
}
}
printf("\n");
と、まあこんな感じで解いているのですが、ここで説明していない理由で
コーディングを決めているものもあって、それもおそらくプログラミングが
苦手な人がつまづいている要因なのかもしれませんね…。
＊
FizzBuzz問題と関連するのかどうかわからないですが面白い記事を発見しました。
プログラマーになれる人なれない人
どういう理屈なのかはわからないけど、プログラミングを出来るようになれる人とマッタク出来ない人はハッキリと分かれてしまう。
俺がコンピュータサイエンス学科に居た頃と Teaching Assistant として一年生の面倒見てた経験から言うと、プログラミングが出来ない人はホントに最初の段階から出来ない。
例えば、
int a = 10;
というのを習うと 50 人中 4,5 人は脱落する。
変数という概念がどうしても腹の中におちていかないらしい。
にわかには信じがたいですが、変数なんて便利な概念を理解できずして
よく生きてこれたと感心します。（皮肉ではなく正直に感心してます）
ものすごく大雑把に言うと 4 割から 7 割の人はプログラマーに向いてない、ということになる。ポインタと再帰はかなりの難関だけど、 それ以前の段階でつまづいている人がかなりいるのでは、と俺は思う。ポインタと再帰までは騙し騙しでやれてるだけなんじゃないかなぁ？
ごめん。ポインターと再帰は私は簡単に理解してしまった。
ていうか、お勉強があまりできない高卒の私ですら理解できたことだから
世間一般のプログラマーは全員、簡単に理解したものとばかり思ってた。
だから指導者にはなれないんだろうな…。なるつもりはないけど。
どうも、この問題、根が深いらしい。というのはプログラミングというのは
ある程度、「ひらめき」が要求されるもので、苦手な人はそもそも、その
ひらめきが生じないらしい。プログラミングは理数系という勘違いも拍車を
かけている気がする。聞くところによれば理数系の大学院まで行って
どう見ても私のような高卒ＤＱＮより、はるかに優秀な頭脳の持ち主が
簡単なプログラミングができなくて、頭をかかえている例もあるらしい。
ところで、あなたは理系ですか文系ですか、というつまらない質問があるが
私だったら「体育系」ですと答えるだろう。プログラミングしている時の
私の頭の中は動物的な勘がぐるぐる渦巻いているような感じで理路整然と
演繹的に問題を解いているのではなく、あっちこっち試行錯誤をしていて
言語として抜き出しにくい状態、いわゆる「暗黙知」が支配する感じだ。
このあたりの感触をわかっている、わかっていないが
プログラミングが得意か、不得意かの分かれ目のような気がするが、
他人の思考を覗き見できない（説明を求めても、うまく答えてくれた試しがない）
ので、今のところ、推測にすぎない。
で、FizzBuzz問題で、頭をかかえる人は、おそらく、ここでつまづいている
という「推測」はできるのだけど、他人の思考を覗き見できない
（なおかつ、できない人は、なぜできないかの説明すらできない）
ので、そのあたりをチクチク責めるよりも
私だったら、こう解いたという道筋を分解して説明しようと思う。
プログラミングの苦手な人は、この「分解」ができていません。
●1～100の数字を表示するプログラムを作る。
ダメな人の特徴として、いきなり「完成形」を作ろうとするのがある。
まず最初はできるところから、ラフスケッチから攻めるべきだ。
「3で割り切れるなら…」「5で割り切れるなら…」という仕様はまず無視。
1～100を間にカンマをつけて表示するから始めよう。ところがこの程度でも
いきなりつまづく人がいる。カンマのつけかたをどうするか。
int aIdx;
for(aIdx = 1; aIdx <= 100; aIdx++){
printf(", %d",aIdx);
}
printf("\n");
これだと「, 1, 2…」と表示するから、最初の1だけカンマをつけないなら
1だったらカンマをつけない、1以外はカンマをつけるという「条件分岐」を
ここで盛り込む。
int aIdx;
for(aIdx = 1; aIdx <= 100; aIdx++){
if(aIdx > 1)｛
printf(", ");
｝
printf("%d",aIdx);
}
printf("\n");
●3で割り切れるならFizzを出す
単純に考えれば、printf("%d",aIdx);を
if(aIdx % 3 == 0){
printf("Fizz");
}else{
printf("%d",aIdx);
}
に入れ替えだが、これが「ひっかけ」だと気づくか気づかないかで運命が決まる。
「5で割り切れるなら…」という仕様が控え、さらに「3と5で割り切れるなら…」
という仕様があるから単純に条件分岐するのはまずい。ではどうするか？
「状態」を保持しておき、分岐は剰余演算の直接結果ではなく、状態で行う。
「3で割り切れるか割り切れないか」の状態を示す変数、aFizzを導入する。
int aIdx,aFizz;
for(aIdx = 1; aIdx <= 100; aIdx++){
if(aIdx > 1){
printf(", ");
}
aFizz = (aIdx % 3 == 0);
if(aFizz == 0)｛
printf("%d",aIdx);
｝else｛
printf("Fizz");
｝
}
printf("\n");
●5で割り切れるならBuzzを出す
ここまで来れば、次のステップは
「5で割り切れるか割り切れないか」の状態を示す変数、aBuzzを導入する。
に気づくから（気づかないならプログラマーはやめたほうがいい、マジで）
int aIdx,aFizz,aBuzz;
for(aIdx = 1; aIdx <= 100; aIdx++){
if(aIdx > 1){
printf(", ");
}
aFizz = (aIdx % 3 == 0);
aBuzz = (aIdx % 5 == 0);
と、ここまでできれば数字を表示するのはFizzでもBuzzでもない状態だから
if(aFizz == 0 && aBuzz == 0)｛
printf("%d",aIdx);
とすりゃいいんだけど、ここで頭をかかえる人はFizz,Buzzの表示方法を
どうするかでしょうね。単純にaFizzでFizzを出す、aBuzzでBuzzを出すだと
両方が成立するケースでうまく表示できない（間のスペースをどう表示する）。
（switch(aFizz + aBuzz)で分岐すると短くなるけど、いかにもC言語だな…）
ここは変に技巧をこらさずにストレートに行きましょう。
}else{
if(aFizz != 0)｛
printf("Fizz");
｝
if(aBuzz != 0)｛
if(aFizz != 0)｛
printf(" ");
｝
printf("Buzz");
}
}
}
printf("\n");
と、まあこんな感じで解いているのですが、ここで説明していない理由で
コーディングを決めているものもあって、それもおそらくプログラミングが
苦手な人がつまづいている要因なのかもしれませんね…。
＊
FizzBuzz問題と関連するのかどうかわからないですが面白い記事を発見しました。
プログラマーになれる人なれない人
どういう理屈なのかはわからないけど、プログラミングを出来るようになれる人とマッタク出来ない人はハッキリと分かれてしまう。
俺がコンピュータサイエンス学科に居た頃と Teaching Assistant として一年生の面倒見てた経験から言うと、プログラミングが出来ない人はホントに最初の段階から出来ない。
例えば、
int a = 10;
というのを習うと 50 人中 4,5 人は脱落する。
変数という概念がどうしても腹の中におちていかないらしい。
にわかには信じがたいですが、変数なんて便利な概念を理解できずして
よく生きてこれたと感心します。（皮肉ではなく正直に感心してます）
ものすごく大雑把に言うと 4 割から 7 割の人はプログラマーに向いてない、ということになる。ポインタと再帰はかなりの難関だけど、 それ以前の段階でつまづいている人がかなりいるのでは、と俺は思う。ポインタと再帰までは騙し騙しでやれてるだけなんじゃないかなぁ？
ごめん。ポインターと再帰は私は簡単に理解してしまった。
ていうか、お勉強があまりできない高卒の私ですら理解できたことだから
世間一般のプログラマーは全員、簡単に理解したものとばかり思ってた。
だから指導者にはなれないんだろうな…。なるつもりはないけど。
プログラムの考え方 その1
http://blog.livedoor.jp/clausemitz/archives/50656033.htmlより引用
FizzBuzz問題
というのが流行っているらしい。
Wikipedia - Fizz Buzz
最初のプレイヤーは「１」と数字を発言する。次のプレイヤーは直前のプレイヤーの次の数字を発言していく。ただし、３で割り切れる場合は 「Fizz」、５で割り切れる場合は 「Buzz」、両者で割り切れる場合は 「Fizz Buzz」を数の代わりに発言しなければならない。
ゲームは、以下のとおりに発言が進行する。
1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, Fizz Buzz, 16, 17, Fizz, 19, Buzz, Fizz, 22, 23, Fizz, Buzz, 26, Fizz, 28, 29, Fizz Buzz, 31, 32, Fizz, 34, Buzz, Fizz, ...
このゲームをコンピュータ画面に表示させるプログラムとして作成させることで、コードがかけないプログラマ志願者を見分ける手法を Jeff Atwood 氏が FizzBuzz問題 (FizzBuzz Question)として提唱した。
どうしてプログラマに・・・プログラムが書けないのか?
ちゃんとしたプログラマであれば、これを実行するプログラムを2分とかからずに紙に書き出せるはずだ。怖い事実を聞きたい? コンピュータサイエンス学科卒業生の過半数にはそれができないのだ。 自称上級プログラマが答えを書くのに10-15分もかかっているのを見たこともある。
えええっ！！！ なんでー？？？ ＼(◎o◎;)／
こんなの剰余演算とループの組み合わせで簡単にできるじゃん。
2分は大げさとしても10分もかかるかあ？！ (´ﾟдﾟ`)
ちなみに、この問題を解くのに「剰余演算は一切使うな」という縛りをつけると
とたんに多くのプログラマーが頭をかかえるらしいけど、嘘だろー？？
そんときゃ配列使えばいいじゃん。ちなみに私の解答(C言語)は以下の通り。
#include
#include
#define MAX_FIZZ_BUZZ 100
#define FIZZ 3
#define BUZZ 5
int main(int argc,const char *argv[])
{
static int aFizzBuzz[MAX_FIZZ_BUZZ + 1];
int aIdx;
for(aIdx = FIZZ; aIdx <= MAX_FIZZ_BUZZ; aIdx += FIZZ){
aFizzBuzz[aIdx] += 1;
}
for(aIdx = BUZZ; aIdx <= MAX_FIZZ_BUZZ; aIdx += BUZZ){
aFizzBuzz[aIdx] += 2;
}
for(aIdx = 1; aIdx <= MAX_FIZZ_BUZZ; aIdx++){
if(aIdx > 1){
printf(", ");
}
switch(aFizzBuzz[aIdx]){
case 0:
printf("%d",aIdx);
break;
case 1:
printf("Fizz");
break;
case 2:
printf("Buzz");
break;
case 3:
printf("Fizz Buzz");
break;
default:
abort();
break;
}
}
printf("\n");
return 0;
}
言っとくが私は高卒のDQNだし、別に天才プログラマーでもなんでもない。
とすると、このFizzBuzz問題って、実は根の深い深刻な問題かもしれない…。
FizzBuzz問題
というのが流行っているらしい。
Wikipedia - Fizz Buzz
最初のプレイヤーは「１」と数字を発言する。次のプレイヤーは直前のプレイヤーの次の数字を発言していく。ただし、３で割り切れる場合は 「Fizz」、５で割り切れる場合は 「Buzz」、両者で割り切れる場合は 「Fizz Buzz」を数の代わりに発言しなければならない。
ゲームは、以下のとおりに発言が進行する。
1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, Fizz Buzz, 16, 17, Fizz, 19, Buzz, Fizz, 22, 23, Fizz, Buzz, 26, Fizz, 28, 29, Fizz Buzz, 31, 32, Fizz, 34, Buzz, Fizz, ...
このゲームをコンピュータ画面に表示させるプログラムとして作成させることで、コードがかけないプログラマ志願者を見分ける手法を Jeff Atwood 氏が FizzBuzz問題 (FizzBuzz Question)として提唱した。
どうしてプログラマに・・・プログラムが書けないのか?
ちゃんとしたプログラマであれば、これを実行するプログラムを2分とかからずに紙に書き出せるはずだ。怖い事実を聞きたい? コンピュータサイエンス学科卒業生の過半数にはそれができないのだ。 自称上級プログラマが答えを書くのに10-15分もかかっているのを見たこともある。
えええっ！！！ なんでー？？？ ＼(◎o◎;)／
こんなの剰余演算とループの組み合わせで簡単にできるじゃん。
2分は大げさとしても10分もかかるかあ？！ (´ﾟдﾟ`)
ちなみに、この問題を解くのに「剰余演算は一切使うな」という縛りをつけると
とたんに多くのプログラマーが頭をかかえるらしいけど、嘘だろー？？
そんときゃ配列使えばいいじゃん。ちなみに私の解答(C言語)は以下の通り。
#include
#include
#define MAX_FIZZ_BUZZ 100
#define FIZZ 3
#define BUZZ 5
int main(int argc,const char *argv[])
{
static int aFizzBuzz[MAX_FIZZ_BUZZ + 1];
int aIdx;
for(aIdx = FIZZ; aIdx <= MAX_FIZZ_BUZZ; aIdx += FIZZ){
aFizzBuzz[aIdx] += 1;
}
for(aIdx = BUZZ; aIdx <= MAX_FIZZ_BUZZ; aIdx += BUZZ){
aFizzBuzz[aIdx] += 2;
}
for(aIdx = 1; aIdx <= MAX_FIZZ_BUZZ; aIdx++){
if(aIdx > 1){
printf(", ");
}
switch(aFizzBuzz[aIdx]){
case 0:
printf("%d",aIdx);
break;
case 1:
printf("Fizz");
break;
case 2:
printf("Buzz");
break;
case 3:
printf("Fizz Buzz");
break;
default:
abort();
break;
}
}
printf("\n");
return 0;
}
言っとくが私は高卒のDQNだし、別に天才プログラマーでもなんでもない。
とすると、このFizzBuzz問題って、実は根の深い深刻な問題かもしれない…。
2007年5月24日木曜日
いまさらながらOSの解像度
http://www.theninjacat.com/WEBCLASS/TOPICS/20021011.html
より
（中略）
ではここでOSの解像度の中身に戻りますと、さきほど「Macは１インチ分を72粒(dpi)、Windowsは96粒(dpi)使って表している」という取り決めのことだ、と説明しました。
じゃなんでたったこれだけのことが問題なんだ、ということですが、問題はあるんです。何を隠そう、（隠したってはじまらないけど）OSごとにその粒数が違うんですな、これが。気のきいた方ならもう察しがつくでしょうけど、1インチ分の長さが違って見えるんですよ！
具体的にいうと、Macは１インチ分を72粒(dpi)、Windowsは96粒(dpi)使って表します。WindowsはMacの約1.3倍の長さになるんです。
でも、画像に関してはピクセル=粒数で大きさを決めていますから、どっちのOSでも100粒なら100粒、大きさに変わりありません。「1インチ分」なんて気にすることはめったにないでしょ。だからまず画像に関してはよし。じゃ何に気を使う必要があるか！
文字、文字ですよ。文字って「ポイント」っていう単位使ったりするでしょ？あれが問題です。
「ポイント」という単位はもともと印刷物に使う文字の大きさの単位で、1インチの72分の1が1ポイントと決められています。そしてMacは生まれた当初からDTPを視野に入れていましたから、印刷物と単位を同じにしました。だから1インチを72粒、1粒1ポイントとなるように設計されています。でもWindowsは同じ1ポイントを表示するのに約1.3粒使うんですよ！
でもって問題なのは、htmlで設定するfont size="3"とかいう設定は、このポイントを基準としているってことです。基本的にfont size="3"が12ポイントだったかと思いますが。
だから文字の大きさを「ポイント」で設定してしまうと、Mac上で10文字横に並ぶ幅に、Windowsは7文字しか入らないで、３文字は改行されてしまう。これはテキストがいっぱいある画面をかっこよくレイアウトしたい人には大問題ですね。ちゃんとゆとりを考えておかないと、どこかの画面でとんでもない箇所で改行されてたりってことがおきる。DTP出身の人なんかだと気絶しちゃうような事件ですわね。
じゃどうしたらいいんだってことですが、オーソドックスな方法として、「スタイルシート」を使うというのが一般的です。スタイルシートでは、フォントサイズをpx（ピクセル）で設定することができます。こうすれば、基本的にはMacだろうとWindowsだろうと、12pxといえば12pxで見えるから。（「基本的には」と言ったのは、これも必ずしも完璧ではないからです。使っているフォントによっては、改行場所が違ってしまうこともなくはない。まあでも率は低いのでこの際この問題は追求しないことにしましょう。）こういう点ではスタイルシートはありがたいですね。スタイルシートが存在しなかったころは、対処方法は「画像にして貼る」だったんですよ。それもまたビックリでしょ。
より
（中略）
ではここでOSの解像度の中身に戻りますと、さきほど「Macは１インチ分を72粒(dpi)、Windowsは96粒(dpi)使って表している」という取り決めのことだ、と説明しました。
じゃなんでたったこれだけのことが問題なんだ、ということですが、問題はあるんです。何を隠そう、（隠したってはじまらないけど）OSごとにその粒数が違うんですな、これが。気のきいた方ならもう察しがつくでしょうけど、1インチ分の長さが違って見えるんですよ！
具体的にいうと、Macは１インチ分を72粒(dpi)、Windowsは96粒(dpi)使って表します。WindowsはMacの約1.3倍の長さになるんです。
でも、画像に関してはピクセル=粒数で大きさを決めていますから、どっちのOSでも100粒なら100粒、大きさに変わりありません。「1インチ分」なんて気にすることはめったにないでしょ。だからまず画像に関してはよし。じゃ何に気を使う必要があるか！
文字、文字ですよ。文字って「ポイント」っていう単位使ったりするでしょ？あれが問題です。
「ポイント」という単位はもともと印刷物に使う文字の大きさの単位で、1インチの72分の1が1ポイントと決められています。そしてMacは生まれた当初からDTPを視野に入れていましたから、印刷物と単位を同じにしました。だから1インチを72粒、1粒1ポイントとなるように設計されています。でもWindowsは同じ1ポイントを表示するのに約1.3粒使うんですよ！
でもって問題なのは、htmlで設定するfont size="3"とかいう設定は、このポイントを基準としているってことです。基本的にfont size="3"が12ポイントだったかと思いますが。
だから文字の大きさを「ポイント」で設定してしまうと、Mac上で10文字横に並ぶ幅に、Windowsは7文字しか入らないで、３文字は改行されてしまう。これはテキストがいっぱいある画面をかっこよくレイアウトしたい人には大問題ですね。ちゃんとゆとりを考えておかないと、どこかの画面でとんでもない箇所で改行されてたりってことがおきる。DTP出身の人なんかだと気絶しちゃうような事件ですわね。
じゃどうしたらいいんだってことですが、オーソドックスな方法として、「スタイルシート」を使うというのが一般的です。スタイルシートでは、フォントサイズをpx（ピクセル）で設定することができます。こうすれば、基本的にはMacだろうとWindowsだろうと、12pxといえば12pxで見えるから。（「基本的には」と言ったのは、これも必ずしも完璧ではないからです。使っているフォントによっては、改行場所が違ってしまうこともなくはない。まあでも率は低いのでこの際この問題は追求しないことにしましょう。）こういう点ではスタイルシートはありがたいですね。スタイルシートが存在しなかったころは、対処方法は「画像にして貼る」だったんですよ。それもまたビックリでしょ。
2007年5月21日月曜日
OS-Xのメモリ管理
http://soap.s216.xrea.com/umu/mt/archives/001117.html
http://soap.s216.xrea.com/umu/mt/archives/001141.htmlより引用
私はスワップファイル増殖撲滅協会自称会員なので、 スワップファイルをなくそうという記事を以前書いた。
簡単に言うと、以下の作業を行うことで、解放されていないメモリが大幅に解放されるため、スワップファイルにページアウトせずに踏ん張れるようになって、少し幸せになれるというものだ。特にメモリ喰らいのFirefoxを使っている人には効果大でしょう。 (Firefoxのメモリリーク抑制についてはこちらも参照されたい
→Firefoxのメモリ食いを小食にする (うむらうす))。
Finderの再起動
Dockの再起動
Weekly Maintainance Script実行
このそれぞれの作業の実行方法も書いたが（MainMenuを使うと便利）、三手必要なのもめんどくさいなと思っていた。そこで、これらをAppleScript一本にまとめ、一手で済むようにした。
内容は前回スワップファイルをなくそうに書いたことそのままだ。私はこれをスクリプトメニューに登録していて、 MenuMeterで残りメモリを監視しておき、残りが少なくなったら実行、という風にしているのだが、もう便利でたまらない。
→ファイルをダウンロード(Release Memory.scpt)
注）Safariでダウンロードした場合は拡張子が変わる。その場合の対応はmutaさんの記事を参照されたい（他人任せですみません）。
スクリプトメニューへの登録の仕方はここに詳しく書いたので参照のこと。
→NBA TVのvideoを手軽に楽しむ (うむらうす)
さて、このAppleScriptを実行すると、FinderとDockの再起動は勝手に進むが、 Weekly Maintenance Scriptの実行には管理者権限がいるため、パスワードが要求される。ファイルの内容は下に書いてあるので、「なんでパスワードがいるの？」と心配になる人は、読んでから実行すると良いだろう。
ということで、以下ソースと説明。(3/18 終了メッセージ追加)
(*
「KOTOERA | AppleScript | Finderの再起動」より
http://www.geocities.jp/aqua7bowler/applescript/relaunch_finder.html
*)
-- Finder再起動
tell application "Finder"
quit
delay 1
activateFinder() of me
if exists Finder window 1 then
activate
set windowBounds to (bounds of Finder window 1)
set theFolder to target of Finder window 1
close Finder window 1
open theFolder
set bounds of Finder window 1 to windowBounds
end if
end tell
on activateFinder()
try
tell application "Finder" to activate
on error
activateFinder() of me
end try
end activateFinder
-- Finder再起動ここまで
-- Dock再起動
do shell script "killall Dock"
-- Dock再起動ここまで
-- Weekly Maintenance Scriptを管理者権限で実行
-- http://www.thexlab.com/faqs/maintscripts.html
-- http://developer.apple.com/jp/technotes/tn2065.html
do shell script "periodic weekly" with administrator privileges
-- Weekly Maintenance Scriptを管理者権限で実行ここまで
display dialog "Release Memory 終了しました！" buttons {"OK"}
書いてあるように、Finderの再起動はKOTOERAさん の 「AppleScript | Finderの再起動」を、 Weekly Maintenance Scriptの管理者権限での実行は Running Mac OS X Maintenance Scriptsと do shell script in AppleScript を参考にさせてもらった。というかそのまんま。ありがとうございます。
--------------------------------------------------------------------------------
まとめ
スワップファイル増殖を防ぐため、解放されていないメモリを解放する作業をAppleScript一発でできるようにしたら、すごく満足
エラーの処理とか全く考えてないので、誰かえらい人が改良してくれるとうれしい
3／15追記）
本AppleScriptをmutaさんに紹介して頂いた。こちらの適当記事よりもよっぽど丁寧に解説して頂いた。私はSafari使っていないので、拡張子が変わるとか全く考慮してなかったので、補足して頂いて、とても感謝。実は私はメモリを2G積んでいるので強烈に解放感を感じるのだが、環境によってはそんなに効かなかい・・・？
私の経験上、Swapfileが4つとかになると、絶望的に全ての動作が遅くなるのだが、それを私の環境で防げていることは間違いない。
追記終わり）
http://soap.s216.xrea.com/umu/mt/archives/001141.htmlより引用
私はスワップファイル増殖撲滅協会自称会員なので、 スワップファイルをなくそうという記事を以前書いた。
簡単に言うと、以下の作業を行うことで、解放されていないメモリが大幅に解放されるため、スワップファイルにページアウトせずに踏ん張れるようになって、少し幸せになれるというものだ。特にメモリ喰らいのFirefoxを使っている人には効果大でしょう。 (Firefoxのメモリリーク抑制についてはこちらも参照されたい
→Firefoxのメモリ食いを小食にする (うむらうす))。
Finderの再起動
Dockの再起動
Weekly Maintainance Script実行
このそれぞれの作業の実行方法も書いたが（MainMenuを使うと便利）、三手必要なのもめんどくさいなと思っていた。そこで、これらをAppleScript一本にまとめ、一手で済むようにした。
内容は前回スワップファイルをなくそうに書いたことそのままだ。私はこれをスクリプトメニューに登録していて、 MenuMeterで残りメモリを監視しておき、残りが少なくなったら実行、という風にしているのだが、もう便利でたまらない。
→ファイルをダウンロード(Release Memory.scpt)
注）Safariでダウンロードした場合は拡張子が変わる。その場合の対応はmutaさんの記事を参照されたい（他人任せですみません）。
スクリプトメニューへの登録の仕方はここに詳しく書いたので参照のこと。
→NBA TVのvideoを手軽に楽しむ (うむらうす)
さて、このAppleScriptを実行すると、FinderとDockの再起動は勝手に進むが、 Weekly Maintenance Scriptの実行には管理者権限がいるため、パスワードが要求される。ファイルの内容は下に書いてあるので、「なんでパスワードがいるの？」と心配になる人は、読んでから実行すると良いだろう。
ということで、以下ソースと説明。(3/18 終了メッセージ追加)
(*
「KOTOERA | AppleScript | Finderの再起動」より
http://www.geocities.jp/aqua7bowler/applescript/relaunch_finder.html
*)
-- Finder再起動
tell application "Finder"
quit
delay 1
activateFinder() of me
if exists Finder window 1 then
activate
set windowBounds to (bounds of Finder window 1)
set theFolder to target of Finder window 1
close Finder window 1
open theFolder
set bounds of Finder window 1 to windowBounds
end if
end tell
on activateFinder()
try
tell application "Finder" to activate
on error
activateFinder() of me
end try
end activateFinder
-- Finder再起動ここまで
-- Dock再起動
do shell script "killall Dock"
-- Dock再起動ここまで
-- Weekly Maintenance Scriptを管理者権限で実行
-- http://www.thexlab.com/faqs/maintscripts.html
-- http://developer.apple.com/jp/technotes/tn2065.html
do shell script "periodic weekly" with administrator privileges
-- Weekly Maintenance Scriptを管理者権限で実行ここまで
display dialog "Release Memory 終了しました！" buttons {"OK"}
書いてあるように、Finderの再起動はKOTOERAさん の 「AppleScript | Finderの再起動」を、 Weekly Maintenance Scriptの管理者権限での実行は Running Mac OS X Maintenance Scriptsと do shell script in AppleScript を参考にさせてもらった。というかそのまんま。ありがとうございます。
--------------------------------------------------------------------------------
まとめ
スワップファイル増殖を防ぐため、解放されていないメモリを解放する作業をAppleScript一発でできるようにしたら、すごく満足
エラーの処理とか全く考えてないので、誰かえらい人が改良してくれるとうれしい
3／15追記）
本AppleScriptをmutaさんに紹介して頂いた。こちらの適当記事よりもよっぽど丁寧に解説して頂いた。私はSafari使っていないので、拡張子が変わるとか全く考慮してなかったので、補足して頂いて、とても感謝。実は私はメモリを2G積んでいるので強烈に解放感を感じるのだが、環境によってはそんなに効かなかい・・・？
私の経験上、Swapfileが4つとかになると、絶望的に全ての動作が遅くなるのだが、それを私の環境で防げていることは間違いない。
追記終わり）
PHP再考
http://blog.livedoor.jp/dankogai/archives/50835571.htmlより引用
そろそろPHPに関して一言いっとくか
こんな記事まで出ていることだし。
[ThinkIT] 第1回：今だからこその「PHPのすすめ」 (1/3)
プログラムをたしなまない方にご注意:
こちらのPHPとはちょっと違います:-p
finalventの日記 - そろそろPHPに関してもう一言いっとくか
各論
使うは天国、インストールは地獄
PHPが一旦インストールされたら、それを使うのは確かに簡単だ。普通にHTMLを書く感覚で
とか書けばいい。しかし、PHPでいろいろやるためには、実際にはさまざまなライブラリーをあらかじめインストールした上で、PHPをそれに合わせてconfigureしなおさなければならない。こうして作られたlibphp#.soは、どれも微妙に、しかしユーザーにとっては耐え難く異なる。
% sh configure --help
の出力が390行(5.2.2現在)というところからして、もうシステム管理者の頭痛の種。なんでもかんでもぶちこめば、やたら重いApacheが出来上がるし、かといっていろいろ削ればあとでユーザーに「なんでXMLが扱えないの?」とか突っ込まれることになる。
Webアプリ以外作る気にならない
PHPは、その生まれからしてWeb Serverと密結合している。Webアプリを作るにはいいが、それ以外の目的には使えない。
「でもCLIがあるじゃん」と言った方。なんでただのshell script書くのにで囲まなきゃならないのか。CLIを使う人にそんな勤勉さを期待されても困るというもの。
反吐がでるほど多い呪文
PHPを使うということは、PHPが用意するコマンドを覚えるということに等しいのだけど、これがやたらと沢山ある。なんでrequireとrequire_onceが分かれているのか、他の言語を知っている人にはさっぱりわからない。
そこには、短い言葉を組み合わせて大きな文章を作るという思想があまりに欠落している。ただ呪文の羅列があるのみ。AnimaliaChordataMammaliaPrimataHomonidaeHomoSapiensでなくHomo::Sapiensと書きたいのだけど。
バージョンが変われば別言語
Mac OS Xには、PerlもRubyもPythonもOSリリース時点での安定版が載っているのに、PHPは4のまま。これはデフォルトでインストールされているのがApache 1.3.xということもあるのだろうけれども、これはAppleがPHPを言語としてではなくWebサーバーのコンポーネントとして見ていることを意味している。
そう。PHPはバージョンの違いがあまりに大きいのだ。PHP4とPHP5の違いに至っては、Perl 5とPerl 6以上に見える。
言語で言語を拡張できない
なぜPHPが（他の言語から見ると)異様に激しくバージョンアップという名の別バージョンリリースを続けているかといえば、PHPには言語をもって言語を拡張するというのが思想からして欠落しているからだという結論に達する。PHPで新しいことをしようとしたら、PHPごと新しくせざるを得ないのだ。PerlもPythonもRubyも、言語はそのままで最新の技術に苦もなく対応していることと好対照である。
MVCのVしか出来ない
PHPというのは、Model, View, ControllerのViewのみしか扱えないことを宿命づけられた言語である。実際PHPのみで動いているWebサービスというのはほとんどなく、実際にはMySQLをはじめ、PHPのためのバックエンドプログラムが山のようにあり、PHPはそれを呼び出しているに過ぎない。
なぜPHPヘビーユーザーのDHHがPHP on RailsではなくRuby on Railsを作ったかといえば、それに尽きると思う。
総論
PHPを一言で言うと、「使えても作れない」言語だということになる。PHPのためにお膳立てした環境を使う事はできても、その環境をお膳立てしてあげるにはPHP以上のものが必ず必要になってくる。
そのことは別に悪くない。というより、他の言語がViewをあまりにおろそかにしてきたというのは事実だろう。HTML書きたちを、プログラマーたちが「下に見ていた」ということは否定できない。そのHTML書きたちの、「私たちにも少しはプログラムさせてよ」という声に他の言語屋たちが耳を充分傾けてこなかったことこそ、猛省すべき課題だろう。
しかし、PHPではプログラマーがプログラムを続けるための一番のご褒美がほとんどない。それは何かというと「新しい技を覚える」という喜びである。「新しい呪文」ではない。それならいくらでもある。しかし新しい呪文を覚えた所で、心理報酬は大したことがない。単に知識が増えただけだ。PHPを使っても、知識は増えても知恵が増える気がちっともしないのである。
それでも、
Matzにっき(2007-05-10)
「PHPは言語としてはダメだが、どこにでもあるし、知見も蓄積されていることがキラーだ」 という話。納得できる。
という意見はある。しかし、その知見もよくみれば単なる知識の断片の寄せ集めばかりで、それらを覚えても脳の空き容量が減る気しかしないのはなぜだろう。
ましてや、今やWebページ生成言語は、PHPだけではないのだ。Webページにコードを埋め込むというのは、大抵のLLには出来るし(HaskellすらHaskell Server Pageというのがある)、それゆえPHPの手軽さも今や他の言語を知っている人がわざわざPHPに乗り換えるほどの魅力にあまりに乏しい。
ましてや、最近はAjaxの台頭で、かつてはサーバー側にやらせていたViewを、ブラウザー側にやらせる機会が増えてきた。PHPが「どこにでもある」かどうかは疑念の余地があるが、JavaScriptがどこにもあるのは疑念の余地がない。そして幸いなことに、JavaScriptは「新しい技を覚える」という喜びを味わえる言語でもある。そのことに皆が気づくのにだいぶ時間はかかったが、今ではみんな知っている。車輪の再発明があまりに多いのは頭痛の種だが、それでも車輪を再発明できるというのは、プログラマーの成長にとっては欠かせない特徴なのだ。
PHPにおいては、PHP「環境」に用意された車輪を使い続けるしかない。
だから、PHPに対して正しいスタンスは、「使うにとどめる」というものだと思う。「作る」までやりたかったら、他をあたるべきだろう。
そろそろPHPに関して一言いっとくか
こんな記事まで出ていることだし。
[ThinkIT] 第1回：今だからこその「PHPのすすめ」 (1/3)
プログラムをたしなまない方にご注意:
こちらのPHPとはちょっと違います:-p
finalventの日記 - そろそろPHPに関してもう一言いっとくか
各論
使うは天国、インストールは地獄
PHPが一旦インストールされたら、それを使うのは確かに簡単だ。普通にHTMLを書く感覚で
以下の環境変数が設定されています:
とか書けばいい。しかし、PHPでいろいろやるためには、実際にはさまざまなライブラリーをあらかじめインストールした上で、PHPをそれに合わせてconfigureしなおさなければならない。こうして作られたlibphp#.soは、どれも微妙に、しかしユーザーにとっては耐え難く異なる。
% sh configure --help
の出力が390行(5.2.2現在)というところからして、もうシステム管理者の頭痛の種。なんでもかんでもぶちこめば、やたら重いApacheが出来上がるし、かといっていろいろ削ればあとでユーザーに「なんでXMLが扱えないの?」とか突っ込まれることになる。
Webアプリ以外作る気にならない
PHPは、その生まれからしてWeb Serverと密結合している。Webアプリを作るにはいいが、それ以外の目的には使えない。
「でもCLIがあるじゃん」と言った方。なんでただのshell script書くのに
反吐がでるほど多い呪文
PHPを使うということは、PHPが用意するコマンドを覚えるということに等しいのだけど、これがやたらと沢山ある。なんでrequireとrequire_onceが分かれているのか、他の言語を知っている人にはさっぱりわからない。
そこには、短い言葉を組み合わせて大きな文章を作るという思想があまりに欠落している。ただ呪文の羅列があるのみ。AnimaliaChordataMammaliaPrimataHomonidaeHomoSapiensでなくHomo::Sapiensと書きたいのだけど。
バージョンが変われば別言語
Mac OS Xには、PerlもRubyもPythonもOSリリース時点での安定版が載っているのに、PHPは4のまま。これはデフォルトでインストールされているのがApache 1.3.xということもあるのだろうけれども、これはAppleがPHPを言語としてではなくWebサーバーのコンポーネントとして見ていることを意味している。
そう。PHPはバージョンの違いがあまりに大きいのだ。PHP4とPHP5の違いに至っては、Perl 5とPerl 6以上に見える。
言語で言語を拡張できない
なぜPHPが（他の言語から見ると)異様に激しくバージョンアップという名の別バージョンリリースを続けているかといえば、PHPには言語をもって言語を拡張するというのが思想からして欠落しているからだという結論に達する。PHPで新しいことをしようとしたら、PHPごと新しくせざるを得ないのだ。PerlもPythonもRubyも、言語はそのままで最新の技術に苦もなく対応していることと好対照である。
MVCのVしか出来ない
PHPというのは、Model, View, ControllerのViewのみしか扱えないことを宿命づけられた言語である。実際PHPのみで動いているWebサービスというのはほとんどなく、実際にはMySQLをはじめ、PHPのためのバックエンドプログラムが山のようにあり、PHPはそれを呼び出しているに過ぎない。
なぜPHPヘビーユーザーのDHHがPHP on RailsではなくRuby on Railsを作ったかといえば、それに尽きると思う。
総論
PHPを一言で言うと、「使えても作れない」言語だということになる。PHPのためにお膳立てした環境を使う事はできても、その環境をお膳立てしてあげるにはPHP以上のものが必ず必要になってくる。
そのことは別に悪くない。というより、他の言語がViewをあまりにおろそかにしてきたというのは事実だろう。HTML書きたちを、プログラマーたちが「下に見ていた」ということは否定できない。そのHTML書きたちの、「私たちにも少しはプログラムさせてよ」という声に他の言語屋たちが耳を充分傾けてこなかったことこそ、猛省すべき課題だろう。
しかし、PHPではプログラマーがプログラムを続けるための一番のご褒美がほとんどない。それは何かというと「新しい技を覚える」という喜びである。「新しい呪文」ではない。それならいくらでもある。しかし新しい呪文を覚えた所で、心理報酬は大したことがない。単に知識が増えただけだ。PHPを使っても、知識は増えても知恵が増える気がちっともしないのである。
それでも、
Matzにっき(2007-05-10)
「PHPは言語としてはダメだが、どこにでもあるし、知見も蓄積されていることがキラーだ」 という話。納得できる。
という意見はある。しかし、その知見もよくみれば単なる知識の断片の寄せ集めばかりで、それらを覚えても脳の空き容量が減る気しかしないのはなぜだろう。
ましてや、今やWebページ生成言語は、PHPだけではないのだ。Webページにコードを埋め込むというのは、大抵のLLには出来るし(HaskellすらHaskell Server Pageというのがある)、それゆえPHPの手軽さも今や他の言語を知っている人がわざわざPHPに乗り換えるほどの魅力にあまりに乏しい。
ましてや、最近はAjaxの台頭で、かつてはサーバー側にやらせていたViewを、ブラウザー側にやらせる機会が増えてきた。PHPが「どこにでもある」かどうかは疑念の余地があるが、JavaScriptがどこにもあるのは疑念の余地がない。そして幸いなことに、JavaScriptは「新しい技を覚える」という喜びを味わえる言語でもある。そのことに皆が気づくのにだいぶ時間はかかったが、今ではみんな知っている。車輪の再発明があまりに多いのは頭痛の種だが、それでも車輪を再発明できるというのは、プログラマーの成長にとっては欠かせない特徴なのだ。
PHPにおいては、PHP「環境」に用意された車輪を使い続けるしかない。
だから、PHPに対して正しいスタンスは、「使うにとどめる」というものだと思う。「作る」までやりたかったら、他をあたるべきだろう。
2007年5月18日金曜日
おまけのPerl Script 2点
その1 文字コードを表示するスクリプト。
MacOS9では「この文字のShift-JISコードなんだっけ？」と思ったときに使える。
print"文字入力>>";
$str = くSTDIN>;
# 引数を $str に格納
（このblogでは<←はhtml言語として認識してしまうので「く」で代用
chop($str);
# 改行を取り除く
@arr=split//,$str;
# $strをバイトで分解して@arrに格納
foreach $byte(@arr){
#@arrの各バイトを$byteに格納しながらループ
@buf = unpack("CC", $byte);
#10進数に変換して@bufに格納
printf "%x%x",@buf
# Shift-JISコード(16進数)で出力
}
#ループを終了
# 8進数にする場合はprintf "%o%o",@buf となる
# 00で始まる文字は00が省略されてしまうため、うまくいかない。今後の課題。
その2 LFキャラcheck
お馬鹿なデザは客から支給されたwordテキストをまんまコピペでイラレに流し込む。当然、行頭にはLFキャラが入ってくる。イラレからまんまカラーゲラを出力する分には気づかないが、EPSにしてQuarkに貼ると文字組みが狂って出力される。その症状が反映されるPSプリンタと反映されないPSプリンタがあるからやっかいである。いちいちファイルを開いて検索・置換するのはメンドイんで、Perlスクリプトにドラッグしてチェック。
#!/user/local/bin/perl
while(<>){
if(/\(\\012A\)/){
print"LFキャラが使用されています。\n";
}
#イラ8用
if(/\( \)\(\\000\\001\)/){
print"LFキャラが使用されています。\n";
}
#イラ9用
}
MacOS9では「この文字のShift-JISコードなんだっけ？」と思ったときに使える。
print"文字入力>>";
$str = くSTDIN>;
# 引数を $str に格納
（このblogでは<←はhtml言語として認識してしまうので「く」で代用
chop($str);
# 改行を取り除く
@arr=split//,$str;
# $strをバイトで分解して@arrに格納
foreach $byte(@arr){
#@arrの各バイトを$byteに格納しながらループ
@buf = unpack("CC", $byte);
#10進数に変換して@bufに格納
printf "%x%x",@buf
# Shift-JISコード(16進数)で出力
}
#ループを終了
# 8進数にする場合はprintf "%o%o",@buf となる
# 00で始まる文字は00が省略されてしまうため、うまくいかない。今後の課題。
その2 LFキャラcheck
お馬鹿なデザは客から支給されたwordテキストをまんまコピペでイラレに流し込む。当然、行頭にはLFキャラが入ってくる。イラレからまんまカラーゲラを出力する分には気づかないが、EPSにしてQuarkに貼ると文字組みが狂って出力される。その症状が反映されるPSプリンタと反映されないPSプリンタがあるからやっかいである。いちいちファイルを開いて検索・置換するのはメンドイんで、Perlスクリプトにドラッグしてチェック。
#!/user/local/bin/perl
while(<>){
if(/\(\\012A\)/){
print"LFキャラが使用されています。\n";
}
#イラ8用
if(/\( \)\(\\000\\001\)/){
print"LFキャラが使用されています。\n";
}
#イラ9用
}
2007年5月12日土曜日
PDFはいじれない
PDF関連のネタはCLさんが書いていますが
http://blog.dtpwiki.jp/dtp/pdf/index.html
今週、そのトラブルに遭遇しました。プロパティで出所を見るとMacのDistillarを通してPDF1.4(Acrobat4.0)形式に作成されたPDFです。いくつかのTrueTypeフォントが使われているものの、全て埋め込まれています。
このPDFをPSファイルにデータ書き出しをしてFacilisに面付けして出力したところ、文字抜けの発生するところが出てきました。TrueTypeフォントが文字抜けを起こすのなら理解できますが、GothicMB101-Bという純然たるPostScriptフォントです。
以下は検証した結果です。
PDFからのデータ書き出しにはPSファイルとEPSの2通りのやり方がありますが、もう1つのやり方でやってみました。別な箇所で文字抜けを起こしました。
※2つのデータはFacilisに貼る前にRIPに投げて検証
ならば、PDFをそのままRIPに投げたらどうなるか？
問題なくラスタライズされました。
PDFはいじるな！と言われていますが、データ書き出しも「いじる」範疇に入るようです。
現段階で一番安全な運用法は、PDFをTrueFlowに投げてRipped outlineEPSを作成して、そいつを面付けするのがいいみたいです。
OS-Xの機能で作成されたPDFは画面ではまともに見えるものの、カラーゲラ出力ですら透明部分の出力がうまくいかず、対処法として上記のようにRipped outlineEPSを作成して出力しました。
http://blog.dtpwiki.jp/dtp/pdf/index.html
今週、そのトラブルに遭遇しました。プロパティで出所を見るとMacのDistillarを通してPDF1.4(Acrobat4.0)形式に作成されたPDFです。いくつかのTrueTypeフォントが使われているものの、全て埋め込まれています。
このPDFをPSファイルにデータ書き出しをしてFacilisに面付けして出力したところ、文字抜けの発生するところが出てきました。TrueTypeフォントが文字抜けを起こすのなら理解できますが、GothicMB101-Bという純然たるPostScriptフォントです。
以下は検証した結果です。
PDFからのデータ書き出しにはPSファイルとEPSの2通りのやり方がありますが、もう1つのやり方でやってみました。別な箇所で文字抜けを起こしました。
※2つのデータはFacilisに貼る前にRIPに投げて検証
ならば、PDFをそのままRIPに投げたらどうなるか？
問題なくラスタライズされました。
PDFはいじるな！と言われていますが、データ書き出しも「いじる」範疇に入るようです。
現段階で一番安全な運用法は、PDFをTrueFlowに投げてRipped outlineEPSを作成して、そいつを面付けするのがいいみたいです。
OS-Xの機能で作成されたPDFは画面ではまともに見えるものの、カラーゲラ出力ですら透明部分の出力がうまくいかず、対処法として上記のようにRipped outlineEPSを作成して出力しました。
2007年5月10日木曜日
配置画像の収集
あかつきさんより
http://pocketdtp.blog16.fc2.com/blog-entry-116.html引用
DTP駆け込み寺の掲示板のスレッド、
イラレのCS2で配置した写真だけを集める方法？より、
Illustrator CS2に付いてくる、スクリプト→サンプルスクリプト→AppleScript→Collect for Outputに入っているスクリプトで問題解決です。
収集したいaiファイルをこのスクリプトにドラッグ&ドロップすれば、収集先を聞いてきて、aiファイルと配置画像を全て収集してくれました。
はじめにIllustrator CS2を立ち上げ、ファイルを開いていた方が成功します。ダイアログなど英語表記ですが、落ち着いてみればたいしたことは書いていないので、簡単に使えました。
［あらじん］
ということで、試してみました。
1.スクリプトを用意します。
CS2の場合は、アプリケーションをインストールすると、
/Applications/Adobe illustrator CS2/スクリプト/サンプルスクリプト/AppleScript/Collect for Output/
に「Collect for Output.app」というアプリケーション形式のAppleScriptがインストールされていると思います。
CS／10およびCS2で自動インストールされていない場合は、インストールディスクからコピーします。下記の場所に格納されています。
CS2の場合、
インストールディスク2/テクニカル情報/スクリプト/サンプルスクリプト/AppleScript/Collect for Output
CSの場合、
/Adobe テクニカル情報/Scripting/Sample Scripts/AppleScript/Collect for Output
10の場合、
/Illustrator エクストラ/Scripting/Sample Scripts/AppleScript/Collect for Output
※アプリケーション内のIllustratorフォルダにコピーして、Dockに保存しておくと使いやすいと思います。
スクリプト自体は同じみたいで、CS2フォルダ内のスクリプトが10でも動きました。
2.Illustratorのドキュメントを開きます。
モデルはウチのナル。かわいいでしょ（笑）
3.Collect for Output.appを起動します。
AppleScriptのアプリケーション形式ですので、起動すればスクリプトが開始されます。
4.「Press Run to run this script, or Quit to quit.」というメッセージが出ますので、Runをクリック
スクリプトを開始するかどうかの選択ウィンドウです。
5.「Collect the current Illustrator document for output ?」というメッセージが出ますので、OKをクリック
収集を始めるかどうかの選択ウィンドウです。3.と重複する内容なのでちょっと煩雑。
6.「Choose a Folder」で保存先を選択。
ダイアログ左下に「New Folder」のボタンがありますので、新規フォルダを作成してそこに保存することも出来ます。
7.保存先を選択すると、ドキュメントが「別名保存」され、同じ階層にリンクファイルが一緒に保存され、完了すると選択したフォルダに移動します。
このスクリプト、画像を収集する際にドキュメントを別名保存しているようで、動作完了までちょっと時間がかかります。また、eps形式のドキュメントもai形式で保存されますので、入稿用にeps保存する必要がある場合は、再度保存する必要があります。
それから、スクリプトに画像収集したいドキュメントをドラッグ＆ドロップしても収集が可能です。
ついでに、OS９の場合。
OSX用のスクリプトは動きませんので、Illustrator10のインストールディスクからOS９用のスクリプトをコピーします（格納場所、ファイル名は同じです）。
Ver10では同じように収集が可能です。が、Ver８でドキュメントを開いてスクリプトを試してみましたが、スクリプトを起動すると10が立ち上がってしまい、さらにその後は動作しませんでした。なので、Ver8で画像を収集する場合は「イラレの鬼」等を使うしかないみたいです。
間違っても、ver8で作成したドキュメントをver10で開き、このスクリプトを使用して画像を収集、10のドキュメントを8にバージョンダウン保存して入稿したりしないこと。
せっかく配置画像を漏れなく入稿しても、別の要因で出力できなくなってしまいます。
http://pocketdtp.blog16.fc2.com/blog-entry-116.html引用
DTP駆け込み寺の掲示板のスレッド、
イラレのCS2で配置した写真だけを集める方法？より、
Illustrator CS2に付いてくる、スクリプト→サンプルスクリプト→AppleScript→Collect for Outputに入っているスクリプトで問題解決です。
収集したいaiファイルをこのスクリプトにドラッグ&ドロップすれば、収集先を聞いてきて、aiファイルと配置画像を全て収集してくれました。
はじめにIllustrator CS2を立ち上げ、ファイルを開いていた方が成功します。ダイアログなど英語表記ですが、落ち着いてみればたいしたことは書いていないので、簡単に使えました。
［あらじん］
ということで、試してみました。
1.スクリプトを用意します。
CS2の場合は、アプリケーションをインストールすると、
/Applications/Adobe illustrator CS2/スクリプト/サンプルスクリプト/AppleScript/Collect for Output/
に「Collect for Output.app」というアプリケーション形式のAppleScriptがインストールされていると思います。
CS／10およびCS2で自動インストールされていない場合は、インストールディスクからコピーします。下記の場所に格納されています。
CS2の場合、
インストールディスク2/テクニカル情報/スクリプト/サンプルスクリプト/AppleScript/Collect for Output
CSの場合、
/Adobe テクニカル情報/Scripting/Sample Scripts/AppleScript/Collect for Output
10の場合、
/Illustrator エクストラ/Scripting/Sample Scripts/AppleScript/Collect for Output
※アプリケーション内のIllustratorフォルダにコピーして、Dockに保存しておくと使いやすいと思います。
スクリプト自体は同じみたいで、CS2フォルダ内のスクリプトが10でも動きました。
2.Illustratorのドキュメントを開きます。
モデルはウチのナル。かわいいでしょ（笑）
3.Collect for Output.appを起動します。
AppleScriptのアプリケーション形式ですので、起動すればスクリプトが開始されます。
4.「Press Run to run this script, or Quit to quit.」というメッセージが出ますので、Runをクリック
スクリプトを開始するかどうかの選択ウィンドウです。
5.「Collect the current Illustrator document for output ?」というメッセージが出ますので、OKをクリック
収集を始めるかどうかの選択ウィンドウです。3.と重複する内容なのでちょっと煩雑。
6.「Choose a Folder」で保存先を選択。
ダイアログ左下に「New Folder」のボタンがありますので、新規フォルダを作成してそこに保存することも出来ます。
7.保存先を選択すると、ドキュメントが「別名保存」され、同じ階層にリンクファイルが一緒に保存され、完了すると選択したフォルダに移動します。
このスクリプト、画像を収集する際にドキュメントを別名保存しているようで、動作完了までちょっと時間がかかります。また、eps形式のドキュメントもai形式で保存されますので、入稿用にeps保存する必要がある場合は、再度保存する必要があります。
それから、スクリプトに画像収集したいドキュメントをドラッグ＆ドロップしても収集が可能です。
ついでに、OS９の場合。
OSX用のスクリプトは動きませんので、Illustrator10のインストールディスクからOS９用のスクリプトをコピーします（格納場所、ファイル名は同じです）。
Ver10では同じように収集が可能です。が、Ver８でドキュメントを開いてスクリプトを試してみましたが、スクリプトを起動すると10が立ち上がってしまい、さらにその後は動作しませんでした。なので、Ver8で画像を収集する場合は「イラレの鬼」等を使うしかないみたいです。
間違っても、ver8で作成したドキュメントをver10で開き、このスクリプトを使用して画像を収集、10のドキュメントを8にバージョンダウン保存して入稿したりしないこと。
せっかく配置画像を漏れなく入稿しても、別の要因で出力できなくなってしまいます。
初めて作ったPerl Script
入門書を片手に生れて初めて作ったPerl Script。
市販の入門書よりもせうぞーさんの
http://www.seuzo.jp/st/Works/MacPerl-lesson.pdfの方が役に立った。
PDFを作成する際に、OCFのダイナフォントやフォントワークス書体をCIDに変換してエンベットさせる。
（フォントワークス外字は抜けてしまいます。今後の課題です。）
書き出したPSファイルを以下のPerlで処理。
#!/usr/local/bin/perl -pi.bk
#元PSファイル名の後ろに.bkがつきます。
s/(D[CF]P.*?)-(.*?)-(83pv)/$1CID-$2-$3/g;
s/Plus(?=-.+-83pv)/CID/g;
s/CIDCID/CID/g;
#元DFPのCIDとOCFが混在の場合は、font名がCIDCIDになってしまうのでCIDにする。
別な書き方として
#!/usr/local/bin/perl
While(<>){
open(OUTPUT,">$ARGV.new")unless -e"$ARGV.new";
#作成されたPSファイル名の後ろに.newがつきます。
s/(D[CF]P.*?)-(.*?)-(83pv)/$1CID-$2-$3/g;
s/Plus(?=-.+-83pv)/CID/g;
s/CIDCID/CID/g;
print OUTPUT;
}
close OUTPUT;
作成されたPSファイルをCIDフォントのある環境でDistillarにかけるとFontが埋め込まれます。
市販の入門書よりもせうぞーさんの
http://www.seuzo.jp/st/Works/MacPerl-lesson.pdfの方が役に立った。
PDFを作成する際に、OCFのダイナフォントやフォントワークス書体をCIDに変換してエンベットさせる。
（フォントワークス外字は抜けてしまいます。今後の課題です。）
書き出したPSファイルを以下のPerlで処理。
#!/usr/local/bin/perl -pi.bk
#元PSファイル名の後ろに.bkがつきます。
s/(D[CF]P.*?)-(.*?)-(83pv)/$1CID-$2-$3/g;
s/Plus(?=-.+-83pv)/CID/g;
s/CIDCID/CID/g;
#元DFPのCIDとOCFが混在の場合は、font名がCIDCIDになってしまうのでCIDにする。
別な書き方として
#!/usr/local/bin/perl
While(<>){
open(OUTPUT,">$ARGV.new")unless -e"$ARGV.new";
#作成されたPSファイル名の後ろに.newがつきます。
s/(D[CF]P.*?)-(.*?)-(83pv)/$1CID-$2-$3/g;
s/Plus(?=-.+-83pv)/CID/g;
s/CIDCID/CID/g;
print OUTPUT;
}
close OUTPUT;
作成されたPSファイルをCIDフォントのある環境でDistillarにかけるとFontが埋め込まれます。
OS9が消える前に 1
あぷらいとさんより
http://homepage2.nifty.com/upright/aidata.html
BBSからも
Illustrator8データの修復
投稿者：あぷらいと 投稿日：2006/01/20(Fri) 15:30 No.530
最近２件のIllustratorデータが開かないと検証をたのまれました。
１件目は「メールで送られてきたデータ」で拡張子が「.ai 1.ps」となっているので、
メールで圧縮せずそのままやりとりしたものらしい。
内容はver.11で作成されver.8で書き出されたもの。
取り敢えずver.8で開いてみると、
************************************************************
イラストレーションを開くことができません。このイラストレーションでは、
オペレータに対するオペランドの数が正しくありません。
不正なオペレータ：「C」
コンテクスト：
(
%AI6_BeginPatternLayer
0 J 0 j 1 w 4 M []0 d
0 XR
27.2285 49.7178 m
56.9531 49.193454.3838 44.3047 54.2139 43.9805 C
************************************************************
こちらはよく見る状況。
「49.1934」と「54.3838」の間のスペースが欠落している。
エディタで開いてスペースを入れて、Illustratorで開く、
の繰り返しでなんとか開けるようになりました。
ver.8以前のデータをそのままメールでやりとりしたものは
このようなスペースの欠落をよく見ます。
２件目を開いてみると、
************************************************************
イラストレーションを開くことができません。このイラストレーションには、
不当なオペランドが含まれています。
不正なオペレータ：「userdict」
コンテクスト：
%%CreationDate (04/10/93) ()
%%Copyright: ((C) 1987-1996 Adobe Systems Incorporated
All Rights Reserved)
userdict
************************************************************
Adobeのデータベースサポートの「文書番号：216266」の方法では、
「A C D」は、文字が縦組のため一文字ずつバラバラとなってしまう。
「B」の「%%PageOrigin:0 0」に書き換える方法では開きませんでした。
最後の手段として、Illustratorで「新規ファイル」を作成・保存し
エディタで「開けないファイル」と「新規ファイル」を開いて
「開けないファイル」の「%%DocumentFonts:」「%%DocumentNeededFonts:」
「%AI55J_Tsume:」の部分と、「%AI5_BeginLayer」から「%AI5_EndLayer--」
の部分を「新規ファイル」の同じ個所にコピーしました。
これで無事にファイルが開くことが出来ました。
http://homepage2.nifty.com/upright/aidata.html
BBSからも
Illustrator8データの修復
投稿者：あぷらいと 投稿日：2006/01/20(Fri) 15:30 No.530
最近２件のIllustratorデータが開かないと検証をたのまれました。
１件目は「メールで送られてきたデータ」で拡張子が「.ai 1.ps」となっているので、
メールで圧縮せずそのままやりとりしたものらしい。
内容はver.11で作成されver.8で書き出されたもの。
取り敢えずver.8で開いてみると、
************************************************************
イラストレーションを開くことができません。このイラストレーションでは、
オペレータに対するオペランドの数が正しくありません。
不正なオペレータ：「C」
コンテクスト：
(
%AI6_BeginPatternLayer
0 J 0 j 1 w 4 M []0 d
0 XR
27.2285 49.7178 m
56.9531 49.193454.3838 44.3047 54.2139 43.9805 C
************************************************************
こちらはよく見る状況。
「49.1934」と「54.3838」の間のスペースが欠落している。
エディタで開いてスペースを入れて、Illustratorで開く、
の繰り返しでなんとか開けるようになりました。
ver.8以前のデータをそのままメールでやりとりしたものは
このようなスペースの欠落をよく見ます。
２件目を開いてみると、
************************************************************
イラストレーションを開くことができません。このイラストレーションには、
不当なオペランドが含まれています。
不正なオペレータ：「userdict」
コンテクスト：
%%CreationDate (04/10/93) ()
%%Copyright: ((C) 1987-1996 Adobe Systems Incorporated
All Rights Reserved)
userdict
************************************************************
Adobeのデータベースサポートの「文書番号：216266」の方法では、
「A C D」は、文字が縦組のため一文字ずつバラバラとなってしまう。
「B」の「%%PageOrigin:0 0」に書き換える方法では開きませんでした。
最後の手段として、Illustratorで「新規ファイル」を作成・保存し
エディタで「開けないファイル」と「新規ファイル」を開いて
「開けないファイル」の「%%DocumentFonts:」「%%DocumentNeededFonts:」
「%AI55J_Tsume:」の部分と、「%AI5_BeginLayer」から「%AI5_EndLayer--」
の部分を「新規ファイル」の同じ個所にコピーしました。
これで無事にファイルが開くことが出来ました。
2007年5月4日金曜日
Unicode正規化 その４
引き続き引用
http://http://tama-san.com/document06.html
Unicode正規化の種類
これまでの流れだと「Unicode正規化」イコール「結合文字列を合成すること」と思ってしまうでしょうけど、すこし違います。Unicode正規化は合成するだけでなく、分解することにも使われるからです。
Unicode Consortium は、Unicode正規化を４種類に分けて規定しています。
NFC Normalization Form C
NFD Normalization Form D
NFKC Normalization Form KC
NFKD Normalization Form KD
「Normalization Form」は 正規形 と訳されています。「正規化した状態」というような意味です。つまりこの４つは、文字を
合成（Composition）する
分解（Decomposition）する
互換分解（K(C)ompatibility Decomposition）してから合成（Composition）する
互換分解（K(C)ompatibility Decomposition）する
ための方法であるということです。
ここでは、あまり深く掘り下げないことにしているので、「互換分解」には触れません。さらに、話を簡潔にするため、私たちの目的に直接関わる「NFC」だけに限定して見て行くことにします。
テキストエディットに「NFC」がない理由
OS Xには、Unicode正規化のAPIが用意されています。ですから、ソフトウェアにUnicode正規化の機能を実装する場合、そのAPIを利用するだけで簡単にできてしまいます。「その１」の簡単なソフトも、そうやって作りました。
それでは、どうしてOS Xの標準エディタであるテキストエディットに、ユーザが「NFC」を適用できる機能がないのでしょうか？
それは、一見とても便利そうな「NFC」に大きな問題があるからです。逆に、NFCを「結合文字列を合成するためだけに使う」商用ソフトは、その開発体制にひどい欠陥があると見て間違いないでしょう。
NFCの大きな問題
私は上記でNFCを「文字を合成する方法」と書きましたが、実際には予想外の処理をしています。すなわち、これが「NFC」のやっていることです。
「分解（Decomposition）してから合成（Composition）する」
「その１」に登場したこの文字で見てみます。まず、この３つはまったく同じ字形ですが、データ上は
「01D6」「00FC 0304」「0075 0308 0304」
とどれも異なります。それぞれにNFCを適用してみます。
「01D6」→ 00FC 0304 → 0075 0308 0304 → 00FC 0304 → 01D6
「00FC 0304」→ 0075 0308 0304 → 00FC 0304 → 01D6
「0075 0308 0304」→ 00FC 0304 → 01D6
結果としてはいずれも単一の「01D6」になるのですが、はじめから「01D6」になっている文字も、徹底的に分解されて、再度また合成されます。つまり、分解マッピングで分解可能な文字は、それが単一コードであってもNFCでは分解されているということです。
そして、分解された文字がすべて元通りに合成されれば問題はないのですが、「すべて元通りに合成されるわけではない」ところにNFCの大きな問題があります。つまり、合成をしようとしてNFCを適用したら、かえって１文字がバラバラになったり、別の１文字に変わってしまう文字があるということです。（「その３」でも少し触れましたが、「分解」という用語は、１文字をバラバラにするだけでなく、別の１文字にする意味でも使われます）
「分解したあとに合成しない」ことを「合成除外 Composition Exclusion」といいます。Unicode Consortium の「CompositionExclusions.txt」はその合成除外文字の一覧です。一見すると少なそうですが、全部で1000文字以上もあります。
どうしてこんな文字があるのか、調べてみると理由はいくつかあり、なるほどと思うものもあれば、私では理解できないものもあります（チベット語とかヘブライ語なんて分かりませんし…）。そしてこれが遠い外国の文字だけなら、日本で作られるテキストにNFCを適用してもさして問題はないかなとも思うのですが、実は合成除外にもっとも多いのが「漢字」なのですから、困るのです。
次回は、この不遇な扱いを受ける漢字について見ていきます。
http://http://tama-san.com/document06.html
Unicode正規化の種類
これまでの流れだと「Unicode正規化」イコール「結合文字列を合成すること」と思ってしまうでしょうけど、すこし違います。Unicode正規化は合成するだけでなく、分解することにも使われるからです。
Unicode Consortium は、Unicode正規化を４種類に分けて規定しています。
NFC Normalization Form C
NFD Normalization Form D
NFKC Normalization Form KC
NFKD Normalization Form KD
「Normalization Form」は 正規形 と訳されています。「正規化した状態」というような意味です。つまりこの４つは、文字を
合成（Composition）する
分解（Decomposition）する
互換分解（K(C)ompatibility Decomposition）してから合成（Composition）する
互換分解（K(C)ompatibility Decomposition）する
ための方法であるということです。
ここでは、あまり深く掘り下げないことにしているので、「互換分解」には触れません。さらに、話を簡潔にするため、私たちの目的に直接関わる「NFC」だけに限定して見て行くことにします。
テキストエディットに「NFC」がない理由
OS Xには、Unicode正規化のAPIが用意されています。ですから、ソフトウェアにUnicode正規化の機能を実装する場合、そのAPIを利用するだけで簡単にできてしまいます。「その１」の簡単なソフトも、そうやって作りました。
それでは、どうしてOS Xの標準エディタであるテキストエディットに、ユーザが「NFC」を適用できる機能がないのでしょうか？
それは、一見とても便利そうな「NFC」に大きな問題があるからです。逆に、NFCを「結合文字列を合成するためだけに使う」商用ソフトは、その開発体制にひどい欠陥があると見て間違いないでしょう。
NFCの大きな問題
私は上記でNFCを「文字を合成する方法」と書きましたが、実際には予想外の処理をしています。すなわち、これが「NFC」のやっていることです。
「分解（Decomposition）してから合成（Composition）する」
「その１」に登場したこの文字で見てみます。まず、この３つはまったく同じ字形ですが、データ上は
「01D6」「00FC 0304」「0075 0308 0304」
とどれも異なります。それぞれにNFCを適用してみます。
「01D6」→ 00FC 0304 → 0075 0308 0304 → 00FC 0304 → 01D6
「00FC 0304」→ 0075 0308 0304 → 00FC 0304 → 01D6
「0075 0308 0304」→ 00FC 0304 → 01D6
結果としてはいずれも単一の「01D6」になるのですが、はじめから「01D6」になっている文字も、徹底的に分解されて、再度また合成されます。つまり、分解マッピングで分解可能な文字は、それが単一コードであってもNFCでは分解されているということです。
そして、分解された文字がすべて元通りに合成されれば問題はないのですが、「すべて元通りに合成されるわけではない」ところにNFCの大きな問題があります。つまり、合成をしようとしてNFCを適用したら、かえって１文字がバラバラになったり、別の１文字に変わってしまう文字があるということです。（「その３」でも少し触れましたが、「分解」という用語は、１文字をバラバラにするだけでなく、別の１文字にする意味でも使われます）
「分解したあとに合成しない」ことを「合成除外 Composition Exclusion」といいます。Unicode Consortium の「CompositionExclusions.txt」はその合成除外文字の一覧です。一見すると少なそうですが、全部で1000文字以上もあります。
どうしてこんな文字があるのか、調べてみると理由はいくつかあり、なるほどと思うものもあれば、私では理解できないものもあります（チベット語とかヘブライ語なんて分かりませんし…）。そしてこれが遠い外国の文字だけなら、日本で作られるテキストにNFCを適用してもさして問題はないかなとも思うのですが、実は合成除外にもっとも多いのが「漢字」なのですから、困るのです。
次回は、この不遇な扱いを受ける漢字について見ていきます。
Unicode正規化 その３
引き続き引用
http://tama-san.com/document05.html
「単一コードの１文字」に変換する
「変換」と言うと、なにかとても難しい処理をするような印象をうけますよね。例えば、ある一定の数量的な法則に従ってバイナリコードを加工する、みたいな感じです。しかし、結合文字列を単一コードにする場合、この方法は使えません。そこには「一定の数量的な法則」がなく、あるのは言語の恣意性そのものだからです。
とは言うものの、やはり記号を扱うコンピュータ上の無機的な規格なので、Unicode Consortium は「結合文字列」と「単一コード１文字」の対応関係、いわばこの恣意的な関係を、属性のひとつとして各文字毎に逐一明記しています。
UnicodeData.txt
このファイルには各文字の属性が列挙されていて、その中に私たちが知りたい対応関係が書かれています。ここから「ポ」の文字を見てみましょう。
30DD;KATAKANA LETTER PO;......;30DB 309A;......
カタカナ「ポ」は
単一コードで「30DD」
結合文字列で「30DB 309A」
であることが書かれています。
これから分かることは、ここに書かれている情報に従って、例えば「30DB 309A」を「30DD」に置換することで、私たちの目的である「単一コード１文字への変換」が実現できそうだということです。そして、この UnicodeData.txt の記述に従って置換することが、まさに「Unicode正規化」です。
http://tama-san.com/document05.html
「単一コードの１文字」に変換する
「変換」と言うと、なにかとても難しい処理をするような印象をうけますよね。例えば、ある一定の数量的な法則に従ってバイナリコードを加工する、みたいな感じです。しかし、結合文字列を単一コードにする場合、この方法は使えません。そこには「一定の数量的な法則」がなく、あるのは言語の恣意性そのものだからです。
とは言うものの、やはり記号を扱うコンピュータ上の無機的な規格なので、Unicode Consortium は「結合文字列」と「単一コード１文字」の対応関係、いわばこの恣意的な関係を、属性のひとつとして各文字毎に逐一明記しています。
UnicodeData.txt
このファイルには各文字の属性が列挙されていて、その中に私たちが知りたい対応関係が書かれています。ここから「ポ」の文字を見てみましょう。
30DD;KATAKANA LETTER PO;......;30DB 309A;......
カタカナ「ポ」は
単一コードで「30DD」
結合文字列で「30DB 309A」
であることが書かれています。
これから分かることは、ここに書かれている情報に従って、例えば「30DB 309A」を「30DD」に置換することで、私たちの目的である「単一コード１文字への変換」が実現できそうだということです。そして、この UnicodeData.txt の記述に従って置換することが、まさに「Unicode正規化」です。
Unicode正規化 その２
引き続き引用
http://tama-san.com/document04.html
結合文字列が引き起こす様々な問題
これはSafariでGoogle検索をした結果です。なんと「パンダ」の検索結果が475件しかありません。実はこの「パンダ」の文字、フォルダ名をコピペしたものです。「パ」と「ダ」が結合文字列なので、検出されるのは実際に結合文字列を含んだ「パンダ」か「ハンタ」だけというわけです。OS Xユーザで、このようにアイテム名をコピペしてGoogle検索をしたら、検索結果があまりに少なくて当惑した方も多いのではないでしょうか。また、誰もが魅了される素晴らしいパンダのサイトでも、結合文字列を含む「パンダ」を使っていたら、アクセスが増えることは期待できません。
次は、JeditXで結合文字列が混在したテキストをソートしてみました。左がソート前、右がソート後です。同じ字形なのでソートしても並び順が変わらないことを期待するのですが、データが異なるため期待に違う結果になってしまいます。
文字検索に関しても、同じ字形なら同じようにヒットすることを、どのソフトウェアでもサポートしているわけではありません。
これはCotEditorで「u」を「A」に一括置換してみたものです。「0075」が検索対象となって置換されてることが分かります。（CotEditorはとてもよくできたエディタです。この置換結果も決して悪い仕様ではないので、低く評価しないようにしてください）
このように、思いがけない結果になるのが、結合文字列です。とくに１文字に表示できるソフトでは、その文字が結合文字列であることを判別できないので厄介です。それでは、どうしたらこれらを防ぐことができるのでしょうか。
やはりそれには、結合文字列を「単一コードの１文字」に変換するしか方法はないと思います。上の例で言うと、結合文字列「ハ＋半濁音」を１文字の「パ」に変換するということです
http://tama-san.com/document04.html
結合文字列が引き起こす様々な問題
これはSafariでGoogle検索をした結果です。なんと「パンダ」の検索結果が475件しかありません。実はこの「パンダ」の文字、フォルダ名をコピペしたものです。「パ」と「ダ」が結合文字列なので、検出されるのは実際に結合文字列を含んだ「パンダ」か「ハンタ」だけというわけです。OS Xユーザで、このようにアイテム名をコピペしてGoogle検索をしたら、検索結果があまりに少なくて当惑した方も多いのではないでしょうか。また、誰もが魅了される素晴らしいパンダのサイトでも、結合文字列を含む「パンダ」を使っていたら、アクセスが増えることは期待できません。
次は、JeditXで結合文字列が混在したテキストをソートしてみました。左がソート前、右がソート後です。同じ字形なのでソートしても並び順が変わらないことを期待するのですが、データが異なるため期待に違う結果になってしまいます。
文字検索に関しても、同じ字形なら同じようにヒットすることを、どのソフトウェアでもサポートしているわけではありません。
これはCotEditorで「u」を「A」に一括置換してみたものです。「0075」が検索対象となって置換されてることが分かります。（CotEditorはとてもよくできたエディタです。この置換結果も決して悪い仕様ではないので、低く評価しないようにしてください）
このように、思いがけない結果になるのが、結合文字列です。とくに１文字に表示できるソフトでは、その文字が結合文字列であることを判別できないので厄介です。それでは、どうしたらこれらを防ぐことができるのでしょうか。
やはりそれには、結合文字列を「単一コードの１文字」に変換するしか方法はないと思います。上の例で言うと、結合文字列「ハ＋半濁音」を１文字の「パ」に変換するということです
Unicode正規化 その1
ものかのさんより
http://tama-san.com/document03.html
実は、OS X には結合文字列が普通にいたるところにあるのです。しかも、新しく簡単に作ることもできてしまいます。やってみましょう。
デスクトップに新規フォルダを作ります。なんと、これだけで結合文字列のできあがりです。「ダ」の文字を「簡単なソフト」へペーストしてみてください。２文字の結合文字列であることが分かります。
このように、OS X のフォルダ名やファイル名などのアイテム名は、結合文字列にできる文字ならすべて結合文字列になってしまいます。アイテム名をテキストにコピー＆ペーストしたことがない人はいないでしょうし、普通に作るテキストデータに結合文字列が混ざることは大いにありそうなことです。それにWindowsでもVistaが結合文字列に対応したことで、結合文字列混在の可能性がひときわ高くなったことも押さえておくべきだと思います。
http://tama-san.com/document03.html
実は、OS X には結合文字列が普通にいたるところにあるのです。しかも、新しく簡単に作ることもできてしまいます。やってみましょう。
デスクトップに新規フォルダを作ります。なんと、これだけで結合文字列のできあがりです。「ダ」の文字を「簡単なソフト」へペーストしてみてください。２文字の結合文字列であることが分かります。
このように、OS X のフォルダ名やファイル名などのアイテム名は、結合文字列にできる文字ならすべて結合文字列になってしまいます。アイテム名をテキストにコピー＆ペーストしたことがない人はいないでしょうし、普通に作るテキストデータに結合文字列が混ざることは大いにありそうなことです。それにWindowsでもVistaが結合文字列に対応したことで、結合文字列混在の可能性がひときわ高くなったことも押さえておくべきだと思います。
登録:
投稿 (Atom)
