ドロップシャドウ部に段差発生（イラレCC&CC2014）

レポート · Nov 02, 2016

１）現象

・イラストレーターCCもしくはCC2014で開くとドロップシャドウ部に段差発生。

・同じデータをイラストレーターCC2015で開くと問題なし

・ただし、MAC マシン違いでCC&CC2014で段差発生しない現象も出ている。

・開いたMAC OS 10.11.5 　5台試して3台段差発生。

・イラストレーターのCC&CC2014のバージョンは同じ。

２）質問

イラストレーターCCは自動的にダウンバージョンして保存する仕様になっているため

各バージョンでの互換性は問題ないと思っていました。

またバグでしょうか？

何か対処方法を分かる方はアドバイスお願いいたします。

ちなみに、もし作成した

バージョンで必ず開くという昔からのルールを守った方が良いのであれば

自動バージョンダウンする仕様はやめた方が良いと思いますが。

レポート · Nov 02, 2016

まず最初の現象ですが、現象は画面表示としての話でしょうか。

それとも実際に出力したときの結果でしょうか。

それによって確認方法が異なってくる部分がありますから、

どの状態で段差が出るのかを確認されるのが望ましいです。

またIllustrator CC（Ver.17）以降、現状のCC 2015.3まで、

データ形式はすべて「Illustrator CC」となっているので、

バージョンダウンしての保存というわけではありません。

ただ、上位バージョンのデータを下位バージョンで開いた場合に

編集上の問題が生じる場合があるのは事実です。

ですので、基本的にはBridge等でバージョン確認を行ったうえで、

保存されたバージョンで編集作業を行うのがベターだと思います。

レポート · Nov 04, 2016

お返事遅れて大変申し訳ありません。

現象としては画面表示も出力も同じです。

イラストレーターCC2014以下で開くと発生します。

ただ、OS環境やバージョンなど同じなのに

CC2014以下で開いて問題ない人と問題ある人両者が存在します。

詳細PDFを添付いたします。

レポート · Nov 04, 2016

画像で送ります。

レポート · Nov 05, 2016

同じファイルで結果が異なり、出力にも影響するというのが少々気になるところです。

CC 2014以下であればGPUパフォーマンスにも無関係なはずですし、

出力としてもそこに影響する点はないためです。

できれば他の環境でもそのデータの結果を確認してみたいところではありますが、

まずは下記についてチェックしてみてはどうでしょうか。

発生する機体としない機体の環境差（Macのモデル、CPUやGPUなどのハードウェア差）
ドキュメントのラスタライズ効果設定の確認　※本来はドキュメント依存なはずですが念のため
プリンタードライバーのバージョンとPS対応の可否
透明を保持するPDFとして保存してAcrobatで見たときにどうなるか

なお、常に最新バージョンで作業すればベターというわけでもないところなので、

必要に応じての使い分けは出てくると思います。

（CC 2015.xでも不具合はありますし、CC 2017でも不具合らしき報告が上がりつつあります）

レポート · Nov 02, 2016

CC2015.3ですが画面表示だけのことであればGPUの設定で表示が変わる経験はあります。

GPUオン

GPUオフ

画像をクリックかダウンロードして等倍以上で見てください。

--
Susumu Iwasaki

レポート · Nov 04, 2016

CC2015では現象は出なくて CC2014以下で出ます。

OS環境やバージョンも同じなのに、社内で出る人と出ない人がいます。

常に最新バージョンで作業した方が良いのでしょうか？

現象の画像は先ほどUPさせていただきました。

レポート · Nov 06, 2016

Illustrator CC以降のファイルフォーマットについてですが、CC(v17)、CC 2014(v18)、CC 2015(v19)、CC 2015.3(v20)、CC 2017(v21)で統一されていて、CC 2017で作成したドキュメントがCCで開けるように設計されているようです（v17.1, v18.1, v19.2は割愛）。大きく4バージョンをまたいで方針が継承されてきていますので、それなりの互換性ポリシーを設計・検討した成果で、引き続きコミットされていくのではないかと思います。いずれどこかで刷新するような気もしますし、そうしてくれないとどんどん肥大化していってしまいますが、まだしばらくは行けそうですね……。

具体的には、差異のある部分だけに絞り、本質的に大事な情報と、再現できないなら無視して良い情報を区別するように工夫していることがうかがえます。どうしても同じように記述できない場合は、バージョン毎に複数の記述をして選択させるようになっています（ダイナミックシンボルなど）。

こちらは、バージョン判別して、どちらのコンテンツを読ませるか選択させる構文です。

%AI17_Begin_Content_if_version_gt:17 1

...（新しいバージョン用の記述）

%AI17_Alternate_Content

...（古いバージョン用の記述）

%AI17_End_Versioned_Content

こちらは、矩形の定義がバージョン毎にどう異なっているかの例です。

CCの場合

（アンカーポイントを並べた、閉じたパスとして記述。本質の部分）

320.173228346457 -410.173228346457 m

291.826771653543 -410.173228346457 L

291.826771653543 -381.826771653543 L

320.173228346457 -381.826771653543 L

320.173228346457 -410.173228346457 L

b

CC 2014の場合

（ライブシェイプのコーナーの情報、時計回りだとか回転角度、縦横サイズなどを付加）

320.173228346457 -410.173228346457 m
291.826771653543 -410.173228346457 L
291.826771653543 -381.826771653543 L
320.173228346457 -381.826771653543 L
320.173228346457 -410.173228346457 L
b
%_/ArtDictionary :
%_/Dictionary :
%_/Dictionary :
%_0 /Real (ai::Rectangle::CornerRadius::3) ,
%_(Invalid) /UnicodeString (ai::Rectangle::RoundingType::3) ,
%_(Invalid) /UnicodeString (ai::Rectangle::CornerType::3) ,
%_0 /Real (ai::Rectangle::CornerRadius::2) ,
%_(Invalid) /UnicodeString (ai::Rectangle::RoundingType::2) ,
%_(Invalid) /UnicodeString (ai::Rectangle::CornerType::2) ,
%_0 /Real (ai::Rectangle::CornerRadius::1) ,
%_(Invalid) /UnicodeString (ai::Rectangle::RoundingType::1) ,
%_(Invalid) /UnicodeString (ai::Rectangle::CornerType::1) ,
%_0 /Real (ai::Rectangle::CornerRadius::0) ,
%_(Invalid) /UnicodeString (ai::Rectangle::RoundingType::0) ,
%_1 /Bool (ai::Rectangle::Clockwise) ,
%_0 /Real (ai::Rectangle::Angle) ,
%_(Invalid) /UnicodeString (ai::Rectangle::CornerType::0) ,
%_3 /Int (ai::Rectangle::InitialQuadrant) ,
%_28.3464566929142 /Real (ai::Rectangle::Height) ,
%_28.3464566929142 /Real (ai::Rectangle::Width) ,
%_; (ai::LiveShape::Params) ,
%_(ai::Rectangle) /UnicodeString (ai::LiveShape::HandlerName) ,
%_; (ai::LiveShape) ,
%_;
%_

CC 2015.3 の場合

（順番が違うが内容はほぼ一緒。ai::Rectangle::CenterXとai::Rectangle::CenterYを追加）

311.813228346457 -435.118228346457 m
283.466771653543 -435.118228346457 L
283.466771653543 -406.771771653543 L
311.813228346457 -406.771771653543 L
311.813228346457 -435.118228346457 L
b
%_/ArtDictionary :
%_/Dictionary :
%_(ai::Rectangle) /UnicodeString (ai::LiveShape::HandlerName) ,
%_/Dictionary :
%_8191.5 /Real (ai::Rectangle::CenterX) ,
%_1 /Bool (ai::Rectangle::Clockwise) ,
%_0 /Real (ai::Rectangle::CornerRadius::1) ,
%_(Invalid) /UnicodeString (ai::Rectangle::CornerType::1) ,
%_(Invalid) /UnicodeString (ai::Rectangle::CornerType::0) ,
%_(Invalid) /UnicodeString (ai::Rectangle::RoundingType::1) ,
%_9033.39 /Real (ai::Rectangle::CenterY) ,
%_(Invalid) /UnicodeString (ai::Rectangle::RoundingType::0) ,
%_(Invalid) /UnicodeString (ai::Rectangle::RoundingType::2) ,
%_28.3464566929142 /Real (ai::Rectangle::Width) ,
%_28.3464566929142 /Real (ai::Rectangle::Height) ,
%_(Invalid) /UnicodeString (ai::Rectangle::CornerType::2) ,
%_0 /Real (ai::Rectangle::Angle) ,
%_0 /Real (ai::Rectangle::CornerRadius::2) ,
%_3 /Int (ai::Rectangle::InitialQuadrant) ,
%_(Invalid) /UnicodeString (ai::Rectangle::CornerType::3) ,
%_(Invalid) /UnicodeString (ai::Rectangle::RoundingType::3) ,
%_0 /Real (ai::Rectangle::CornerRadius::3) ,
%_0 /Real (ai::Rectangle::CornerRadius::0) ,
%_; (ai::LiveShape::Params) ,
%_; (ai::LiveShape) ,
%_;
%_

通常は圧縮しているとはいえ、ちと冗長ですねぇ……。

レポート · Nov 06, 2016

さて、今回の現象ですが、観察しているだけでは原因がわかりにくいので、問題の発生する実データを解析した方が良いでしょう。

画像で見せて頂いた範囲の再現できるAIデータ（不要部分は差し支えあるかと思いますので削除してください）をアップロードしていただければ、少し紐解いてみますので、書き出したCC2015に問題があるのか、読み取る側の環境等による要因なのか、何か手がかりが得られると思います。

レポート · Nov 08, 2016

http://dtbn.jp/29B5DZP

データは上記URLからダウンロードしていただけますでしょうか？

(容量の重たいイラストレーターのUPの仕方がわからないため。すみません。)

自分で検証してわかった範囲で報告いたします。

１）メモリ6GBのMACで開くとCC2015でも段差発生（5台試して全部発生）

　　※ただしCC2015は1回少しデータをずらしコマンドZで戻すと段差発生

２）メモリ4GBと8GBのMACではCC2014で現象発生しないし、CC2015で一旦ずらしてコマンドZでも発生しない

３）１）で発生した段差現象を消す方法は

　　　　データはドキュメントのラスタライズ効果設定350に対して300とか400にすると一時的に消えます

　　　　ただし350に戻すと段差復活します

以上がこちらで、わかった情報です。

みなさん検証のご協力をお願いいたします。

レポート · Nov 08, 2016

何が起きているか、だいたい様子がわかりました。

ドロップシャドウの内部で使われているPhotoshop効果の「ぼかし（ガウス）」で発生する問題
ある発動条件により、内部的に一定の高さの帯状に分割して「ぼかし（ガウス）」が適用される
- パフォーマンス向上（メモリ節約）のために分割していると思われるので、発動条件はメモリか？（未確認）
- 分割して「ぼかし（ガウス）」を適用する内部処理に問題があり、境目が生じる
  - 問題は、「ぼかし（ガウス）」を逐次実行してしまうアルゴリズムの誤り。最初のぼかし処理のあと、次のぼかしを実行する際に、最初のぼかし結果の一部を利用してしまうため結果がおかしくなる（Photoshopによる再現で同一の結果を確認）
  - 正しい結果を得るには、ぼかしを別々に実行し、あとから合成する
- ドキュメントのラスタライズ効果設定にて解像度を変えると、分割位置が変わるため、分割されなくなって問題が発生しなくなったのか、おかしくなる位置が変わっただけなのかは、よく見極める必要あり。

ということで、バグ（アルゴリズムの誤り）の存在は確認できました。

発動条件はもう少し調べてみる必要がありそうです。

さて、これはどうやって回避しましょうかね……。