出力の手引きWeb[InDesign]
2012年05月09日 ｜ Adobe Creative Suite 6 (3) - InDesignCS6の留意事項
Adobe Creative Suite 6 (1) - 発表
Adobe Creative Suite 6 (2) - 線にグラデーションを適応
Adobe Creative Suite 6 (3) - InDesignCS6の留意事項
Adobe Creative Suite 6 (4) - 評価結果報告
Adobe Creative Suite 6 (5) - サポート開始
Adobe Creative Suite 6 (6) - まとめ
InDesignCS6において、特定のオペレーションにおいて不具合が見つかりました。RIP以前のPDF書き出し時の問題です。
今回の問題は、InDesignドキュメントをInDesignに貼り、縦横比が異なる変倍で配置、というかなり限定的な問題です。
騒ぐほどの問題ではないと思います…
■概要
この問題はInDesignのドキュメント(.indd)をInDesignに貼り込む場合にのみ発生する問題です。
InDesignCS3以降で採用された効果がPDFに書き出すと消えてたり、出力が不正になります。
似た問題が過去にありましたが、今回の再現条件はより限定的です。
■再現条件
以下の4つの条件が揃った場合にこの問題は発生します。
1) InDesignCS6のみで発生
2) InDesignのネイティブ（.indd）をInDesignに貼る
3) 貼った.inddの変倍を縦と横で異なる値を設定
4) PDF/X-4など透明が活きたPDF書き出しで発生
■回避策
回避策としては、上記の再現条件を避ける方法が考えられます。
どれか1つでも対策すれば、この問題は発生しません。
1) InDesignCS6以外を用いる …ぉぃぉぃ
2) ネイティブではなく、PDF/X-4などに書き出して配置
3) 貼った.inddの変倍を縦と横で同じにする …デザイン変わる
4) PDF/X-1aなどあらかじめ透明の分割統合を行う …ぉぃぉぃ
従って、上記2)の回避策が最も適していると思われます。
■まとめ
今回の不具合は、InDesignのドキュメントをInDesignに配置するという編集を行った場合にのみ発生するものです。
この再現データは、「InDesignCS3エッセンシャルガイド」のCS3でサポートされた「効果」という機能紹介のために、この様な編集になったものと思われます。
EQUIOS / Trueflowでは、データ制作上で十分に注意すれば避けられる問題として、これが原因でサポート延期などの措置はとりません。
Adobeはこの問題に関して、同一バージョン内での修正に向けて最大限の努力を行う、とコメントしています。
（PDFのコアの部分の修正は影響範囲が広く技術的ハードルが高いですが、期待して待ちましょう）
2011年10月21日 ｜ InDesign CS5.5サポート情報(5) - 不具合修正されました！
本日、InDesign CS5.5のパッチである7.5.2がリリースされました。
このパッチで例の問題が修正されています。
リリースノート(英語)・(日本語)
リリースノートの「解決された問題 」「プリント / PDF」にある「PDF に書き出すと、ページ罫線の近くに挿入したテキストフレームが正しく配置されない場合がある。」がこの問題に該当します。「ページ罫線」ってなんだ？
修正前のTechNoteはこれですが、InDesign CS5.5 7.5.2以降ではこの問題は発生しません。
修正されたことをココにも書けばいいのに…
[Adobe] TechNote: 裁ち落とし線に接するテキストフレームが書き出したPDFでページ内に移動する（InDesign CS5.5）
この問題について、次のバージョンではなくInDesign CS5.5でキチンと修正されたことは、姿勢の問題として高く評価できると思います。
アドビシステムズの方々の粘り強いご協力にも感謝いたします。
2011年06月23日 ｜ InDesign CS5.5サポート情報(4) - 出力サポート開始
＜2011年10月22日追記＞
InDesign CS5.5 7.5.2 (Mac版)・(Win版)において、この問題は根本修正されました。
「2011年10月21日 ｜ InDesign CS5.5サポート情報(5) - 不具合修正されました！」を参照してください。
サポートに関する詳細は以下の記事を参照してください。
以前お知らせした「InDesign CS5.5に重要な不具合」については、Adobeと連携し対応状況の確認などを行ってきました。Adobeでの回避策についての技術的な裏付けの確認が完了し、つい先ほど従来のTechNoteに、より詳細な情報が追記・更新されました
Trueflowではこの回避策をもってInDesign CS5.5からの出力サポートを開始致します。
Trueflow SE Ver5.01 TF175 、Ver6.01 TF135、Ver7.10 TF110 以降が必要です。
[Adobe] TechNote: 裁ち落とし線に接するテキストフレームが書き出したPDFでページ内に移動する（InDesign CS5.5）
InDesign CS5.5のサポートについては、このTechNoteに基づいた回避策を実施して頂く事を前提とします。
回避策を実施しても、手順には大きな変更が無いので、既に公開している「Trueflow出力の手引き 第14版」の改訂はありません。ここでは、その他のInDesign CS5.5の出力サポートに必要な情報をお伝え致します。
■Trueflow印刷ユーティリティ2.6の公開
InDesign CS5.5でPDF/X-4:2010を出力するために必要なjoboptionsを追加したTrueflow印刷ユーティリティ2.6を、Trueflow SE製品情報ページよりダウンロードして下さい。
以前のTrueflow印刷ユーティリティ2.5との差違は、InDesign CS5.5に対応した「Trueflow PDFX4 1.4J.joboptions」の追加のみです。
それ以外に、フォルダ名を適切に変更しています。
■PDF/X-4の書き出しオプションの使い分けについて
InDesign CS5.5ではPDF書き出し設定の「標準」のPDF/X-4の設定として、PDF/X-4:2008からPDF/X-4:2010に変更されています。
上記「Trueflow印刷ユーティリティ2.6」には、従来から含まれているPDF書き出しプリセットファイルでCS5.1以前に対応している
Trueflow PDFX4 1.3J.joboptions
はCS5.5には対応しておらず、新たにCS5.5に対応した
Trueflow PDFX4 1.4J.joboptions
の両方が含まれています。こちらはCS5.1以前では対応できません。
GUI上では、どちらも選択できてしまうので、注意して下さい。
つまり、右表のように「Adobe Creative Suite 5.5」パッケージに含まれるInDesign CS5.5とIllustrator CS5.1では、PDF/X-4を作成するための設定ファイルを使い分ける必要があります。
■レイヤーのサポート
InDesign CS5.5からPDF/X-4を出力する事で、レイヤーを活かして、1つのPDFで複数の言語切り替えや、店名差し替えができる「バージョニング運用」が容易になります。これはInDesign CS5.5のみのメリットです。
詳細は「Trueflow出力の手引き 第14版」P91 「バージョニング運用」を参照してください。
■TechNoteの技術的裏付けについて
今回更新された回避策は、Adobeによってソースコードレベルでの技術的裏付けの確認と、検証が行われました。その結果、TechNoteでは以下の様なロジックで発生していたと説明しています。
| マスターページのテキストフレームが裁ち落とし線に交わるとき、PDFへ書き出す際に座標の再計算を行います。フレーム内マージンにより座標がシフトしないように修正が必要ですが修正前の座標が利用されていました。 |
■留意事項
この問題は、InDesign CS5.5からPDFを書き出すときに位置がずれてしまう問題です。印刷会社に書き出した後のPDFが入稿されて、PDF上のそれらしい位置に文字がある場合に、それがデザインの意図通りなのか、この問題によってその位置に移動したものか、PDFを見ただけでは分かりません。
・制作側では、PDFが意図通りであるか目視で確認して下さい。
・印刷側では、カンプを見て意図通りであるか確認して下さい。
それ以外にも以下の点に留意が必要です。
・InDesign CS5.5のみで発生します。
・PDF/X-4だけでなく、PDF/X-1aでも発生します。
・トンボの有無に関わらず発生します。
また、解決方法のA.として紹介されている…
| A. [ドキュメントの裁ち落とし設定を使用]を解除し、[裁ち落とし]の全てを０mmに設定します。 |
回避策を模索されていた方の中には、[ドキュメントの裁ち落とし設定を使用]のチェックを外すだけで回避できる、と解析された方もおられる様ですが、Adobeの解析では外した場合でも問題が発生するケースがあるので、やはり両方を満たす必要があります。
オススメ回避策は「C. テキストフレームを裁ち落とし線から離します。 」です。
■更新分だけが必要な方へ
既に以前のPDF/X-4書き出し設定ファイル「Trueflow PDFX4 1.3J.joboptions」はインストール済みで、今回の差分ファイル「Trueflow PDFX4 1.4J.joboptions」のみが必要な方は以下よりダウンロードして下さい。Mac/Win共通です。
Trueflow PDFX4 1.4J.joboptions（zip/4KB）
根本的な修正はいつかなぁ…
[第14版] [InDesign] [お知らせ] [解説追加] ｜ 固定リンク｜ 
2011年06月17日 ｜ InDesign CS5.5サポート情報(3) - InDesign CS5.5 - 7.5.1リリース
＜2011年10月22日追記＞
InDesign CS5.5 7.5.2 (Mac版)・(Win版)において、この問題は根本修正されました。
「2011年10月21日 ｜ InDesign CS5.5サポート情報(5) - 不具合修正されました！」を参照してください。
サポートに関する詳細は
「2011年06月23日｜InDesign CS5.5サポート情報(4) - 出力サポート開始」を参照してください。
＜2011年6月23日追記＞
この問題の回避策が公開されたので、InDesign CS5.5からの出力のサポートをはじめました。
詳細は記事「2011年06月23日｜InDesign CS5.5サポート情報(4) - 出力サポート開始」を参照してください。
本日、InDesign CS5.5の最初のパッチ7.5.1がリリースされましたが、この問題は修正されていません。
リリースノート(英語)・(日本語)
[Adobe] TechNote: 裁ち落とし線に接するテキストフレームが書き出したPDFでページ内に移動する（InDesign CS5.5）
「PDFの書き出しの領域における重要な修正」とはまた思わせぶりな言い回しを…
2011年06月07日 ｜ InDesign CS5.5サポート情報(2) - PDF/X-4のプリフライト
先日の「InDesign CS5.5サポート情報」の公開以降、掲載した情報についてAdobeと連携し対応状況の確認を行っています。
まず、先日の記事の最後に書いてある、InDesign CS5.5で出力したPDF/X-4は、Acrobat 9のプリフライト「PDF/X-4への準拠を確認」でエラーになるという問題については、Adobeの公式見解が確認できましたのでご紹介します。
「PDF/X-4:2010のプリフライトが可能なのはAcrobat Xだけ」本当は「Acrobat X以降」ですよねきっと。
と言うことだそうです。
近くAdobeからもこの件に関するTechNoteが公開される予定…のハズ
Acrobat 9でも、「レイヤーの付いたPDF1.6」をPDF/X-4にFixupする事ができ、そのFixupされたPDF/X-4のプリフライトは、Acrobat 9でも問題なくOKと判断されていました。
InDesign CS5.5で出力した「レイヤーの付いたPDF1.6」のPDF/X-4が、Acrobat 9でプリフライトがNGなのは、原理的に考えるとInDesign CS5.5に従来とは異なる何らかの変更があると考えられます。
バージョンごとにプリフライトの結果が異なるのは困りますよね。
[2011/06/09更新]
Adobeからこの件に関するTechNote「PDF/X-4:2010とAcrobat Proのプリフライトについて（InDesign CS5.5）」が公開されました。
2011年05月20日 ｜ InDesign CS5.5サポート情報
＜2011年10月22日追記＞
InDesign CS5.5 7.5.2 (Mac版)・(Win版)において、この問題は根本修正されました。
「2011年10月21日 ｜ InDesign CS5.5サポート情報(5) - 不具合修正されました！」を参照してください。
サポートに関する詳細は
「2011年06月23日｜InDesign CS5.5サポート情報(4) - 出力サポート開始」を参照してください。
＜2011年6月23日追記＞
この問題の回避策が公開されたので、InDesign CS5.5からの出力のサポートをはじめました。
詳細は記事「2011年06月23日｜InDesign CS5.5サポート情報(4) - 出力サポート開始」を参照してください。
InDesign CS5.5に重要な不具合が発見されたため、問題の解決/回避が明確になるまで、InDesign CS5.5からTrueflowへの出力サポートの開始を延期致します。
続報ありましたら追ってこのサイトでご案内致します。
本日、2011年5月20日(金)、Adobe Creative Suite 5.5が発売されました。Adobe CS5.5に含まれるIllustrator CS5には出力に関係する変更はありませんが、InDesign CS5.5には、出力に関係する変更がありますので、そのサポートについてお伝えします。
■お知らせ
以下の「■重要な留意事項」の問題ついて、印刷事故の原因になる可能性が高いと考えられることから、この問題の根本的な修正か、あるいは技術的裏付けに基づく有効な回避策が明確になるまで、Trueflowでのサポート開始を延期致します。
当社はAdobeと協力して問題解決向けた対策を進めており、再現条件や回避策の一層の精度向上を図ると共に、根本修正についても要請しており協調して検証を進めていきます。
この件に関して、AdobeからもTechNoteが公開されています。
しかし、今のところ技術的に完全にはクリアになっておらず、以下の情報は確認中の暫定的なもので、今後変更される可能性があります。
[Adobe] TechNote: 裁ち落とし線に接するテキストフレームが書き出したPDFでページ内に移動する（InDesign CS5.5）
以前の記事で説明した、PDF/X-4書き出し設定の変更については、以下のAdobe TechNoteもご参照下さい。
[Adobe] TechNote: PDF/X-4:2010について（InDesign CS5.5）
■重要な留意事項 （InDesign CS5.5 7.5.2 (Mac版)・(Win版)において、この問題は根本修正されています）
InDesign CS5.5において、InDesign上のマスターページ上では仕上がりサイズ、塗り足しサイズの外に書かれた文字が、PDF書き出しすると仕上がりサイズの中に現れるという問題が見つかりました。
これは、PDFをAcrobatで表示した時点で確認されるので、Trueflowの問題ではありませんが、この様な場所に（読まれたくない？）メモを書かれることがあり、それが仕上がりの中に現れるので印刷事故の原因になります。
＜想定される再現条件＞
・当社でのテストではInDesign CS5でこの問題は発生していません。
・PDF/X-4だけでなく、PDF/X-1aへのなどでも再現します。
・塗り足しがある場合に再現し、トンボの有無には無関係の様です。
・条件を満たした場合の再現性は100%ではありませんが、稀といえるほど少なくない模様です。
内部的に再現していても、移動が遠すぎて見えないだけかも…
＜今回再現できているデータについて＞
トラブルの再現には不要な設定も含まれていると思われますが、再現テストの手順として参考にして下さい。
・4ページの見開きドキュメント（左綴じ）を作成します。
・マスターページの左右両方にテキストボックスを配置します。
・テキストボックスを作成し、テキストフレーム設定のフレーム内マージンの「下」に3mmを設定します。他は0mmです。
・テキストボックスにテキストを記入します。インデント15mmで、左側は左揃えの左インデントで、右側は右揃えの右インデントです。
・さらに [テキストの編集]の[配置]を左ページは「下/左」に設定
・このテキストボックスを赤線で表示されている塗り足しエリアの上部の端に吸着して配置。
・PDF書き出しプリセットは標準でインストールされている[PDF/X-4:2008（日本）]あるいは、当社のプリセットでも構いません。
・ [トンボと裁ち落とし]タブの[裁ち落としと印刷可能領域]の[裁ち落とし]の全てを3mmに設定して下さい。当社のプリセットではデフォルトで3mmに設定されています。
・出力されたPDFの全ページを検査してください。
以前の記事で「多くの運用実績のあるPDF/X-4:2008がCS5.5で使えなくなるのは残念です。」と書きました。多くの運用実績を重視し、PDF/X-4:2008の書き出しをそのままの状態で残しておけば、これは大きな問題ではなかったはずです。
電子書籍も重要かも知れませんが、この様な基本的な変更を印刷向けに加えるのであれば、その部分のQAはもっと慎重にすべきです。
■PDF/X-4の書き出しオプションの変更について
InDesign CS5.5ではPDF/X-4の書き出しの「標準」のPDF/X-4の設定を、PDF/X-4:2008（PDF1.4ベース）からPDF/X-4:2010（PDF1.6ベース）に変更しています。この変更により、従来のPDF書き出しプリセットファイル「Trueflow PDFX4 1.3J.joboptions」はAdobeによれば、勝手に解釈を変えるので、使おうと思えば使えるらしいけど、どう変わるかユーザーは気づかないので、厳密には対応できなくなります。
今回より、新たにCS5.5に対応した「Trueflow PDFX4 1.4J.joboptions」を作成しています。こちらはCS5以前では対応できません。このjoboptionsが含まれた、新しいTrueflow印刷ユーティリティ2.6は、上記の問題がクリアになりサポート開始するときに公開致します。
つまり「Adobe Creative Suite 5.5」パッケージに含まれるInDesign CS5.5とIllustrator CS5では、PDF/X-4を作成するための設定ファイルを使い分ける必要があります。
ISO 15930-7であるPDF/X-4は、規格の最初からPDF1.6以下がベースバージョンで、透明だけでなく、レイヤーを活かせる事ができるの事も当初からの特徴とされていました。
■AcrobatによるPDF/X-4のプリフライトについて
InDesign CS5.5で出力したPDF/X-4は、Acrobat 9のプリフライト「PDF/X-4への準拠を確認」でエラーになります。
Acrobat X(10)とAcrobat 8では同じプリフライトでもOKとなります。
また、TrueflowのPolishedInputでのプリフライトでもNGで、レイヤーの記述に何らかの違いがある様ですが、処理を行う上での問題は見つかっていません。
2011年04月21日 ｜ InDesign CS5.5とQuarkXPress 9の事前情報
＜2011年10月22日追記＞
InDesign CS5.5 7.5.2 (Mac版)・(Win版)において、この問題は根本修正されました。
「2011年10月21日 ｜ InDesign CS5.5サポート情報(5) - 不具合修正されました！」を参照してください。
サポートに関する詳細は
「2011年06月23日｜InDesign CS5.5サポート情報(4) - 出力サポート開始」を参照してください。
＜2011年6月23日追記＞
この問題の回避策が公開されたので、InDesign CS5.5からの出力のサポートをはじめました。
詳細は記事「2011年06月23日｜InDesign CS5.5サポート情報(4) - 出力サポート開始」を参照してください。
QuarkXPress 9についても詳細は記事「2011年05月18日｜QuarkXPress 9サポート情報」を参照してください。
これらのDTPアプリケーションは現在検証中でありサポートしていません。
サポート開始時期に関しては、追ってこのサイトでご案内致します。
InDesignとQuarkXPressの最新バージョンが以下の予定で発売されます。
・Adobe Creative Suite 5.5：2011年5月20日(金) プレスリリース（PDF/160KByte）
・QuarkXPress 9：2011年4月26日(火) プレスリリース（HTML）
それぞれの新機能や特徴などは、開発元の情報をご参照下さい。
ここでは、出力に関係する情報と、当社の対応の予定をお伝えします。
Adobe CS5.5に含まれるIllustrator CS5には出力に関係する変更はありませんが、InDesign CS5.5には、以下の様な出力に関係する変更があります。
・Adobe InDesign CS5.5
InDesign CS5.5ではPDF/X-4の書き出しの「標準」のPDF/X-4の設定を、PDF/X-4:2008（PDF1.4ベース）からPDF/X-4:2010（PDF1.6ベース）に変更しています。この変更により、従来のPDF書き出しプリセットファイル「Trueflow PDFX4 1.3J.joboptions」は対応できなく(*1)なります。現在、CS5.5に対応した「Trueflow PDFX4 1.4J.joboptions」を作成、検証中ですが、こちらはCS5以前では対応できません。(*1)
ISO 15930-7であるPDF/X-4は、規格の最初からPDF1.6以下がベースバージョンで、透明だけでなく、レイヤーを活かせる事ができるの事も当初からの特徴とされていました。しかし、多くの運用実績のあるPDF/X-4:2008がCS5.5で使えなくなるのは残念です。
つまり「Adobe Creative Suite 5.5」パッケージに含まれるInDesign CS5.5とIllustrator CS5では、PDF/X-4を作成するための設定ファイルを使い分ける必要があります。
(*1)読み込みや書き出しは出来るのですが、プリセットのダイアログに左図の様な警告が表示されます。左図はInDesign CS5にCS5.5用のプリセットを読み込んだ場合の警告。
「透明度に関して PDF/X (2003) 標準に準拠するために Acrobat 4 (PDF 1.3) にリセットされました。」…実際にはAcrobat 5 (PDF 1.4) にリセットされてるし、PDF/X(2003)って意味分からない上に、実際にはPDF/X-4:2008に設定されてるし…
・QuarkXPress 9
QuarkXPress 9に関しては、出力に関係する変更はない見込みです。
出力スタイルファイルなども現在配布しているQuarkXPress 8向けのものがそのまま使用できる様で、現在検証中です。
また、出力に関する留意事項もQuarkXPress 8と同じで、特に以下の事項に留意してください。
・貼り込まれたIllustratorネイティブの透明は分割統合されてから出力されます。
・オーバープリントプレビューはサポートされていません。
PDFに書き出してからAcrobatでチェックして下さい。
・PDF/X-4はサポートされていません。
PDF/X-1a出力を推奨します。
実際にこんな箱で売るんだろうか？見てみたい。
[第14版] [InDesign] [QuarkXPress] [解説追加] ｜ 固定リンク｜ 
2011年04月19日 ｜ Adobe PDF Print Engineでのオーバープリント(6) - 番外編：DeviceGray
前の記事
「Adobe PDF Print Engineでのオーバープリント(5) - 理論通りにならない事例」
の補足です。
この記事は全て従来処理系の内部の処理について言及していますが、出力結果は最新処理系と同じになります。
以下の事例2)について、さらに理解を深めるために2つの事例を紹介します。
前の記事の2)を引用します。
 2) 従来処理系なのにDeviceGrayのオーバープリントがヌキにTrueflowの従来処理系では、透明をそのまま演算できないので、入力処理の内部で透明の分割統合処理が行われます。この透明の分割統合処理を行う部分は（Trueflowのオーバープリントモードの設定に関わらず）PDFの規格に基づいてオーバープリントを再解釈します。 ここで、DeviceGrayのオーバープリントオブジェクトは、（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYK部品に変換され、結果ヌキになります。 |
2-1) DeviceGrayのオーバープリントがノセにならないといけないケース（Trueflowの従来処理系）上記では（PDFの規格に準じるとノセなくていいので）と説明しましたが、PDFの規格に準じるとDeviceGrayのオーバープリントがノセにならないといけないケースでは、どの様になるのでしょうか？
今までの全ての事例は下部のオブジェクトもプロセスカラーであることが条件です。もし、この例でも下部が特色でDeviceNやSeparationの場合、最新・従来に関わらずノセになる必要があります。
実際の出力結果も、右図の用に確かに元々DeviceGrayだった部分が（透明と同居しているにも関わらず）期待通りノセになります。
これはRIP内部の処理において、オーバープリントに対して、あたかも透明のような分割統合処理が行われています。基本的にDeviceGrayは（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYKに変換しますが、下部が特色の部分だけはノセる必要があるので、その部分を分割しDeviceCMYKのオーバープリントがOnに変換します。この単純な例では、DeviceGrayを分割せずにDeviceCMYKのノセに設定すれば良さそうですが、他のオブジェクトが絡んでくる事を考えると分割されるのが正解です
2-2) DeviceGrayの墨ベタで自動オーバープリントが効かないケース（Trueflowの従来処理系）
右図は、分かりやすくするために墨ベタを少し薄くしています
前の記事の最後に「DeviceGrayの墨ベタにも自動オーバープリントは効く」と書きました。確かに2)の例（下部が単純なDeviceCMYKの図形）で、もしDeviceGrayが墨ベタの場合は、分割は行われず、単にオーバープリントがOffに変換されるだけなので、その後の自動オーバープリントは効きます。
しかし、自動墨ノセは万全ではありません。
DeviceGrayで記述された墨ベタが、透明と同じページにあった場合、入力処理の分割統合処理において、DeviceCMYKの部品に対しては（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYK部品に変換されるまでは、上記2)と同じです。
しかし、下部のオブジェクトがグラデーションや画像の場合、分割統合の影響で重なっている部分が画像化されてしまいます。
この分割統合処理で生成された画像は、ノセなくていい前提で分割統合されているので、せっかく分割されたのに、グラデーションとは合成されておらず、単なる墨ベタの画像（トホホ…）になっています。
こうなってしまうと、テキストでも図形でも無いので、自動オーバープリントは効きません。
その上、下部のオブジェクトも欠けているのでどうしようもありません。
＜まとめ＞
・全ての例は、同じページ上に分割されていない透明オブジェクトがある場合に限ります。（つまりPDFのみ）
・Adobe CS3以降など推奨アプリケーションを使えば、この様なことを考える必要はありません。
2011年04月15日 ｜ Adobe PDF Print Engineでのオーバープリント(5) - 理論通りにならない事例
以前の4つの記事
「Adobe PDF Print Engineでのオーバープリント(1) - 概要」
「Adobe PDF Print Engineでのオーバープリント(2) - 技術詳細」
「Adobe PDF Print Engineでのオーバープリント(3) - DTPアプリケーションの挙動」
「Adobe PDF Print Engineでのオーバープリント(4) - 覚えておくべき事」
では、基本的な事例を紹介しました。もう1年以上前ですね…
ここでは、その基本で説明した原理から外れる処理結果について、なぜ結果が異なる場合があるのか、技術的に説明します。
■結論「推奨アプリケーションではこの差違は発生しません」
・AdobeCS以降、QuarkXPress 6以降
オーバープリント処理の違いを意識する必要はほとんどありません
Acrobatのオーバープリントプレビュー通りの出力が得られます
・それよりも古いアプリケーション
オーバープリント処理の違いから出力を予測することが必要です
＜まとめ＞
不具合の要因(リンクで貼るとスジが出るなど)も考慮すると、特にAdobe CS 3以降、QuarkXPress 8以降を推奨します。詳細は、Trueflow出力の手引き 第14版P4「サポート DTP アプリケーション」を参照して下さい。
＜注意＞この記事は、特にIllustrator 10以前やInDesign 2.0.2以前、推奨設定を使用しないQuarkXPressを使用される場合にのみ必要な情報です。
■従来処理系と最新処理系の差違の基本
以下のオブジェクトにオーバープリント指定された場合で、かつ下部のオブジェクトもプロセスカラーの場合、オーバープリント属性が設定されていても、PDFの規格上ノセにならない事になっています。
・グラデーション(DeviceCMYKで指定された)
・パターン(DeviceCMYKで指定された)
・画像(DeviceCMYKで指定された)
・DeviceGrayのオブジェクト
Acrobatでの表示も規格通り、これらのオブジェクトはノセになりません。Trueflowでの出力結果は、基本的には以下の様になります。
・従来演算系：これらのオブジェクトのオーバープリントを処理
・最新演算系：PDFの規格通り、これらのオブジェクトはヌキに
これらの処理の違いから、同じデータをTrueflowの従来演算系と最新演算系の両方で処理した場合、出力結果の差違が表れます。上記、推奨アプリケーションでは、この差違は発生しませんし、デザインとしてもレアケースであること、DeviceGrayによる墨ベタにも自動オーバープリントは効くことを忘れないで下さい。
■基本通りにならない事例
以下の3つの事例は、本来の動作とは逆の結果になっていますが、それぞれ条件と技術的なロジック（理由）があります。
＜事例＞
1) 最新処理系なのに透明があるとDeviceGrayのオーバープリントがノセに
2) 従来処理系なのに透明があるとDeviceGrayのオーバープリントがヌキに
3) 従来処理系なのに透明があるとDeviceCMYKのグラデーションのオーバープリントがヌキに
＜発生条件＞
・同じスプレッド内（ページ内）に透明オブジェクトが含まれている。
・透明オブジェクトと該当オーバープリントとの位置関係は問わない。
・同じスプレッド内（ページ内）に透明オブジェクトが無ければ基本通りの処理になる。
→つまり、同じ処理範囲内に透明オブジェクトがあると、位置的には全く関係のない場所のオーバープリントも含めて動作が基本通りになりません。同じ処理範囲内に透明があると、処理が変わる、ということになります。
＜発生ロジック＞
1) 最新処理系なのにDeviceGrayのオーバープリントがノセに
同じページに一つでも透明オブジェクトがあった場合、透明の処理による色の整合性を保つ（透明が関わるDeviceGrayと、透明が関わらないDeviceGrayの色の結果を合わせる）ため、全てのDeviceGrayオブジェクトはSeparation Blackに置き換える処理を行います。
この処理は、同じページ上であれば、透明との配置関係の有無に関わらず、印刷用の色空間であることを明確に示すSeparation Blackへの置き換えを、Trueflowの入力処理の内部で行います。
DeviceGrayは、DeviceRGBと同じく光の強さを示しており、DTPアプリケーション上グレースケール100%は「黒」ですが、PDFの記述上は0が「黒」、255が「白」になります。
その結果、ノセになります。
従って、同じページに透明オブジェクトが全く存在しない場合は、ヌキになります。
2) 従来処理系なのにDeviceGrayのオーバープリントがヌキに
3) 従来処理系なのにDeviceCMYKのグラデーションのオーバープリントがヌキに
この2)と3)は同じ原理で説明できます。
Trueflowの従来処理系では、透明をそのまま演算できないので、入力処理の内部で透明の分割統合処理が行われます。この透明の分割統合処理を行う部分は（Trueflowのオーバープリントモードの設定に関わらず）PDFの規格に基づいてオーバープリントを再解釈します。
ここで、DeviceGrayのオーバープリントオブジェクトは、（PDFの規格に準じるとノセなくていいので）オーバープリントがOffのDeviceCMYK部品に変換され、結果ヌキになります。
DeviceCMYKのグラデーションも同じく（PDFの規格に準じるとノセなくていいので）オーバープリント設定はOffに変換されます。
逆に、同じページに透明オブジェクトが全く存在しない、などPDF1.3準拠のデータの場合、透明の分割統合処理も行われず、DeviceGrayやDeviceCMYKのグラデーションのオーバープリントオブジェクトは基本通りノセになります。
＜最後に＞くどい様ですが…
「結果は一致しない」事にのみ注目するのではなく、以下の項目を念頭に、「ほとんどの場合結果OK」と冷静に判断し、技術情報として正しく理解しておくことが重要です。
・全てAdobe CS3以降など推奨アプリケーションではこの差違は発生しない
・1)は、規格通りではないがオーバープリントがノセになる方向の違い
DeviceGrayになっている事に気付いていない事の方が多いので、ノセになるのが期待通りでは？
・2)は、DeviceGrayの墨ベタにも自動オーバープリントは効く
・3)は、ほとんどオペレーションミス（意図的にしたい場合は乗算の透明を使いましょう）
「最適な出力」とは、重箱のすみのギリギリの部分で、やむなく規格通りではない処理を行う事も含めて実現されます。今後も「最適な出力」を目指していきます。
2011年01月31日 ｜ 太らせた文字がかすれた様に出力される問題
■出力結果の例（拡大図）
■概要
文字の線幅を指定することで、文字を太らせるデザインを行った場合、RIPの演算結果、文字がかすれた様に出力される場合があります。この問題は低い解像度で、解像度に適さない線幅を指定した場合に発生する問題です。
■発生条件
・出力解像度が低い（この例では360dpi）
・文字の線幅を指定して、文字を太らせる
・この線幅が細い場合（この例では0.2pt）
→解像度が低く、線幅が細い結果、デバイス解像度で1ピクセルの線になる場合。
■回避策
・文字の線幅を指定する事で文字を太らせるのではなく、太い書体を用いる。
・文字に設定された線を太くする。（文字が潰れる弊害があります）
デザイン品質上の問題としても、文字の線幅を太らせる手法は、書体のバランスが失われ、文字が潰れるので、お勧めできません。
■発生原理
・文字はHINT情報により、図形の塗りつぶし (fill) の幅を一致させるために、調整されます。
・文字のアウトラインは、線幅補正機能（SA : stroke adjustment）により、線幅 (stroke) を一致させるために、調整されます。
・fillとstrokeが別々に調整（微細な移動）されることで、解像度が低い場合にstrokeとfillの間に隙間が現れます。
■HINT処理、線幅補正について（右図は概念で、実際の演算はもっと複雑です）
HINT処理や線幅補正処理は、文字や罫線の配置位置による統一性を保つために、理論的な配置位置を最大で0.5デバイスピクセル分移動します。
この移動により、実際の物理的な配置位置は1デバイスピクセル分の差違が出る場合があります。（実際には0.5ピクセルだけ塗ることはできないので、RIP演算時に丸められるから）
今回の線幅として指定された0.2ptは、360dpiではちょうど1ドットつまり1デバイスピクセル分しかありません。2400dpiだと0.2ptも7ドットで描画されます。
HINT処理や線幅保障処理によって、1デバイスピクセル移動した場合、2400dpiなら大きな影響はありませんが、1ドットしか描画されない360dpiでは大きな影響が出ることになります。
本来、HINT処理や線幅保障処理は、特に低い解像度で出力する場合に効果がありますが、360dpiでの出力において0.2ptの線幅を文字の周りにつける処理は、補正の限界を超えていると言えます。
