リンクをクリップボードにコピー
コピー完了
ソフトVer:IllustratorCS4/CS5/CC(2015)
アートボード上に等間隔に配置した同じ文字が、PDF保存後に文字の位置がずれる現象が発生しています。
(実際の作業・データは別で、私の作業はテストとして行ったものです)
以下の操作で実験しました。
1)アートボード上にテキスト(小塚ゴシック/12pt)で「8」を入力
2)文字を選択後、オブジェクト>変形>移動にて、等間隔(今回は6mm)に23回右側にコピー配置
3)1行分全てを選択、オブジェクト>変形>移動にて、等間隔(今回は6mm)に32回下側にコピー配置
4)文字ずれの確認用に、文字を覆うように大きな長方形を一つ描き、「8」の字のギリギリに配置
5)ファイル>別名保存にて、PDF保存(Illustrator初期設定)
上記作業で作成したPDF上で、「8」の字が下の行になるにつれて左側にずれていく症状が発生しました。
トラブル発生時のデータとフォント・文字並びの数等は異なりますが、大体似たような状態です。
とりあえず症状自体は文字のアウトラインやAdobePDFプリンタでのPDF書き出しで解決はしています。
質問:
・他のPC・バージョン環境でも再現するか
・仕様なのか、不具合なのか
・明確な原因がわかるか
ご回答の程、よろしくお願い致します。
探っていてわかったのは、
おそらく、PDF変換で、オブジェクトツリー上で隣接するテキストオブジェクトをPDF内部表現にひとまとめにする際に、演算の精度が甘く誤差が蓄積されていっているのではないかと思います。間に別のオブジェクトが挟まると、正しい座標にリセットされます。今回の例では、Illustratorで6mm(17.0078125pt)動かしているものが、PDFに変換すると5.9986mm(17.00390625pt)になってしまうようですが、その差0.00390625はすなわち2-8です。
なお、このようなテキストだけをずらーっと並べたデータですが、訂正シールの面付け、表などのフォーマットに文字だけ流し込む際など、私の仕事では発生し易いシチュエーションです。誤差に気付かなかっ
...リンクをクリップボードにコピー
コピー完了
OS X 10.10.5 Yosemite
Illustrator CS6 / CC 2015.3.1
こちらでも再現しました。たしかに(座標位置は同一なのに)ズレます。
[移動]のバグかもしれません。下記のように[移動]を使わないと(等間隔でも)ズレません。
1)(ここは同じ)
2)文字を選択後、optionキーを押しながらヨコにずらして複製。[オブジェクト>変形>変形の繰り返し]を数十回。
3)1行分全てを選択、optionキーを押しながらタテにずらして複製。[オブジェクト>変形>変形の繰り返し]を数十回。
Illustrator初期設定は、「PDF互換ファイルを作成」をONにしたときに.aiに内包されるものと同一です。
ですから、.aiのままで、Acrobatで開いたり、.inddに配置したりしても、ズレを確認できます。
X-1aやX-4で書き出してもズレますね。
リンクをクリップボードにコピー
コピー完了
当方もやってみました。
mm/pt関係するかと思って、横には17ptで、縦には18pt×40でやってました。
テスト環境はWindows 10+CC 2015.3.1で、PDF互換のaiファイルのまま(要はmonokanoさんの仰ることと同じ)、
Acrobat DC continiousで開きました。そのスクリーンショットの一部が下記です。
同じ「8」の、アウトライン化したものを赤に変えて背面に敷いたので、目視でずれがわかります。
一番左にあるn個目は、あとでPhotoshopで書き加えた移動コピーの回数です。
そして、縦方向移動コピーの15回めまでがずれていて、16回目からまた元に戻ってます。
その後再度ずれはじめ、今度は33回目でまた元に戻っているという状態です。
よって一定パターンでループしてずれている、という状況のように見えます。
もちろん、Photoshopでこのaiファイルを直接開いてもずれは出ました。
あと、横方向のコピーをせずに縦方向だけやっただけではずれは出ないようです。
(あくまでも簡単にテストしただけなんですが)
ここまで大量にコピーするケースがどれだけあるか、というのはあるにはありますし、
そのずれがどこまで実データに影響を及ぼすような結果になりうるのか、というのもありますが、
Illustrator内包のPDF Library内で、何かあるんだな、ということで認識しておくしかなさそうな気がします。
リンクをクリップボードにコピー
コピー完了
探っていてわかったのは、
おそらく、PDF変換で、オブジェクトツリー上で隣接するテキストオブジェクトをPDF内部表現にひとまとめにする際に、演算の精度が甘く誤差が蓄積されていっているのではないかと思います。間に別のオブジェクトが挟まると、正しい座標にリセットされます。今回の例では、Illustratorで6mm(17.0078125pt)動かしているものが、PDFに変換すると5.9986mm(17.00390625pt)になってしまうようですが、その差0.00390625はすなわち2-8です。
なお、このようなテキストだけをずらーっと並べたデータですが、訂正シールの面付け、表などのフォーマットに文字だけ流し込む際など、私の仕事では発生し易いシチュエーションです。誤差に気付かなかっただけで、これまでもズレが発生したまま使用していたかもしれません……。
リンクをクリップボードにコピー
コピー完了
monokano様
assause様
noellabo様
様々な環境でのご確認、ありがとうございました。
バージョンや透明に関係なく症状は発生するようですね。
似たようなデータを処理される方がいた場合はフォントのアウトラインを取るよう
ご案内させていただきます。
まとめての御礼で申し訳ありませんが、この返信をもって締めさせていただきます。
リンクをクリップボードにコピー
コピー完了
Adobe Illustrator CC 2017 / macOS Sierra 10.12.6 を使用。
もう回答済みになっているのですがスレッドのばします。
私は表題のような大量にコピペをする場合は効果>変形で作るので、その方法で検証してみましたら、開始位置からしてごそっとズレるという恐ろしい結果が出ました。
MI_SKさんの手順の1)の後、
2)効果>パス>パスの変形で水平方向:6mm/コピー:23 で適用
3)効果>パス>パスの変形で垂直方向:6mm/コピー:32 で適用
4)ファイル>別名保存でPDF保存(Illustrator初期設定)
PDFをAcrobatやプレビューで開くと、8の文字の左上の1文字目からしてごっそりズレます。これは大変だぞ…。
スクリーンショットはスミが移動コピー、マゼンタが移動コピーのアウトライン、シアンが効果の変形です。
アピアランスを分割して単体のテキストオブジェクトにしても同様のズレ方をしたままですが、Illustatorの元データでは移動コピーと同じ位置に揃っています。
大惨事なので引き続き色々試してみます。
リンクをクリップボードにコピー
コピー完了
効果でコピーした場合、オブジェクトの並び順(重なり順)が逆になりますね。
1文字目がズレの激しいヤツで、だんだん正しい位置に戻っていくような流れになってしまうようです。
リンクをクリップボードにコピー
コピー完了
移動コピーの場合、不透明度100%以外ではズレが解消するようです。
再現検証中に偶然発見したので、共有のためレスさせていただきました。
効果コピーでは、不透明度はズレのトリガーにはならないようです。
リンクをクリップボードにコピー
コピー完了
以前より、挙動不審な演算結果に対してワープ効果(カーブ:0%)を追加することで期待通りの結果が得られるというTipsを知人より受けていたのですが、本件についても有効のようです。共有させていただきます。
・複製前のテキストオブジェクトに効果→ワープ を追加。スタイル、方向はどれでも構わないので、3種のパラメータをすべて0%にしました。
複製の繰り返し回数だけてきとうですが、あとはMI_SKさんの示された手順の通りに作成しました。
念のため、このあとワープ効果を削除して別名保存してみましたが、そちらは他の方の検証結果同様にズレていました。
リンクをクリップボードにコピー
コピー完了
リンクをクリップボードにコピー
コピー完了
Adobe PDF Libraryの問題でしょうね。
Adobe PDFプリンタ、Foxit Reader PDF Printer、Microsoft Print to PDF、PS→Distillerでは発生していませんので。
対処法で「フォントのアウトラインを取る」とありましたが、
それよりも「Adobe PDFプリンタでPDFを作成する」の方が
正攻法だと思います。
リンクをクリップボードにコピー
コピー完了
手元で試しましたが、InDesignのテキストがずれてしまう件については、タグ付きPDFで解決できました。
ただし、このような状態のaiファイルではどうやっても難しく、epsに書き出し→InDesignに配置(タグ付きは無関係)がもっとも誤差が少ないように思いました。
リンクをクリップボードにコピー
コピー完了
本件、整理すると、
「まとめる」動作の中で発生するものなので、回避方法としては、いかに「まとめないようにするか」がポイントになるかと思います。
言い換えると、まとめると結果が変わってしまうように仕向ければ良いということになります。
不明なのは、誤差が蓄積したあと、個数なのかズレ幅なのか、ある限度を超えると正常な位置にリセットされる理由です。
ひょっとすると誤差が蓄積するのは作っている人は承知していて(仕様)、大きく破綻しないようにガードがかかっているのかもしれません。
さて、ちょっとだけPDFの内部表現に立ち入ります。
私もよくわかっていないので、眉に唾を付けて(真偽を疑って)お読み下さい。
テキストについて記述されている部分の抜粋です。
BT
(中略)
12 0 0 12 486.185089111 167.639602661 Tm
(\000 \031)Tj
-1.417 0 Td
(\000 \031)Tj
-1.417 0 Td
(\000 \031)Tj
-1.417 0 Td
(中略)
(\000 \031)Tj
-1.417 0 Td
(\000 \031)Tj
34.01599884 1.417 Td
(\000 \031)Tj
-1.417 0 Td
(\000 \031)Tj
(中略)
-1.417 0 Td
(\000 \031)Tj
ET
BT
(以下略)
BTがテキストの始まり、ETがテキストの終わりです。
(\000 \031)Tj というのが「8」です。
-1.417 0 Td というのが座標の指定で、x座標を-1.417、y座標を0 移動せよ、ということです。
12 0 0 12 486.185089111 167.639602661 Tm というのが座標系の定義で、xスケール 12, x傾き 0, y傾き 0, yスケール 12, x座標 486.185089111, y座標 167.639602661 といった具合です。(行列の指定ですが、私には説明できないので省略させていただきます)
追っていくと、テキストがズレ始めてから最大のズレになるまでがBTとETで囲まれていて、また繰り返すところでBTがはじまります。
-1.417 × 12 = -17.004(pt) つまり 5.9986mm 移動しているということで、発生している現象と一致します。
Tmでx座標の指定は小数点以下の桁数が多いのに、なぜTdでの指定は小数点以下の桁数が少ないのでしょうか?
まぁ、これが何の仕様なのかは確かめていませんが、つまりはそういうことのようです。
ということで、「まとめさせない」というのは、内部の話としては、Tdでの移動を許さず、その都度Tmで正しい位置を指定すれば問題ナシ、ということです。