最近3.5にバージョンアップしたのですが、、3.5は重くて使えません。
ロケーションバーをコピペしようとしても文字が消えたり、「履歴とブックマークを検索」に変わったかと思うと、URLが二度と表示されなくなったりします。
JavaScriptが高速になったらしいですが、そのぶんメモリを食うようになってOS（Vista）がFirefoxにロックをかけて、画面の再描画に1分ぐらいかかることがあります。
3のころにはそういうのはまったく発生しませんでした。
アドオンもなかなか対応してくれず、マウスジェスチャ系も全滅です。
パッチがこれば直るだろうとダウングレードもせず、Firefox3の使い勝手に気をよくして封印していたOperaを再度引っ張り出して使うのでした。
結論から言うと失敗作というか、最小値と最大とのみを考慮して作られた式です。
はっきりいって使い物になりませんが、フリーソフトではつかっちゃっているようです。
動作確認用に作ったものなので、細かいエラーチェックは抜きです。
#===============================================================================
# RGB => CMYK（cmyが同じ値の場合kに割り振る）
#-------------------------------------------------------------------------------
sub rgb2cmyk {
my $rgb = shift;
$rgb =~ /^#?(..)(..)(..)$/;
my %color = (
'r' => hex( $1 ),
'g' => hex( $2 ),
'b' => hex( $3 ),
);
$color{'c'} = 1 - ( $color{'r'} / 255 );
$color{'m'} = 1 - ( $color{'g'} / 255 );
$color{'y'} = 1 - ( $color{'b'} / 255 );
$color{'k'} = 0;
if(
$color{'c'} == $color{'m'}
|| $color{'m'} == $color{'k'}
){
$color{'k'} = $color{'c'};
$color{'c'} = $color{'m'} = $color{'y'} = 0;
}
return %color;
}
結局、色を絞って変換テーブルを自作することになりましたけどね。
CentOSとか、Fedoraとかで、デスクトップ使用でセットアップした後に、アプリを削除すると一緒にGTKも消されてGNOMEが起動しなくなる。 yum groupinstall ”GNOME Desktop Environment"
一番最初はかなり慌てたけど、何度かやるうち（何度もやるなよ）にだんだん慣れてきて（慣れるなよ）しまった今日この頃。
yumでグループまとめて入れば直るはずです。
グループの指定方法について詳しいサイトがありました。
yumでグループを使う
CentOSとFedora以外ではやらかしてないので、ほかのディス鳥については不明です。
ゴンゾが上場廃止になるらしいです。
そこでゴンゾでも支援してやれば、アキバの支持率は大幅に持ち直すと思いますよ。
もちろん、あまり表に出ない制作会社も忘れないでいただきたい。
すくなくとも、補正予算なんかでアニメの施設を作る必要はありません。
アニメを作る会社が減れば、施設の意味もなくなるんじゃないですか？
漫画雑誌が減ると、麻生さんの楽しみも減るんじゃないですか？
ライセンスが必要なものはもちろんフリーではないが、
何かしらの条件をつけて、もしくは無条件にフリーとして配布しているものはフリーである。
GPLライセンスとかの話はおいといて。
つまりこれらは著作者が決めるべきことで、外野が決めるものではありません。
アドバイスなどで考えを改めたとしても、その結果は著作者が決めたことです。
お金を出しても使いたいものか、タダなら使ってあげてもいいものか。
カンパウェアなんてものもありますね。
一部使用者が決められるものもあります。
これは、使用者が決めていいと著作者が決めたのです。
「そもそもフォントはお金を出して買うもの」
フォントに限った記事でしたが、かなり偏った意見に思われます。
英字圏と漢字圏ではフォントの意味が異なります。
使う文字の数が極端に違うからです。
フォントには、漢字を含まないひらがなやカタカナだけのフォントもあります。
もちろん、英字だけであってもライセンスが必要なフォントもあります。
ただ、この違いを無視して必ず金を払うようにすすめるのは間違いでしょう。
「フリーフォントの配布には、制作者にとってなんらかの目的があり、プロモーションのための1つの手段である」
これは、ネットで公開すれば必ずレスポンスにつながると思っている基本的なミスです。
作ったものを広めるためには広告という手段が必要で、それを回収するために使用料を設けることももあるのです。
つまり、フォント自体に対する料金なのか、使ってもらうための広告料金を回収するための料金のか。
もちろん、サイトにアップするだけで広まる場合もありまし、自演的にあちこちにアップロードする場合もあります。
また、リスクを承知でタダにすることもありますし、本当に自己満足だということもあるでしょう。
買わなければならない、のではなく、買うべきものは買う、そうでないものもある、なのです。
にっぽつ！
というわけで、ドメインをとりました。
フリードメインだとたまにおかしくなるので保険として。
http://nippotsu.org
細かい構文は別の機会に。
EPSファイルを作るには、ImageMagickで画像をEPS化したものを、PerlのPostScript::Simpleでデータ毎埋め込んでいましたが、1つのデータでは特に問題がなくても、面付けまで自動的にやろうと思った場合、ファイルサイズがとんでもないことになってしまいます。
そこで、画像のEPSファイルをリンクで指定できれば面付けしてもファイルサイズはぜんぜん問題になりません。
そこで、いろいろ調べて見つけたものを試してみました。
しかし、GSViewでは問題なく表示されても、イラストレータで開けません。
いろいろ試してみると、ファイルパスの指定方法に問題があるとわかりました。厳密にいうと、イラストレータのファイルパスの扱いに問題があるのですが。
リンク先の画像EPSを特定の場所におこうとした場合、ドライブを含む、若しくはドライブ以下の絶対パスが必要です。
そのパスを指定したくない場合は、ドライブの直下に置けばいいことがわかりました。
つまり・・・
Cドライブの直下に置けば、
%%BeginDocument: image.eps (image.eps) run %%EndDocument
となります。
仮にC:/eps/に置くとすれば、
%%BeginDocument: image.eps (C://image.eps) run %%EndDocument
となります。
ファイルパスを指定するのは面倒なので、ドライブを1つつぶしてその直下に置いたほうが断然楽でしょう。
WordPressに待望の新バージョンが出たわけですが、自動アップグレードでWP以外のファイルが削除されるという不具合が発生しているようです。
この不具合は致命的な欠陥です。
フォーラムには手動でアップグレードすれば問題ないと書いてありますが、そもそも「ファイルを勝手に消してしまうコードがどこかにあるわけで、アップグレードの手段を変えただけで本当に回避できるのか？」と疑うべきでしょう。
もちろん、この不具合はアップグレード前、つまり２．７の自動アップグレード機能に問題がある可能性もあるわけですが、それらがはっきりしてない以上、余計なことをしない方がいいのかもしれません。
とはいえ、新し物好きな性分なので、別のサイトのWordPressを2.7.1から2.8に手動でアップグレードしてみることにしました。
特に凝ったこともやってないから、困ったことにはならないだろうという勝手な解釈です。
削除してからアップするべきだけど、2.7.1のときは問題なかったので完全に無視して、上書きで更新。
いよいよwp-adminにアクセスすると・・・画面真っ白。レスポンスヘッダは一応出力されているけど、コンテンツのサイズが0で、まったくの空っぽです。
とりあえず、ファイルを一度削除してアップしなおすことにしました。
これでとりあえず動くようにはなりましたが、今まで使っていたオリジナルのテンプレートが使えなくなってしまいました。
もうくだらないことに時間を割くのももったいないので、初期画面に戻してしばらく様子を見ることにしました。
WordPress2.8は改悪でしたね・・・
先日いろいろ苦労したサーバーのインストールですが、サーバーの機能を一部あきらめてみることにしました。
デバイスの辺りに問題がありそうなので、一番問題と思われるRAIDコントローラーをを外してみることにしました。
PCIボードに刺さっているADAPTEC 2010Sをはずして、CentOSを入れなおしてみると・・・成功です。
何の問題もなくインストールできました。
ハード優先するよりも、使い慣れたOSが動くようにチューンしたほうが後々いいはずです。
今まで動かしていたUbuntuは多機能とはいえども、いままでの慣れには劣るため、設定周りで難儀していました。テキストで全部やればいいんでしょうけど、ここは過程より目的です。
CntOSnoパッチを当ててからまたWCGで付加テストをやって、問題なさそうなら時期サーバーにします。
うるさいけど。
フォームでtextareaを利用するとテキストエディタ風に編集できますが、この文字に装飾を加えることができません。
検索してみるとcontenteditable="true"という属性があるとわかりました。IE5.5から実装されたようです。
この属性はタグに追加するだけで直接編集できるようになるのですが、何らかのイベントの後にinnerHTMLで内容を置き換えると無効になるというIEらしいバグがIE7でも残っています。IE８は知りません。
この属性はIE以外のブラウザでも利用でき、innerHTMLで置き換えても正しく表示されるブラウザは、Firefox3、Opera9、Safari3.2でした。
他にもあるかもしれませんが、必要な範囲で調べました。
IEが作った属性なのにIEでは動かずに、サードパーティで動くとはこれいかに。
IEのせいでクロスブラウザなコンテンツを作るのが難しく面倒になります。
なお、この属性を検索すると「コンテンツの編集許可」でたくさん出てきますが、この単語で内容がわかるほどエスパーではありません。