Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2014年10月15日

reika masumitsu

FlashCCからHTML5 Canvas書き出しの際の画像ファイル形式変換の謎

こんにちは。ソーシャルゲーム1部開発課 Hチームのマスミツです。
長いタイトルですみません。初めての投稿です(ドキドキ)
FlashCCで制作したアニメーションをHTML5 Canvasに書き出した際に起こった、 「png画像がjpgに勝手に変換されてしまう」世にも恐ろしい(大げさ)怪現象に遭遇したのでご紹介します。

HTML5 Canvasとは?

Canvasとは、JavaScriptを使って動的に図を描くために策定された仕様です。 Flash CCから、制作したアニメーションをこの[HTML5 Canvas ドキュメント]に書き出すことが可能になりました。
これにより、ブラウザのプラグインの有無に関わらず再生できるアニメーションを簡単に作れるように!

書き出されるファイル

ドキュメント形式を「HTML5 Canvas」で新規作成、あるいは「ドキュメント形式をAS3からHTML5 Canvasに変換」にて制作し、パブリッシュを行うと下記のファイルが書き出されます。

  • HTML
  • JavaScript
  • imagesフォルダ(の中に使用するimg)

imagesフォルダでおこった怪現象

このパブリッシュですが特に難しい操作がなく、Flash氏がいいようにしてくれるので、 書き出されたHTMLを開けばブラウザだけでちゃんとアニメーションが再生されます。 何もしなくてJSもできてるし・・・ナニコレ便利!!
で、できたJSを見てみますと。画像の記述のところがこのようになっています。

ここまできて・・んん?なんでjpg入ってるの?全部pngのはず・・・(((( ;゚д゚)))

とりあえずJSと同時にFlashから書き出されたimgesフォルダの画像を見てみると、こちらも一部の画像がjpgになっています。

まあそうですよね。だからちゃんと再生されるんですけど。

まったく原因がわからないので、制作したFlashのライブラリを再度見てみてると、こちらは確かにすべてpngです。
画像をシンボル化したものとそうでないもので関係あるのかとか、そもそも元画像が壊れてるのかとか、いろいろと疑ってみたのですが特にそういうわけでもなく・・・詰みました。

調査結果

そして、答えはここにありました。
参考サイト:http://www.adobe.com/jp/devnet/createjs/articles/using-flash-pro-toolkit-createjs.html


画像も、JPGフォーマットまたはPNG32フォーマットでライブラリから書き出されます。画像に透過が含まれるか、ユーザーが圧縮タイプをlosslessに設定してある(オリジナルソースがJPGではない)場合を除き、Toolkit for CreateJSは、JPGを使用します。このToolkitは、JPG出力される各画像に対して、「properties(プロパティ)」ダイアログボックスに指定された品質設定を使用します。


簡単にまとめると、

  1. 画像は、jpgまたはpng32フォーマットでライブラリから書き出される
  2. 透過が含まれる画像・圧縮タイプをlosslessに設定している画像(※且つ元画像がpng)はpngで書き出される
  3. それ以外はjpg

つまり、透過画像はそのままやってくれるけど、背景など透過してない画像は何も設定していないと勝手に圧縮しちゃうってこと!!?画質とかどうなんのよ! ・・はい、そうです。ひどい話です。完全におこです。

回避方法

ということで、

デフォルトでは透過が含まれない画像はjpgに圧縮して出力されてしまうので、回避する場合は「圧縮タイプをlosslessに設定する必要がある」てことですね。 こんな簡単なことでした
bitmap
各画像のビットマッププロパティにて「圧縮タイプ:劣化なし(PNG/GIF)」を選択する
※透過が含まれる画像は自動でpng書き出しされるため必要なし

その他気づいたこと

Flash上でのライブラリは、libネームスペース内の再使用可能なクラスとしてJavaScriptファイルにパブリッシュされます(アニメーションに使用している画像はライブラリでのアイテム名を使用してJavaScript上で処理される)。

「ライブラリでのアイテム名を使用」するので、これに気づかず画像名をちゃんと決めないままで気にせずライブラリに突っ込んで使っていると、JSにその名前で書き出されてしまいました。

上に晒しましたソースを見てみると、ファイル名テキトーすぎる…ハズカシ…しかもよく見ると全角とか入っちゃってるしorz
JSに使うのでそりゃエラーにもなるってもんです。

ライブラリ内のアイテムはパブリッシュ時にそのまま書き出されてしまうので、半角英数を使用してください。全角や日本語を使用するとJS上でのエラーの原因になる場合があります。全角は悪!ダメ、ゼッタイ。

まとめ

ほかにもFlashCCからのHTML5 Canvasにおいてはいろいろとありましたが、ネット上でもなかなか情報を探せなかった この問題が一番謎だったので記事にしてみました。最後まで読んでいただき、ありがとうございました!


2014年02月13日

いしはら

最新版のChromeでtouch eventを有効にする方法

こんにちは。いしはらです。

久々にChrome DevToolのtouch eventを有効にしようと思い、設定画面を開いたところ、「Emulate touch events」の設定が見当たらず 設定に時間がかかってしまいました。

最新版のChromeでは下記の手順になるので 設定してみてください。

 
1.Setting1アイコンをクリック
 
2.Overridesの「Show’Emulation’view in console drawer」にチェックを入れる 2
 
3.Show console3アイコンをクリック
 
4.Emulationタブをクリックし、サイドメニューの「Sensors」を選択 「Emulate touch screen」にチェック 4
 
これで完了です。 カーソルが灰色の丸になっているとtouch eventが有効になっています 5
Chrome DevToolを非表示にしていると設定は無効になるのでご注意を。


2013年11月21日

社内行事でのHTML講習会資料の共有

こんにちは。竹島です。
先日、フリュー2014年度新卒社員さんの「就業体験」というイベントがありました。 来年入社する学生の方々が、フリューの仕事を体験してみる、といった内容なのですが、
その中で行われた、WEBページ製作が初めての方向けの、HTML講習会を担当させていただきました。
その際作成した資料を共有したいと思います。    

Html講習会資料 from 竹島 泉

  

かなり基礎的な内容になっていますので、これからWEB製作をはじめてみたい学生さんなど、ぜひ参考にしていただければと思います。


2013年11月13日

ブログリニューアルしました

はじめまして。
ソフトウェア開発部の竹島です。
HTMLやCSSでのWEBページ開発などを中心に行っています。
今回、本フリューTechBlogのリニューアルをさせていただきました!
フリューの「明るく楽しい雰囲気」に合わせてデザインをしてみました。 そしてできるだけ読みやすいようにいたしました。
個人的に、記事名横の丸アイコンと吹き出しが気に入っています。
 
このブログはWordPressを利用しているのですが、わたくし今回が初めてでした! はじめてWordPressのテーマ作成をしましたが、 とても楽しかったです。
 
「PHPベースだしプログラムの知識がなければ難しいんじゃないか…?」
 
と思っていましたが、やってみたらそんなに難しいものじゃなく、 Google検索すればやりたいことを親切に教えてくれているサイトがたくさん出て くるので、 WordPressの知識がなかった私でもいい感じに製作することができました! (一定期間たったらまたリニューアルしたい、と密かに考えています。。)
 
テーマ作成に参考にさせて頂いたサイト↓↓

技術のお話ができなくて申し訳ありませんが、、
WordPressカスタム楽しい!というお話と、 リニューアルのご報告でした。


2013年02月20日

オブジェクト指向CSSのススメ

便利なオブジェクト指向CSSの紹介をします。

オブジェクト指向CSS(OOCSSとは?)

オブジェクト指向のCSS、、、つまり、CSS側でスタイルを細かく分けて、HTML上で組み合わせてデザインしていく最近見直されてきたCSSの書き方です。
主にCSSテンプレート制作に利用出来ます。
まずは例を見てみましょう。

例) 文字を小さく、かつ右寄せにしたい

こんな風にclassを組み合わせるだけで、文字組等出来る様になります。

例) ul.table_list.col2>li*8>aとか使ってみた場合

flexible boxを使ったマルチカラムや、テーブル状のリストを作るスタイルを予め用意すれば、かなりの物を作れます。

img1

いくつかのスタイルは省略されてますが、基本的にこんな感じです。
記述するのは基本的なレイアウトのみで、個別のデザインはid/classを追記し、個別のスタイルを当てていくと見やすくなります。

メリット

HTMLだけでUIの作り方を制作する人に指示できる事です。
HTMLの基本しか知らない人でも、組み合わせ次第でいろんなUIが実現出来ます。

img2

こんな感じで簡単な取扱説明書を作れば、使い方を簡単にメンバーへ伝える事が出来ます。
見る側も、CSSと見比べっ子しながら作らないで良いので楽ですね!

デメリット

とまぁメリットだらけに見えるOOCSSには大きなデメリットが2個もあります。

  1. メンテナンス性が悪くなります。
    例えば、通常、liを追加するだけで済む所が、一杯classを追記しなくてはいけなくなったりします。
    特にCSSに精通している人にとっては邪魔になる事の方が多いです。
  2. セマンティックで無いクラスの濫用はそもそもダメ。
    要するに、クラス名に内容と直接関係ない名前(例. col2)は付けてはいけないという話です。
    国内では対応状況は悪いですが、そのうち標準になるでしょう。

①はよく更新する部分は楽に更新出来る様に別途CSSを組めば大丈夫です。
ただ、マニュアルはその分多くなります。
②はidを付けて管理したり、別途セマンティックなクラスを付ける事でそれらしくする事は出来ます。
ただ完璧では無いです。

まとめ

OOCSSは、

  1. ○ CSSがよくわからない人でもHTMLの基礎さえ知っていれば複雑なレイアウトを組める
  2. ○ テンプレートの解説が容易
  3. ☓ メンテナンスが複雑
  4. ☓ セマンティックでは無い

という事になります。
HTML+CSS専門家と実際に運用する人のスキルレベルに差がある場合は有用かと思います。

続きます

まだここから先があります。
OOCSSの弱点を潰しつつ、オブジェクト指向で簡単にサイトがレイアウト出来る…
その名もOOSCSSを次回は(いずれ)紹介したいと思います。