InD-Board

PDF/X-1a形式の見開きで / KT

見開きPDF/X-1aの作成でおかしなことがあったため、報告を。
DTP Transit（2012年1月30日）には関連するような記事がありましたが、こちらでは同様な事例が検索できなかったので。

InDesign CS5.5 Ver7.5.2　MacOSX10.6.8で作成した10ドキュメント計400ページになる書籍で、章ごとに作成した複数のドキュメントをブックに登録し、見開きでPDF/X-1a形式（InDesignのプリセット「PDF/x-1a:2001（日本）」を使用して、「見開き印刷」のみをチェック）で書き出しました（著者用の校正紙だと見開きが好まれるので、見開き状態でPSプリンタから出力するため）。

そのPDFを確認したところ、ある章の各ページの小口側の天にある章柱（各ドキュメントのマスターページ：全てのドキュメントで同一の名前「A-マスター」に配置してあるフレームグリッドに手入力。フレームグリッドは裁ち落とし部分にかかっていない）が、ブックの並びのそのドキュメントのひとつ前にあるドキュメントの柱に入れ替わっていました。
上記の説明ではわかりにくいので簡単に言うと、例えば３章に相当するページに２章の柱が入っている、ということです。
章の全てのページで起こっている場合や、章の最初の数見開きで起こっているなど、発生の規則性はないようです。
また、本文のストーリーや図版等のオブジェクトなどは正しく作成されており、マスターページの章柱の小口側に配置したノンブル（自動ページ番号）なども正しく作成されています。
この各ドキュメント単体で見開きPDFを作成すれば、章柱は正しく作成されます。

同じドキュメントでブックを作り直したり、ドキュメントを「複製を保存」してブックを作り直したり、IDMLで書き出してドキュメントを作り直してブックを作り直したりしてみましたが、再現しました。
ところが、手持ちの同じような作り方をしている他の書籍のブックでは、こうしたおかしなPDFは作成されません。

いろいろ試したところ、このドキュメントでは、PDF/X-1a形式・見開きにしなければ、柱が入れ替わることはないようです。この現象が起きたドキュメントやブックは、見開きPDFで印刷工程に回さないため実害はないと思いますが、どのような法則でこうしたことが起こるのかが不明なので、なんとなく不気味です。
先にあったCS5.5のPDFの裁ち落としバグに関連した問題でしょうか？
ちなみにAdobeのサポートにはこうした事例があったと相談・報告済みです（データがほしいと言われましたが、当然ながら出版物なので渡しませんでした）。

No.6634 2012/03/19(Mon) 18:01:52
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11

Re: PDF/X-1a形式の見開きで / 流星光輝

うちでは、InDesign2.0.2の頃に使ってましたが、
CS(3.0.1)の時に不具合が起きたので、
それ以来、信頼しなくなりました。
なので、ゲラ出力や製版出力用データの作成に
InDesignのBook機能は不具合が多いので、使わないことにしています。

No.6642 2012/03/22(Thu) 12:28:19
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11

続・フレーム調整オプションの挙動について / （z-）

過去ログでオメガさんが提言された、フレーム調整オプションのバージョンごとの挙動の違いについてのスレッドがありますが
http://www2.rocketbbs.com/11/bbs.cgi?id=thats&mode=pickup&no=6236

それに関連した内容で質問です。
上記から派生した作業手順で、CS4で詰まりました。
回避策があれば教えてくださると助かります。
※添付画像参照お願いします。

・画像を配置、コピーしておく
・画像の前面に新規グラフィックフレームを2個作成（フレームA、Bとする）
　　フレームBだけ「フレーム調整オプション」を開き、何もせずOKして閉じる
・それぞれ選択し「選択範囲内へペースト」
・フレームA内には、コピー元と同じ座標にペーストされる
・フレームBには、フレーム調整オプションの内容に応じた位置にペーストされる
　（何もせずOKした場合、デフォルトの左上基準）
---------------
手順ここまで

フレームB内に、フレームA同様、コピー元の座標をキープして画像を配置するには
CS3…コピー元画像を親フレームごとコピーし、入れ子にする。
　　　入れ子が気にくわない場合はコピー先から画像のみコピーし直し、
　　　フレームBを選択して再度「選択範囲内へペースト」
CS5…「フレーム調整オプションを消去」してから「選択範囲内へペースト」

…で、どうにかなりそうなのですが、
CS4の場合はいずれの方法もダメでした。
　どうしたらよいでしょうか。。

フレームA、Bのプロパティを比較してみましたが、とくに決定的な差異はありませんでした。
frameFittingOptionsなどは完全一致です。
最悪の場合スクリプトでペースト後に移動などになりそうですが、
　回避案があれば教えてください。お願いします

No.6598 2012/03/08(Thu) 12:45:16
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; ja-jp) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1

Re: 続・フレーム調整オプションの挙動について / オメガ

過去ログでは、以前の配置画像のトリミング量が残ってしまうのが問題で、それに関してはスクリプトでトリミング量をリセットすることで自己解決しました。（オブジェクトスタイルを適用する方法もあります）
いずれにせよ、CS5以降ではショートカット等でオブジェクトサイズの調整をするとフレーム調整オプションにも反映されてしまうなど、フレーム調整オプションの挙動が柔軟過ぎてかえって不便になりました。（あくまで主観です）
画像まわりの挙動がバージョン毎で一定しないのは実務に直結するだけに困りものですね。

前回と今回の件で共通して言えることは、
『作成時のフレーム≠フレーム調整オプションを何も変えずにOKしたフレーム』　という点ですね。
フレーム調整オプションを表示・設定すると（ウィルスにでも感染したかのように）以後の挙動が変わってしまい、元に戻す方法がない、と。
CS5以降は「フレーム調整オプションを消去」が追加されて、一応（全ての設定値を抹消する副作用付きで）戻せるようになりましたが、CS4にはないですね。
何とか別な方法で出来るといいのですが、ちょっと思い当たりませんでした。

有効な解決策ではないかもしれませんが、選択範囲内でペーストを使わずに、画像をコピーし元の位置にペーストor同位置に複製して手動で変形するのが無難な方法です。でもフレームBが星形などの複雑な形状だと不可能ですね。
ちょっと手数が増えますが、もう少し良い解決方法は、
　1.画像（or画像フレーム）をコピーし、元の位置にペーストor同位置に複製します（画像Bとします）
　2.画像BをフレームBより前面に移動します
　3.画像BのフレームがフレームBを覆うように大きく拡げます
　4.画像BとフレームBを選択してパスファインダで「交差」を実行、出来上がり
これならバージョンに関係なくできると思いますが、いかがでしょう？

No.6603 2012/03/10(Sat) 12:17:59
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7

Re: 続・フレーム調整オプションの挙動について / オメガ

（追記です）
手順1.で最初から大きめの新規フレームを作って画像を選択範囲内にペーストすれば、手順3.でわざわざ拡げる必要もなくなりますね...

あ、単純に『フレーム調整オプションを何も変えずにOKしたフレーム』を新規フレームで覆って、パスファインダで交差すれば『作成時のフレーム』の挙動に戻ります。
つまり、フレームBを新規フレームで覆ってパスファインダで交差→画像をコピー→選択範囲内へペーストという手順でできますね。

No.6605 2012/03/10(Sat) 13:18:02
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7

Re: 続・フレーム調整オプションの挙動について / （z-）

オメガ様

ありがとうございます。パスファインダは盲点でした。
　しかしスクリプトでペースト後に位置修正した方がよさげですね。。
ご尽力には感謝します ^

No.6617 2012/03/12(Mon) 12:18:10
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; ja-jp) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1

Re: 続・フレーム調整オプションの挙動について / （z-）

うーん。
フレーム調整オプションが効いてしまうフレーム内に、元位置ペースト可能な新規空フレームを配置、
そのまま「内容をフレームに合わせる」して、その中に「選択範囲内へペースト」
が手数的にも「離れないワザ」的にも無難かなあ。

No.6624 2012/03/14(Wed) 13:45:46
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; ja-jp) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1

Re: 続・フレーム調整オプションの挙動について / オメガ

>スクリプトでペースト後に位置修正
で上手くいきませんか？
少し書いてみましたが、条件をざっくり絞れば何とかなりそうな気がします。
それとも何か特別な条件を想定されているのでしょうか？

ちょっと元に戻りつつ脱線しますが、今回の件と似たような記事を見つけました。
[InDesign Secrets]
http://indesignsecrets.com/how-frame-fitting-options-affect-paste-into.php

スポイトツールを使って塗りカラーを拾うとフレーム調整オプションも一緒に拾ってしまうようです。
パスファインダでフレームBの色や効果が消えてしまうので、スポイトツールで拾おうとしたらハマり、調べている内に見つけました。
既に“汚染されている”フレームから色を拾うと、伝染るんです。チップスというより、全く役に立たない不具合ですが…。
こういう新しい発見があって私も勉強させて頂いています。感謝。

No.6630 2012/03/15(Thu) 02:20:48
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7

Re: 続・フレーム調整オプションの挙動について / （z-）

あ、いえ、すべての「選択範囲内へペースト」にとってかわるスクリプトを、ではなく、選択範囲内へペーストして想定外の結果が出たらundoして、用意しておいたスクリプトを、でも特に問題はなかろうと思います。
ただ、スクリプトに頼らずその場のオブジェクト操作で切り抜けられる事なのか、ある程度もがいておかないと超基本的な事すら見落としがちなので…個人的な理屈ですが。

スポイトツールはプリセットでもない限り前準備が面倒すぎて不安要素が多すぎるので20世紀の時点で敬遠しとります。。

No.6632 2012/03/15(Thu) 21:22:11
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.53.11 (KHTML, like Gecko) Version/5.1.3 Safari/534.53.10

Re: 続・フレーム調整オプションの挙動について / オメガ

理解しました。
端から見ていると、何もかもスクリプトで～と見えてしまうのでしょうね。それに頼らず簡単にできるなら、やはりそれが一番良いです。

スポイトツールがダメならオブジェクトスタイル経由とも考えましたが、ますます離れ業になってきたので。あとはA社に期待することにします。

No.6633 2012/03/16(Fri) 01:50:06
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.54.16 (KHTML, like Gecko) Version/5.1.4 Safari/534.54.16

Re: 続・フレーム調整オプションの挙動について / （z-）

で、結局スクリプトを書きました orz
http://pub.ne.jp/ajabon/?entry_id=4225447
「選択範囲内へペースト」に反応するイベントハンドラという形をとりました。

リンク先で訂正してありますが、スレッド親記事のCS3での手回避方法について解釈の誤りがありました。お詫びして訂正しま…しました。自分のとこですみませんが。。

No.6638 2012/03/21(Wed) 21:54:04
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; ja-jp) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1

フォントの置換でテキストデータが消える / うき

InDesign CS4 MacOSX10.6.8において

フォントの検索と置換を行ったとき、置換をした部分のテキストボックス内のテキストが丸ごとなくなってしまったり、一部分が消えてしまう現象がおきてしまう事があります。
消えてしまうとテキストデータ自体がなくなっているので、再度元のフォントに変更してみても消えたままになります。

同じファイル、同じフォントでも必ず再現する訳ではないので原因がつかめません。

どなたか原因などおわかりになりますでしょうか？

No.6558 2012/02/24(Fri) 14:58:59
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; ja-JP-mac; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27

Re: フォントの置換でテキストデータが消える / kin

検索置換では、置換文字列と置換形式を指定しないとマッチした文字列は削除という扱いになります。

こういうことでは？

No.6559 2012/02/25(Sat) 03:31:38
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/534.50.2 (KHTML, like Gecko) Version/5.0.6 Safari/533.22.3

Re: フォントの置換でテキストデータが消える / うき

kin様　お答えいただきありがとうございました。

しかし、私がお聞きしたかったのは書式メニューの「フォント検索」での「置換」で、検索と置換のテキストの置換ではないのです。
わかりにくくて申し訳ございませんでした。

引き続き原因等おわかりになる方よろしくお願いします。

No.6563 2012/02/27(Mon) 18:47:49
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; ja-JP-mac; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27

Re: フォントの置換でテキストデータが消える / まる

試したわけではないですが、
漢字（例：ヒラギノ）をひらがなフォント（游築五号仮名）に変換するとか、
約物を、約物を持たないフォント（例：游築見出し明朝体）に変換するとか、
なにかそういうことでしょうかね。

普通、アラートが出たり、消えてしまうのではなく、豆腐になったりするので、
通常の状態では、あまり考えられなさそうですが。

フォントが原因というより、何の文字かによるとかではないでしょうか。

消えてしまう文字には、何か共通性がございますか？
（特殊な書体、凝った合成フォントなど）

No.6564 2012/02/28(Tue) 02:00:45
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.53.11 (KHTML, like Gecko) Version/5.1.3 Safari/534.53.10

Re: フォントの置換でテキストデータが消える / こに

フォントの検索置換で、テキストそのものが消えてしまう現象は記憶にないですね。
テキストが消えた直後に編集メニューのトップは
「フォントを置き換えを取り消し　コマンド＋Z」になっていましたか？
（注；InDesignのローカライズのバグと思いますがそのまま表記してます）
フォントの検索置換でテキストのオーバーフローでフレームからはみ出したのではとも考えてみましたが、元のフォントに置き換えても復活しないようなので、この可能性は無さそうですね。

それと、実際に問題が発生したことのあるフォントの組み合わせはわかりますか？

No.6566 2012/02/28(Tue) 10:46:18
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/4.1.3 Safari/533.19.4

Re: フォントの置換でテキストデータが消える / dot

WindowsXP、InDesignCS3の組み合わせで経験があります。
InDesignを再起動して改めて置換すると問題がなかったりと、こちらでは原因が特定できていません。

記憶にある限りでは、システムにないフォントをシステムにあるフォントに置換するときに起こっている気がします。
OSXでもこの現象は経験がありますが、結局のところ原因が分からず放置しています…

No.6567 2012/02/28(Tue) 14:32:10
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

Re: フォントの置換でテキストデータが消える / Subi

英語のフォーラムでは同じ現象がしばしば報告されています。欧文フォントの置換で起こりやすいのでしょうか。
残念ながら根本的な解決方法はないようです。
報告の内容を以下にまとめました。

・「書式」→「フォント検索」で、フォントを「すべてを置換」で置換したときに発生（「置換」と「置換して検索」は問題なし）
・発生は毎回ではなくランダム
・InDesign CS3, CS4, CS5, CS5.5で報告あり
・Helvetica, Helvetia Neue, Arial Regular, Gill Sans, Palatinoなど非常にポピュラーなフォントで発生
・同名フォント同士のTTF→OTF、PS→OTF等の変換で起こることが多い（フォント置換作業ではありがちだからかも）

質問者がとった回避方法：
・問題なく置換されるまでundoする
・CS4からINXを書き出してCS3で作業する

回答者が薦めた方法（有効かどうかの報告なし）：
・検索置換でフォントを置換する（kinさんの画像の方法で、置換形式のフォントを指定する）
・段落スタイル・文字スタイルを使用してフォントを指定しているなら、手作業でスタイルのフォントを変更する

フォント検索の下部にある「すべてを置換した時にスタイルおよびグリッドフォーマットを再定義」をオンにして「すべてを検索」した場合に起こるエラーなのでは？と想像していますが、どうでしょうか。

http://forums.adobe.com/message/3730323
http://forums.adobe.com/message/2805566
http://forums.adobe.com/message/4178708
http://printplanet.com/forums/adobe/25712-text-disappears-when-replace-fonts-id-cs-5-a

No.6568 2012/02/28(Tue) 16:03:41
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.2; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; MDDR; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)

Re: フォントの置換でテキストデータが消える / こに

Subiさん
詳細な情報ありがとうございます。
私のとこでは普段「置換検索」かスタイルを適用でフォントを切り替えているので、再現することがなかったみたいです。
それにしてもCS5.5でも再現していててなおかついまだに解決策が提示されていないのは不安ですね。
次期バージョンのCS6(?)でも解決できていないんじゃないかと勘ぐってしまいます。

No.6569 2012/02/28(Tue) 17:04:00
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/4.1.3 Safari/533.19.4

Re: フォントの置換でテキストデータが消える / オメガ

昨晩試していた所、InDesign CS5 MacOSX10.6.8でも再現しましたが、再現条件はわかりませんでした。まさにランダムに起きるといった感じです。

十分検証できておりませんが、
・置換フォントには欧文フォントを指定した時でした。（和文フォントで起こるかは不明）
・和文フォント（TTF）でも全角／半角文字の一部が消えました。
・「すべてを置換した時にスタイルおよびグリッドフォーマットを再定義」は外した状態で起こりました。

「フォント検索」で置き換えた後にチェックをしないことはないと思いますが、これは気を付けるほかなさそうですね。Subi様、有用な情報ありがとうございます。

No.6572 2012/02/28(Tue) 22:02:15
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7

Re: フォントの置換でテキストデータが消える / うき

回答いただいた皆様ありがとうございました。

Subi様とても参考になりました。
ありがとうございます。

何度か検証してみたのですが、当方では和文のOTF（モリサワ）でも現象が起きています。
チェックを怠らないようにしないと．．．

これからいろいろな方法を模索していきたいと思います。

皆様本当にありがとうございました

No.6574 2012/02/29(Wed) 10:17:57
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; ja-JP-mac; rv:1.9.2.27) Gecko/20120216 Firefox/3.6.27

Re: フォントの置換でテキストデータが消える / mo

この現象って作業しているものにとって致命的な問題じゃないでしょうか？
『フォント置換で「すべてを置換」は使ってはいけない。』ということですよね。

まさか、文字がランダムで消えるとは思いませんからね。

この情報ってアドビが公式に知らせるべきじゃないですか？
もう公開しているのかしら？

Googleで検索してもここともう一つのブログしか見つかりませんでしたが……。

知り合いのインデザ使いには広めておこう。

No.6628 2012/03/14(Wed) 21:18:26
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.54.16 (KHTML, like Gecko) Version/5.1.4 Safari/534.54.16

ドロップシャドウで、色が変ってしまう / 急いでる

CS3です。

塗りを黒（K100）に設定したオブジェクトに、
赤系のドロップシャドウを適用し、レーザープリンタで出力したところ、
オブジェクトの色が、黒と赤が混じったような色で出てしまいました。

逆に、赤のオブジェクトに黒のドロップシャドウを適用しても、
赤が暗く出力されているように見えます。

画面上では、そのようにはなっていないように見えるのですが・・・。

ドロップシャドウのようなことをすると、
そのオブジェクトが透明になってしまったりすのでしょうか？
それとも、レーザープリンタで出力したせいなのでしょうか？
実際の印刷で、きちんとK100のように印刷されるようにするには、
どうすればいいでしょう。

念のため、そのドロップシャドウ適用したオブジェクトの上に、
なにも適用していていない、K100のオブジェクトをのせて出力してみても、結果は同じでした。
あと、属性ダイアログでは、オーバープリントにもなっていませんでした。

ドロップシャドウの設定を添付しておきます。
その他、説明不足でしたら、ご指摘ください。

よろしくお願いします。

No.6608 2012/03/11(Sun) 22:18:36
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; ja-jp) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19

Re: ドロップシャドウで、色が変ってしまう / こうちゃん犬猫まみれ

レーザープリンタは使ったことないのでそのプリンタの出力結果がどうなるか知りませんが、オーバープリントプレビューか分版プレビューで、版の状態を確認すればいいと思います。

No.6610 2012/03/11(Sun) 23:01:52
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11

Re: ドロップシャドウで、色が変ってしまう / 急いでる

ありがとうございます。

版の状態を調べてみましたが、おかしいと思うところがなく、
原因は分かりませんでした・・・。
確認するべくところが分かっていないのかもしれませんが。

No.6611 2012/03/11(Sun) 23:26:16
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; ja-jp) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19

Re: ドロップシャドウで、色が変ってしまう / Subi

以前、効果を使った部分がInDesignから直接プリントするとうまく印刷できないけれど、PDFに書き出してAcrobatでプリントするとできるということがありました。
一旦PDFに書き出してプリントしてみてはどうでしょうか。

No.6612 2012/03/11(Sun) 23:32:42
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; ja-JP-mac; rv:1.9.0.19) Gecko/2010031218 Firefox/3.0.19 GTB7.1

Re: ドロップシャドウで、色が変ってしまう / 急いでる

ありがとうございました。

PDFに書き出してプリントしてみたところ、
今度は、四角い状態で部分的に色が変わるようになりました。

でも、もしPDFでうまく表示できるのであれば、
PDFにして入稿しないとだめなのでしょうか。
インデザインを入稿してしまっても大丈夫なのでしょうか。

回答者様は、入稿後の実際の印刷の結果はどうでしたか？

No.6613 2012/03/12(Mon) 00:10:57
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; ja-jp) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19

Re: ドロップシャドウで、色が変ってしまう / Subi

ドロップシャドウの周囲が四角く色が薄くなる感じですか？それならプリンタの性能の問題で、データは問題ないはずです。

AcrobatでもInDesignでも分版プレビューができますので、分版チェックをして、問題ないならそのデータで入稿しています。
印刷屋には伝えておいた方がいいですね。

あとちょっと気になったのですが、赤というのはCMYKですか？それとも特色ですか？

No.6614 2012/03/12(Mon) 00:32:36
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; ja-JP-mac; rv:1.9.0.19) Gecko/2010031218 Firefox/3.0.19 GTB7.1

Re: ドロップシャドウで、色が変ってしまう / 急いでる

ご親切にありがとうございます。

＞ドロップシャドウの周囲が四角く色が薄くなる感じですか？

薄くなるというより、赤と黒で混ざるかんじなのです。
（最初に、混ざって出たのと同じようなかんじです。）
私も、PDFでシャドウの辺りの文字がズレたり変になる現象は見たことがありますが、
このようなケースは初めてです。

＞AcrobatでもInDesignでも分版プレビューができます

Acrobatでは、どのように確認すればいいのでしょうか。
探ってみましたが、よく分かりませんでした。
InDesignでは（おそらく）おかしくはないようでした。

＞印刷屋には伝えておいた方がいい

出力に「このような見え方にならないように」とか、
「この部分は、K100です」とか、書き込む指示でよろしいのでしょうか。

＞赤というのはCMYKですか？それとも特色ですか？

特色です。CMYKと特色では、何かが違ってきますか？

No.6615 2012/03/12(Mon) 00:55:23
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; ja-jp) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19

Re: ドロップシャドウで、色が変ってしまう / Subi

嫌な予感が当たってしまいました…
特色とドロップシャドウなどの透明効果は相性がとても悪いです。「特色　ドロップシャドウ」で検索してみてください。

InDesignのデータで入稿するなら分版をよくチェックしてください。
画面で見たときに問題ないなら、オーバープリントプレビューのスクリーンショットを印刷して「色はこれを参考に」と言うと分かりやすいと思います。

No.6616 2012/03/12(Mon) 01:09:22
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; ja-JP-mac; rv:1.9.0.19) Gecko/2010031218 Firefox/3.0.19 GTB7.1

Re: ドロップシャドウで、色が変ってしまう / 急いでる

何度もありがとうございます。

＞特色とドロップシャドウなどの透明効果は相性がとても悪いです。

それは、知りませんでした。
特色で透明効果は使用したことがあるのですが、シャドウは初めてなので、初めて知りました。

しかし入稿時には、特色の設定を、M版に置き換えるつもりなので、
そうすれば、問題ない（？）ということですよね。

それで、後からで申しわけないのですが、
分版のプレビューで問題がありました。
黒のオブジェクトにつけていた、赤の特色のところなのですが、
オブジェクトの下にもシャドウが入っていました。
だから、色が重なって見えていたと思われます。
（ふだん、分版プレビューを活用しないので、気がつきませんでした・・・。）

オブジェクトの下に、影の色が入らないようにするには、どうすればいいのでしょうか？？

最初に添付したダイアログのように、
「シャドウをノックアウト」にチェックをしているのですが、
それは、シャドウ部分にしか影がつかない、ということではないのですか？

ちなみに最初に書いたように、【属性】では、
オーバープリントのチェックも入っていません。

いろいろ申し訳ありません。よろしくお願いします。

No.6618 2012/03/13(Tue) 00:29:16
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; ja-jp) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19

Re: ドロップシャドウで、色が変ってしまう / Subi

・問題のオブジェクトのスクリーンショット
・ドロップシャドウの設定画像（最初の添付画像と同じなら不要）
・特色の色番号

文章では分かりにくいのでこちらをお願いします。

No.6619 2012/03/13(Tue) 01:39:36
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; ja-JP-mac; rv:1.9.0.19) Gecko/2010031218 Firefox/3.0.19 GTB7.1

Re: ドロップシャドウで、色が変ってしまう / 急いでる

・説明不足ですみませんでした。画像を添付します。
・ドロップシャドウの設定は、最初と同じです。
・それで特色ですが、事情により今回は使用できないことになりました。
今回は、特色でなくCMYKでいきます。（特色→M100+Y80 に置き換え。）

よろしくお願いします。

No.6620 2012/03/13(Tue) 21:49:45
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; ja-jp) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19

Re: ドロップシャドウで、色が変ってしまう / Subi

なるほど、把握できました。
K100のオブジェクトですが、塗りに[黒]のスウォッチを使用していませんか？
InDesignのデフォルトの設定では、[黒]のスウォッチを100%で使用すると強制的にオーバープリントがかかります。
この設定は「環境設定」→「黒の表示方法」で変えられますが、そのままにしておいたほうがいいです。そのかわり、オーバープリントをかけたくないオブジェクトを[黒]ではなく「C=0, M=0, Y=0, K=100」のCMYKスウォッチを100%で塗ればOKです。分版プレビューで確認できますが、こちらもきちんとプロセスブラックとして認識されます。

No.6621 2012/03/13(Tue) 23:36:04
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; ja-JP-mac; rv:1.9.0.19) Gecko/2010031218 Firefox/3.0.19 GTB7.1

Re: ドロップシャドウで、色が変ってしまう / Subi

あとは、K100のオブジェクト自体に乗算などの透明効果を使っていないかどうか、透明パレットで確認してみてください。

No.6622 2012/03/13(Tue) 23:58:53
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; ja-JP-mac; rv:1.9.0.19) Gecko/2010031218 Firefox/3.0.19 GTB7.1

Re: ドロップシャドウで、色が変ってしまう / 急いでる

教えていただようにしたところ、無事、思うようなことができました！！

オブジェクトの［黒］と赤を逆にする（オブジェクトを赤、影を［黒］にする）のは、ちゃんと影が抜き合わせになるのに、不思議ですね。

何年もインデザインを使っていながら、基本的なことを分かっていませんでした。
今回は、特色の件も勉強になりました。
無知な質問者に長らくお付き合いいただき、本当にありがとうございました。

No.6623 2012/03/14(Wed) 01:12:21
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; ja-jp) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19

Re: ドロップシャドウで、色が変ってしまう / Subi

補足です。

印刷屋の多くは製版段階でK100%を自動的にオーバープリント処理します。
万が一のことを考えて、K100%にMかYを1%足しておくことをおすすめします。

No.6625 2012/03/14(Wed) 13:58:38
Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11

Re: ドロップシャドウで、色が変ってしまう / 急いでる

インデザインでデータを抜き合わせにしたとしても、
印刷屋さんがオーバープリントにしまうということで気が抜けないですね。
結果的に色の見え方が変わってしまうのは気にならないんでしょうかね。

ご親切にありがとうございます。

No.6626 2012/03/14(Wed) 17:03:40
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; ja-jp) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19