想定外

なんだか今週は想定外の事態にみまわれた…

おいどんが作成したflashに組み込んだログ計測がきちんと機能してないと連絡有り。
きちんと仕様書通りに組み込んだのに…。
でも代理店さんの持っている情報(というか代理店さんのつきあいのある別の
制作会社さんからの情報)で、イベントハンドラ内から実行すると何故か
正常にjavaScriptに情報が渡らないらしい事が判明…。
ということで、フレームに書いて、そのフレームへgotoAndStopなんていう
仕組みにしたら正常に機能した。ほっとひと安心。
そんなこと仕様書には全く書いてないのにぃ。

別案件で、印刷機能をもったFlash。
印刷すると、透過部分が黒ベタで印刷されると連絡有り。
PNG(32bit)を使っていて、うちのプリンタでは問題なかったのに…
でも、ネットでしらべたら、アルファのある画像は印刷でアルファ部分が
不透明になるのは「flashの仕様」ということが判明…。
今回はグラデアルファでないので、マスクしてみた。
うちでは検証できないので、代理店さんでの検証待ち…。

ふぅ。

さて、明日は入門講座Cだ。
授業の準備もしないと!!

———————————————
追記
マスクする場合でも、半透明のムービークリップでマスクしたものはダメみたい。
でも、今回はシンプルにベタのシェイプで対応できるコンテンツなので無事対応完了!
勉強になりました。

ふぅ。

wordPressの改造

jQueryの記事をカテゴリ表示するときだけ、記事を古い方から表示するようにしてみました。
変更したのはカテゴリーテンプレート(category.php)で以下の様にループで記事表示する前の
部分に、カテゴリがjQueryだったら記事を古い順にソートするようにしました。

<?php if (is_category('jQuery')) { ?>
 <?php $posts = query_posts( $query_string . '&order=asc' ); ?>
<?php } ?>
 
<?php while ( have_posts() ) : the_post(); ?>			
 <?php get_template_part( 'content', get_post_format() ); ?>
<?php endwhile; ?>

青字の三行が追加部分で、最初の行でカテゴリがjQueryかどうかをチェックし、
もしそうなら、次の行で記事を古い順にソートします。
 
参考ページ
・カテゴリーによって異なるテキスト
・query_posts:並び順・並べ替え引数
 
 
 

備忘録:印刷への配慮

印刷への配慮

19日の記事の続き。です。時間が無いので箇条書きっぽくなっています。
 

印刷はいつでも利用される可能性がある

めでたく印刷画面の生成に成功したのですが、問題に気が付きました。
ブラウザの印刷機能は、結果画面だけでなく他の段階でも利用される可能性があります。
 
作成しているコンテンツのは複数の段階があるのですが、どの段階で印刷機能を
利用しても、印刷用に生成した「結果画面」を印刷してしまうのです。
 
結果画面以外で印刷機能が利用されることは少ないと思うのですが、これはいけません。
ということで、結果画面以外では印刷用に生成した画面を印刷しないように修正しました。
状況に応じて印刷用のclassを付け外しして対応。
 
 

ブラウザの印刷仕様

ブラウザには色々種類がありますが、大抵のブラウザではデフォルトで背景色/背景画像を
印刷しない仕様になっています(表示する設定にする事も可能)。
これはインクの消費量を抑える配慮らしいのですが、このことを頭に入れておかないと
必要な情報が印刷されないことになってしまいます。
 
 

印刷への配慮

印刷に配慮したcssの記事はネット上に多くみつけることができました。
ポイントとしては以下の通り。
・メニューやリンクなど紙面では機能しない部分は表示しない。
・モノクロ印刷でも見やすくするために文字色は黒に。 
 
 

背景利用したボタン

昔はマウスオーバーで画像を切り替えるのはjavaScriptを利用して、表示画像を切り替える
のが主流だったように思います(dreamweaverでもそのようなビヘイビアがありましたし)。
しかし、今では背景画像の表示位置を切り替えて対応する場合が多いと思います。
そうすることで、javaScriptを書かずに対応できプリロードの問題も無くなります。
詳しくは以下のページで。
→参考:サンプル「選択肢の作成(1)
 
この様に作成したボタンは印刷時に表示されないので「印刷への配慮」で記した
「紙面では機能しない部分は表示しない」にも繋がり一石二鳥です。
 
しかしコンテンツによっては、ボタンを印刷しないと画面が成立しないケースが
でてきます。現在作成している案件でも、そのような箇所があるので
部分的に昔ながらのjavaScriptで制御するボタンに切り替えました。
 
 

背景を印刷するモードもある

検証は色々なケースを考えて行ったのですが、印刷用のcssを用意している時に
「背景を印刷する」モードで印刷すると困るケースが出てきます。
例えばフッター部分を「黒背景に白文字」でデザインし、印刷時には
背景が表示されないから「文字を黒くする」ように設定するとします。
 
この場合、デフォルトの「背景を印刷しない」場合は問題ないのですが、
「背景を印刷する」の設定にすると、黒背景に黒文字になり読めなくなってしまいます。
なので、印刷用のcssには背景色を白にする記述も追加しなくてはなりません。
 
 

印刷に配慮することへのジレンマ

この段階で、ふと考えてしまいました。ブラウザの表示と同じ印刷結果が欲しくて
「背景を印刷する」設定にしても、印刷用のcssを利用していると、それとは異なる
結果が出力されることになります。これは良いのだろうか?
悩んだ時は、他の企業サイトを確認しましょう。
 
 

印刷への配慮は殆どされていない?

色々な企業サイトで確認したのですが、印刷時にメニューを印刷しないように
設定している企業は見つかりませんでした。やはり表示しているものをそのまま印刷
する用にした方が良いのかもしれません。私自身も、その方が安心する気がします。
 
以下のサイトは印刷時にサイドメニューは残しますが、上部メインメニューは
印刷されません。これは配慮なのか?と思ったのですが、上部メニューは背景画像を
利用したボタンなので意図せず印刷されないのでしょう。
→参考:プリウス「スペック
 
 

jQueryを利用したサイトこそ印刷への配慮を!

色々なサイトを確認して、jQuery等を利用したリッチコンテンツほど印刷に配慮
しなければいけないような気がしてきました。
jQueryを利用したコンテンツは従来の紙面を意識したデザインの壁を破ることが
できますが、そのことが印刷への未対応につながっています。
 
例えば以下のサイトで「MAP」ページに移動して印刷プレビューしてみてください。
地図は印刷する機会が多いと思いますが、地図が印刷できません…。
→参考:Dining kitchen
※「大きな地図で見る」ボタンをクリックしてgoogleマップに移動すれば印刷できます。
 
 

まとめ

大企業のサイトでも印刷に配慮したページは少ない。これは配慮していないというより
ブラウザの表示のままを印刷するようにしているのかもしれない。
これがデファクトスタンダードなら、メニューやリンクを表示しないなどの配慮は
やり過ぎない方が良いかも。
 
jQueryを利用したリッチコンテンツでも印刷が必要となるページ「地図など」は
きちんと印刷できるように配慮しよう。