素材工房（というより鍛冶屋って感じだけど）のコンテンツで使っている画像ファイルを見ていたら、アルファチャンネルPNGなのに妙にサイズが小さいファイルを見つけました。他の同じ程度の大きさの画像だと90KB程度になっているのに、30KB程度....。32bitPNGは圧縮していない形式なのに.........。

　どう考えたって手持ちのソフトで書き出したに決まっているのですから、使ったソフトをいろいろ調べていたら発見！

　なんとFireworksでは、8bitのPNGにもアルファチャンネルによる透明化を実現出来たのです！！！　.....たぶんその画像は何かの手違いでそういう書き出しをしてしまったのだと思います。......自分でも気付いていなかったので....。

　手持ちのグラフィックスソフトでPNGの書き出しが出来るのは、Adobe ImageStyler1.0、Photoshop Elements1.0、Macromedia Fireworks4で、ImageStylerでボタンやプレート等を作った場合はImageStylerで書き出しをし、その画像のうち、スライスする必要があるものは、Fireworksで処理していました。

　ImageStylerは古いソフトなので、デフォルトではアルファチャンネルによる透明化PNGは書き出し出来ないのですが、Photoshop ELにあるプラグインのファイル形式フォルダにあるPNGのプラグインをImageStylerのプラグインフォルダに入れる事によって、アルファチャンネルによる透明化が可能なのです。（......たぶんこれを発見したのは自分だけだろうな....）　それでも書き出し可能なのは、8bitか32bit（=TrueColor）のどちらかで、8bitでは圧縮はできるのですがアルファチャンネルには対応しておらず単一の透明化のみ可能なので、GIF形式と同じ様なものです。32bitはオプションがなく、アルファチャンネル透明化可能ですが圧縮無しの書き出しになってしまうので、ちょっとした大きさのボタンでも、100KB超はざら、という具合です。

　同じプラグインにしているはずなのに、Photoshop Elementsでは、32bitの選択肢がなく、8bitと24bitの書き出しに対応しており、8bitについてはImageStylerと基本的には同じでカラーの割り当てが出来るくらいで、24bitがImageStylerでの32bitと同じ機能らしいのですが、ファイルサイズがImageStylerでの書き出しよりも少し小さくなるのです。たぶん24bitだからなのでしょうが。それでもまあ五十歩百歩みたいなものなので、大きなサイズには変わりありません。

　Firework4では、8、24、32bitそれぞれ選択肢があるのですが、24bitでは透明化できないので、32bitでしかアルファチャンネル対応していないと思っていたので、そのまま32bitで書き出ししていました。

　なのに......なのに.........8bitでもアルファチャンネル対応出来たとは......迂闊でした。自分の間抜けぶりを改めて認識するはめになってしまいましたが、とにかくこの事実を知った事は、非常に有益でした。ほとんど1/3程に小さく出来るのですから、あれだけPNGを大量使用しているコンテンツにとっては物凄いサイズ減少になるわけです。8bit=256色までしかカラーが使えないのですが、カラーの割り当てがこのFireworks、非常に上手く、ほとんど元画像と同じ状態で書き出しできるんです......。ちょっと信じられないくらいです。

　でも....8bitPNGって、確かGIFと同様に単一の透明化しかできない仕様だったはず.....。PNG関連のサイトを見てもそう書かれているのに.....、。ということは、8bitでアルファチャンネルを持てるPNGはFireworks独自のファイルなの？？？　でもIEを初めとして、ブラウザチェックに使っている全てのブラウザできちんと表示できたし......。ちょっと「?」な感じ。それに........実はついうっかりして、結合せずにレイヤーマスクを残した状態のPNG画像をそのまま使っていたものもあったのですが、それも問題なく表示できるし.............Fireworksってすごいかも。

　なぜ、こんなにPNGに執着しているかというと、W3Cが、今後のWeb用の画像ファイルとして、PNGを奨めているからです。というか、いろいろとライセンス関係で問題のあるGIFに変わって高機能の画像形式を用意しようとW3Cが提案してきたものの結果がPNGなのですから、今後Webでは標準になるはずです。W3Cがそう言っているんだから、それに従わざるを得ないですし。HTMLだってそのうちXHTMLで書かれたWebページが多くなるでしょうし、エンコードだって、ユニコード(UTF-8/16）になっていくでしょうし.....。　とはいえ、事実上の標準ブラウザであるWin:IEがアルファチャンネルPNGに対応していないせいで、普及が進んでいないという現実もあるので、次バージョンのIE次第なのかもしれませんが。　しかし他のブラウザは全て実装しているし、どうせW3C辺りからも対応を迫られているでしょうから、対応するとは思いますが。

　ともかく、32bitPNGを大量に書き出してしまった今頃になって気付いたのは遅すぎるのですが、Fireworksにはパッチ処理機能もあるので、まあ楽に変更できるでしょうし、近いうちに、鍛冶屋も癲狂院も、ぐっと画像の読み込みが早くなるはずです。

　なんだか、自分のやりたいことはすべてこれらのソフトをフルに使う事によってほとんど可能なのかも。もちろん将来は分からないけど現状では問題無しだし。.......改めて振り返ると、ソフトの選択肢は間違っていなかったのかも、って思います。どれも1万〜2万以内の低価格なソフトなのに上手い具合に機能が重なっていないから幅広く対応できたのですね.....。

今回の素材工房だって、手持ちのソフトを総動員して作っています。

STRATA Vision3d 5.0　で、3DモデリングしてレンダリングイメージをJPEG形式で保存。

Photoshop Elements1.0　で開き、背景を取り除き、色調補正、テクスチャをレイヤーに重ねたりして、もともとコントラストの弱い出力になりがちなVision3dのレンダリングイメージを補正。PSD形式で保存。

ImageStyler1.0（現在はLiveMotion2.0）に取り込み、レイヤースタイルを追加。影を付けたり、ImageStylerで別に作ったロゴやボタンなどと組み合わせたものをグループ化して、PNG形式で保存。

Fireworks4　で開き、スライス設定を必要ならば設定した後、Web用に画像を最適化し、画像を書き出し。その際にスライスした場合は、テーブルレイアウトされるHTMLソースも一緒に書き出し。ここで画像関係の作業は終了。

書き出したHTMLを、Dreamweaver4で開き、多少修正した後、そのテーブルレイアウトのソースを、別のHTMLファイルに組み込み、同時にページを制作し保存。

mi（ミミカキエディット／フリーウエア）でHTMLファイルを開き、XHTML用に修正、細部を修正してWebページ全体が完成。

　.......6つもソフト使ってるよ.........。さっさとDreamweaverを最新バージョンにして、Photoshopのフルバージョンを買え！って感じですが。　特にDreamweaver4は、もう4年くらい前のものになるので、CSSの表現はほとんどアテに出来ないし、HTMLだって、Validではない記述を平気でするし、その修正が面倒くさいので、これだけはアップしておきたいかも。現行Dreamweaverがバージョンアップしてしまったら、アップグレードできなくなってしまうし。（2世代前までがアップの対象だったはず）

　それなので、今はテーブルレイアウトと画像配置のみソフトで行い、他のほとんどは手書きでタグ打ち状態です。そのタグ打ちに便利なのが、少し前から使い始めたmi（ミミカキエディット）というMacではだいぶ前からポピュラーだったフリーウエアのテキストエディタを使っています。デフォルトでも標準のテキスト形式はもちろん、HTMLやCSSの記述にも対応していて、タグや要素をメニューから選ぶだけでポンとテキスト内に記述されるので、ちまちまと打つ手間も省けるので助かっています。ユーザの方が作成された「モード」と呼ばれる拡張機能を組み込む事により、さらに機能がアップするので大変便利です。
　ユーザの方が作成された、XHTMLに対応したモードで編集しているのですが、文字コードもユニコード（UTF）に対応しており、テキストの変換も楽だし大変助かっています。XHTMLでは、タグ等は全て小文字で表記することになっているのですが、DW（Dreamweaver4）で書き出されたものは大文字も混じっているし、<br>もXHTMLでは、<br />という風に閉じなければいけないのですが、DWでは閉じてくれないので、改行を多用する文章の記述は出来ないので、miで編集しています。検索／置換機能も優れていますし.......本当、素晴らしいソフトです。

　.....とまあ、こんな感じでいつも作っています。
他の人も、いくつもソフトを多用しているのかもしれませんが、なんだか自分の場合は、それがやたらみみっちい感じが.............なきにしもあらず。いやいやそれでもよいのです。低価格のソフトでもこうして一応それなりのサイトは作れるし、なにより宝の持ち腐れにならないから、罪の意識に苛まれずに済みます。w

　修正がようやく終わりました。
意外に時間が掛かってしまいました。......本当はもっと単純ですぐ終わるはずだと思っていたのですが......。どちらかというと癲狂院の方の修正に手間取ってしまいました。

　まず、HTML+CSSのソースに修正箇所があってそれを直すのに苦労しました。VMLでアルファチャンネルPNGを透明化させると、なぜか右下に1ピクセルずれるのです。例えば1枚の画像をスライスしてテーブルレイアウトした時に、そのままだと1ピクセル分右下にずれて、レイアウトが崩れてしまうんです。VMLのことを良く知らないのもあるかもしれませんが、検索しても全くヒットしないし根本的に対処するのは無理だったので、しかたなくアルファチャンネルPNGの<img>タグに、クラス指定してあります。　もっともこのことは、癲狂院を公開する前から把握していた事ですし、Materialer〜と違って、テーブルレイアウトよりもレイヤーでパーツを重ねているデザイン故にposition指定しているので、1ピクセルずれようが関係ないのですが。ただ、その箇所ごとに別のクラス指定していたので、CSSがぐっちゃぐちゃになってしまっていたので、それを中心に、CSSの部分を今回修正しました。

　これは当コンテンツのようなposition指定でがちがちにレイアウトする場合のためのtipsですが、そういうレイアウトをする場合、position: relative; と margin　で位置調整をした方がよいということです。position: relative;　とtop,leftで調整すると、元の位置の部分が空白になるので、1つくらいならば良いかもしれませんが、組み合わせてレイアウトすると崩壊します。w　いや、本当です。ただ、これも限界があってすべてをmarginでの調性で済ませられるわけではなくて、top,leftと併用することによってうまく崩壊を免れる様です。

　テーブルのセルを動かすには、position: relative; top,leftでしか移動できなかったと思います。marginでは動かなかった様な.....。とにかく、アルファチャンネルPNGを扱うと、もうとんでもない事になるので、気が狂います。w　VMLを適用するのはWindowsのIEでのみなので、ブラウザごとにCSSを切り替える様にしないと、他のPNGに対応しているブラウザでズレてもいないのに左上に1px分詰めてしまうことになるので、よく見るとちょこっとだけ潰れているように見えてしまいます。

　そういうわけで、ちゃかちゃかとJavaScriptでCSSの振り分けをしています。IEのCSSバグを逆に利用した、CSSハックを利用する手もあるのですが、Win:IEに限らず、もう色々なブラウザが様々な解釈で表示するので、その部分だけを抜き出してJavaScriptで振り分けています。ちなみにそのスクリプトは自前です。自分でもJavaScriptが組めたなんて！.....とはいっても2行程度ですけどね。w

　そんな見えない所をよりスマートに修正したのがほとんどですが、それ以外は動作の高速化の修正でした。
自分の環境では、Win:IEの動作はすごく高速で、テレポート移動も別にさくさくと動いてくれていたのですが、Mozilla系のブラウザではどうしようもなく遅いのです。以前は、まあ打つ手がなく諦めていたのですが、テレポートのJavaScript内で、テレポートの速度を調節する箇所で、ブラウザごとに振り分けるスクリプトを書き込むことによって、1つのスクリプトで各ブラウザのコントロールが可能になりました。Mozilla系ではIEの4倍程の速さに設定しています。それくらい処理が遅いのです。　なんとなく分かったことは、テーブルレイアウトで画像を敷き詰めている場合や、インラインフレーム使った場合、背景画像を固定した場合、遅くなる様です。.....ってこれら全部を適用しているわけですが.......。　　せっかくなので、修正のついでにWin:IEも若干速度を上げました。もっと上げても良いかもしれませんが、パソコンによっては、画面が飛ぶ気がする。w　ただ、Windows XP以前のOSとIEの古いバージョンでは、どうも動作が怪しい感じ。それらに関してはもうどうしようもないし過去のことなのでスルーさせていただきます。うちのセレロン互換のAMDの900MHzでメモリ256MBのWindowsXP SP2　の2年前のノートPCであれだけ高速に動いたのですから、たぶん最近のXP搭載マシンなら問題ないはず.........。

　あとはファイルサイズ。
前にも書きましたが、奇跡の8bitアルファチャンネルPNGがFireworksでは書き出し可能なので、すべてのPNG画像をパッチ処理で一気に変換して、アップしました。今まで1ページの総ファイル数が1MB超なんてざらだった悪夢の様なページがどれもほぼ1/3以下になりました。......とはいっても、結局の所、ADSL1M以上でないと辛いかも.....。

　そして、フレーム仕様ページ。
もうどうしようもなく重いって方のためにせめてもの策として、フレーム仕様も用意しました。フレーム用に各ページを用意するのはご免なのでそれはできませんが、それでも軽いし、少しでもビジターに見てもらうための努力をそれなりにはしています。..........だって本当に人が来ないんだもの.....。せっかく苦労して作っても誰も見てくれないんだったら努力は水の泡になってしまうし......。10hit/day...なんていう状況から抜け出したいです。癲狂院なんかもっとひどくて3hit/dayくらいあれば多い方だもん。（ぉぃそれって......）　......まあコンテンツの中身が乏しいっていうのは認めざるを得ませんが、それでも、Web制作のリンク集などは充実している気がしますし、けっこう参考になる箇所もあるとは思います.........。

　あと、このDiaryのアドレスを変えました。他人には関係ないかもしれませんが、管理人としては、やっぱりtenkyouinのディレクトリに収めたかったので、インデックスとアーカイブなどは全て移動しました。

　まあそんなわけで、ようやくこの2つのコンテンツ、修正箇所も無くなり、放置出来ます。（ぉぃ）　次はコンテンツの充実です。でもその前に伏魔殿の設置と第七天のリニューアル作業が残っているわけですけど。w

修正したのでした。
これもけっこう無茶なCSSの使い方+激重画像使っていたりしたので、前々から修正しなくてはとは思っていました。ちょっと画像が大きかったので、1024*768のサイズで見ると、十字がでかすぎ。なので一回り小さくコンパクトにまとめました。他には......どうでもよいことなのでしょうが、タイトルのフォントサイズ、ページの余白、ページ下部のバナー台、結構細かい箇所まで綿密に修正しなおしました。　なんとなく縦に長いページにしたかったので、今回の修正で、うまく収まる所に収まった、という感じで、満足しています。

　そういえば、Materialer〜と癲狂院、それぞれテキストに使うフォントも改めてCSSを書き直しました。今までWindowsのフォントについて良く知らなかったためフォント指定に消極的だったのですが、このDiaryをWinで見ると字間が妙に空いてカッコワルく感じてたので、なんとかしようと思っていろいろ調べたら...........どのWindows機にも確実に標準でインストールされているフォントって、意外に少ないことがわかりました。　特に和文フォントは少なく、明朝体などは通常のテキストのフォントサイズではギザギザで読みづらいし、結局、ゴシックフォントの3つだけになってしまうんですね....。その中でも字間が気に入った、"ＭＳ Ｐゴシック"にしました。プロポーショナルフォントですね。欧文フォントについても、Materialer〜のほうでは部分的に指定しています。Macにも同じくインストールされている"Impact"を使っています。癲狂院の方でも試してみたのですが、合う様なフォントがなくて............残念です。"　University Roman"が標準でインストールされていればねえ.....。ラッキーなことにうちのWin機には最初からインストールされていたのだけど.....。　とにかくフォントの力は医大だと思っているので、フォントの埋め込み技術とか気になっているけど、あれって実用的ではないし。　
　　Macをお持ちでないウインドウズユーザーの方は、ぜひ一度マックで自分のサイトを見てほしいです。........ぜったい驚くから。こんなに綺麗なの？？？って思うはずだから。　OS Xになってから標準でインストールされているヒラギノシリーズは本当に素晴らしいフォントです。OS側で常にアンチエイリアスがかかっているせいもあると思いますが、滑らかで美しいのです。それが普通に表示されるんですよ。　ためしにCSSのフォント指定で、"ヒラギノ角ゴ Pro W3"とか、"ヒラギノ明朝 Pro W3"と指定してみれば、..........Winでは残念ながら変わらないけど、Macで見ると、見違える　！　角ゴの方は指定しなくてもデフォルトで指定されているのであんまり意味ないかもしれませんが。

　あ、あと、そう！　スクロールバーの着色も今回初めてしてみました。Win:IE独自のプロパティなので、以前は邪道だと思っていました。Macには関係無いし、IEの「勝手に実装した」プロパティだと思っていたので。.........確かに勝手に追加したプロパティですが、実際のブラウザのシェアを考えれば、多くの環境で表示されるわけだし、W3Cに従わないから何だかんだ言ったとしても、......( ・x・)ﾌｰﾝ　って感じでしょう？　せっかくそういう機能があるのだし、その機能の有無でレイアウトが崩れるわけではないし.....と思って、指定しました。　その結果、すごく見栄えが良くなった気がします。スポイトツールでスクロール付近の背景画像の色を取り出して、その色で指定しているので、うまく馴染んでくれて満足しています。　あえてブラウザウインドウには指定せずに、コンテンツ内部の、overflow: auto; で疑似インラインフレームになる部分だけ、指定しています。

　部分的ですが、カーソルの指定もしています。.........よく巷で、カーソルがえらいことになっているサイトを見かけたりしますが、あれって......ちょっと廚臭いので、やだな〜と思って敬遠していたのですが、ヘルプのリンクだけは、ヘルプのカーソルになるようにしたほうがいいかなと思って、そうしました。

　そんなわけで、あと気になっているのが、テキストの影を表示出来るプロパティ。　実はこれ、Macの標準ブラウザ、Safariのみ対応しています。これはSafariの独自のプロパティではなくて、CSS2に規格としてきちんと盛り込まれているものなので、この先廃止されなければ、いずれは他のブラウザも対応してくれるはず！　最近そのことを知ったので...........近いうちに......どこかに影をっ！