今さらAnimate覚えたっていいじゃない：その3 アクション

前回は気軽なコピペ結果が場外ホームランで嗚咽でした。
また経典に沿って、今回はアクション（スクリプト）を書いていきます。
これActionScript3かと思ってたら違って、JavaScriptなんですって。
時代についていけてなかった。

Actionsを設定

…の前に、キーフレーム作成するんだったね。
え、8フレームめ？（アオリ検版開始）
自分の失敗ファイルはサウンドの終わりが18フレームめ。

フレームレート30.00で作ちゃてた。経典は12.00だ。

というわけでメニュー項目をしらみつぶしに眺めてー
修正 > ドキュメント
の「ドキュメント設定」で変更できました。
ふつうにプロパティからでもできた。

これでヘンな影響が、出なければいいな。
…出たな。

ここはレイヤーごとに余分なフレームを選択して削除（shift+F5）だけでどうにか。
実はこの時点でもう間違えてる。どこでしょう。

答えはアクションの挿入フレーム。「a」マーク。
2フレームめではなく1フレームめが正解。勇み足で書き込んだ this.stop(); をカット＆ペーストで対処。

シーンのActionsを設定する

ええと。
ステージのウィンドウ左上から「←」をクリック

…して、シンボル編集を抜けました。
経典にないレイヤー「gep」は自分の失敗ファイルのもの。
のちのち消します。

ここからちょっと長いスクリプトを書くんだけど、どこに書くんだろ。
たぶ、たぶん鼻のフレームよね。鼻しかさわらないんだし。※1
よし。さて写経。

にしてもこのアクションウィンドウ内、非常に書きにくいづらい。
VSCodeで書いてペーストしよう。
ゎぁぃ copilotがこっちの思考を先回りしてお節介に「次これ書くんじゃろ？」してくれるよ。
いらーん。

というわけでまじめに写経したのでアクションパネルにペースト。
経典では音声ファイルは belchwav.mp3 だけど自分の失敗ファイルでは belch.wav なので
対応して引数の文字列を belch にしておいた。※2

プレビューとパプリッシュ

んじゃでは、どっきどきのムービープレビュー。Macなので ⌘ + return。
はい失敗
延々くちをぱくぱく。しかも無音。

原因：前述の「のちのち消します」としておいたgepレイヤーが残ってましたわ…

gepレイヤーを削除して再ちゃれ。
失敗。いくらクリックしても無反応。鼻が痛くなっちゃうよ。
あれ、わかんね。
経典のコードと差分とってみたけど問題なさそう（対策→攻撃 は素で間違えたけどコメントなのでおっけー）。

あ、はい、すいません…
原因：インスタンス名「nose」が未入力でした。

気を取り直して再々ちゃれ。
鼻クリック。クチひらいた！　ゲップした！　クチとじない！
自分も猫も、開いた口が塞がらない（言うと思ったと言うと思った）。

経典を先頭から見直したら、※1 先述の疑問点が氷解。
原因：アクション記述先を間違えてた（やっぱり！ やっぱり！）。

再々々ちゃれ。
改善なし。
動きはするが元位置にこないということは、たぶん、あれのあれがなんかあれなんだろ。←わかってない
わ、わかんないけどコメントの「攻撃」は「対策」に直しておこう
い、いちおう案外それだけで直るか試しておこう（だめでした）。

冷静に。
サウンド再生が終わったら1フレームめに戻る設計。それでクチが閉じる。
しかし閉じない。つまり1フレームめに飛んでない。つまりサウンドが正常に再生終了していない。
つまり…なんだ、あれがあれなんだろう。
冷静にプレビューしてみるとゲプ音が半分ぐらいに短い。切れている。っぽい。
これ、直感ではフレームレートを変更した影響かも。そんな気してた。

しかし自力では限界が見えたので先生に助けを求めよう。
素直に最初から作り直せよ、と思うものの、ここでの目標は作品の完成よりもアプリの理解なので…

助けを求めた。現状データを見ていただいた。
※2 のアレンジがよくなかったみたい。ワハー。
ライブラリには音声ファイル「belch.wav」しか読み込んでいないのでそうしたんだけど、
どうもパブリッシュの際、かってにmp3に変換しちゃうらしくて、そしたらファイル名が「belchwav.mp3」になってしまうみたい。
つまり、あらかじめmp3を用意しておくのが得策みたい。
ともかく、理屈を理解しつつ挙動も改善したのでばんざい。

それに前後して
「Flash時代の癖でタイムラインを伸ばしたが、どうも不要なようだ」と別の改善点を授かったので反映。
symbolActionsレイヤーの最終フレームに記述したアクション「this.gotoAndStop(“idle”);」も削除で。
これだけで動いたみたい。うん動いた。ありがとうございます！

というわけで、InDesignで作ったやつよりサクサクとゲプゲプするやつ、どうぞどうぞ。
（先生記事にあるやつと何も変わらないのだが）

次回、また権利的に微妙なやつでアニメーションの練習をします。
先生を楽しくさせるお題、というとこだけは自信あるw

透明効果とオーバープリントは仲が悪いぞ　の余録

先日の入稿データ謎トラブルについて、京都のおせんべいやさんこと元・SCREEN 出力の手引きWebの中の人、松久さんから大変ありがたいコメントをいただけました。
自分の読解力の乏しさから聞き返してしまい、そのたび溢れ出るエモい情報整理。

こうなったら何度も聞き返して至福を味わい続けちゃおう…などとは思いもしなかったわりに、結果そうなってしまいまして。めんもくない。
自分だけ読むのはあまりにももったいないので、一連のやりとり掲載のご許可をいただきました。
本業のお忙しい中、本当にありがとうございますすぎます。

自動黒オーバープリントは、画面で確認したデータをRIP内部で書き換える処理であり、原理的に「画面通りに出ない」リスクを高めます。正しく黒オーバープリントが指定されているデータの場合は余計な処理であり、一方的に「受け手側の都合」とは言い切れません（この点を先方に理解してもらえれば、そう説明できます）。

また、「PDF/X-1aだから安全」とは一概に言えないため、その前提自体を確認すべきです。

・PDF/X-1a
透明効果はDTPアプリ側で分割・統合（1）され、見かけ上は透明でも、実体は透明でないデータになります。この段階での透明の振る舞いにはRIPは関与していません。

・PDF/X-4
透明効果の合成はRIP内部の演算処理（2）によって行われます。
一般的に、RIPでの自動オーバープリント処理は、DTPアプリ（1）が出力したPDFと、RIPでの透明合成演算（2）の間で行われます。そのため、期待通りの結果になるかどうかはケースバイケースです。

具体的には、透明効果の種類によっても結果は変わり、自動オーバープリントは各RIPベンダー実装に依存するため、処理も異なります。今回の「比較（明）」では問題なさそうに見えても、他の透明効果が絡むと万能ではありません。従って、「PDF/X-1aで書き出していれば自動オーバープリントは問題ない」と断言することはできません。
はじめの一節、すこし表現が逆転している観があるので確認させてください。

「受け手」が印刷会社、対して制作主が「送り手」の場合、
「一方的に『受け手側の都合』とは言い切れません」
は、むしろオーバープリント処理に無頓着な送り手に向けた意見なのでは、と思います。
「そっちの都合でしょ」と言うのは、作り手=制作者ですよね。つまり、印刷会社の都合で自動オーバープリントを行っているわけですよね？
もうこれは、製作者と出力側の力関係かも知れませんが、印刷会社目線では以下のことが言えます。

黒オーバープリントを、正しくデータで指定されている、という共通認識が基本的にない、とした場合、自動オーバープリントは、墨ノセが行われない問題、墨オブジェクトがヌキになる問題の回避策です。
これは、比較（明）で発生しうる問題より、はるかに頻度が高いので、仕方なく、自動オーバープリントを行っている、と言えます。
つまり、「データの不備」を助けているのて、この観点から言うと、むしろ制作者の都合とも言えます。

ただし、「そっちの都合でしょ」って言ってしまうような制作者に、「いやいや、データが悪いから仕方なくやってるんですよ」なんて言っても、険悪になるだけで、理解は得られそうにありません。
従って「理解してもらえれば」の前提が付いてしまうんです。

RIPベンダーの立場で、これを、制作側にも出力側にも、訴えることで、黒オーバープリントは正しくデータで指定されている事、つまりノセイキ運用が、技術的には理想解と示してきたわけです。
これなら、墨ノセと比較（明）が両立できます。
当方の懸念点「『そっちの都合でしょ』と言われかねない」は、そもそもオーバープリント管理がされていないデータの制作主に言われた場合、認識の改善と理解を期待して説明する機会が生まれる、ということですね。
ようやく不安を持たず先方に展開できる自信がつきました！ ありがとうございますっ

といったところです。
松久さんとっくに退役されているのにどっぷり頼ってしまい。
しかも弊社EQUIOSじゃなくてApogeeなのに…非常に申し訳ないですw　ものすごく助かりました。
松久さん、今でも出力サイドにいる自分にとって希望の星です。どっぷり甘えてご面倒おかけしました。
よい子のみんなは真似しないでね！（うちはまたやりたい…がまん）

今さらAnimate覚えたっていいじゃない：その2　座標系

前回は「ブラシで猫の鼻が描けねえ」でつまずき、
転んでもタダでは起きないんだわよ、とブラシモードの理解を深めました。

経典に沿って次に進みます。

くち画像を配置

で、またつまずきました。はっや。
こんなの、ライブラリからポイするだけだろー、とお思いでしょうよ。
自分でもそうお思いだったよ。
今回、惜しくも満足に動作しなかった自作のファイルをベースにしていて、
極力それを活かそう（ほとんど無理なんだけど）としていたのでした。

あれっすよ、昭和の仮面ライダーでよくあった、あの
「ついにライダーを引っ捕らえました。いつでも処刑できます」
「まあ待て、すぐに頃してしまってはつまらない、時間をかけて愉しむとしよう」
と同じきもち。
あれって100％処刑失敗してるよね…うちも失敗したかったのかもしれないね。

経典ではここで初めてクチを配置してたんだけど、
手元には既にばっちりの位置に配置したクチがあったのです。
スクショの赤で示した箇所、次のテストに出るので覚えておくように。

これをコピーして、鼻シンボルの内部に「同じ位置にペースト」したら、
ぎゃあ。たしかに座標値は同じだけど、ぎゃあ。

これはつまり、座標値の基準点がステージだったものをコピーして
シンボル内パーツとしてペーストしたら、シンボルの基準点座標が基準点になっちゃったよ、
ということ。

なので、親の鼻シンボルの座標値を覚えてクチの座標値にマイナスしてやることで
元の位置に配置することができました。
（ほんとはそれでもちょっぴりズレてる気がして少し手で調整しました）
…だったら最初から新規配置すればよかったよ。
まあ、勉強勉強。経験経験。

フレームの挿入、サウンドの設定は問題ないちゃんでした。
自分でやったときは、なんかてきとうにサウンドをステージにポイしてました。
フレームが適切に選択できていれば、それでもいいっぽい。

次回、いよいよスクリプトをごちょごちょ書くとこです。めんどそー。