InDesignの画像の割り付け

(以前のエントリー、「InDesignでWebDesign」の続きです)

例えば、InDesignの画像の割り付け作業は、他のAdobeソフトに比べ、とても簡単、かつ効率的です。

チュートリアル(のようなもの)を作成しました。1分47秒の動画です。

「画像の割り付け(+トリミング)」自体はもちろん、Photoshop、Illustratorを使って行うこともできますが、InDesignに比べ、工程はもう少し煩雑です。

Adobe XD(Adobe Experience Design CC)はInDesignに似た割り付け方法ですが、対応ファイルが少ない(例えば、.aiや.psdは割り付け不可)、画像を(外部リンクでなく)内部に持ち、ファイルがそれなりに重くなる、カラープロファイルを管理する機能がない、など、まだまだ荒削りです。

WebデザイナーがInDesignをさわることはまずないと思いますが、SketchやXDを「発見」した方なら、InDesignも一度触ってみることをオススメします。

また、印刷物のデザイナーでも、タイミングを逸すると、InDesignを全く経験しないままキャリアを積むこともあるようです。以前から使っているアプリを惰性でそのまま使い続けていると、作業効率でいつのまにか他者に差を付けられてしまいます。

InDesignの実務での導入をオススメするかはさておき、開発環境に於けるアプリケーションの選択は、常に柔軟に考えたいと思います。


ちなみに、InDesignの画像の割り付け方法は他にもあります。

  • Finderから画像ファイルを(何も配置されていない)アートボードやペーストボードにドラッグ&ドロップで割り付け。
    • クリックで実物大・ノートリミングで割り付け。
    • マウスで範囲を指定し、その範囲内に(縮小して)ノートリミングで割り付け。
  • ⌘+Dまたはメニューバー[ファイル]→[配置…]で割り付け。
    • さらにオプションを指定して割り付け。
      • 例)aiの背景を透明にしてアートワークのみを割り付け。
      • 例)pdfのページを指定して割り付け。
      • 例)psdのレイヤーを指定して割り付け。

「雑」な作業、段取りを考慮した細かな作業、どちらにも対応しています。

InDesignでWebDesign

備忘録ですらない完全な独り言。Adobe InDesign CCがWeb(グラフィック)デザインツールとして最適なのではないかという仮説。

ひとりQ&A

Q. え? InDesign? あれは印刷物を作るアプリでは? なんでまたInDesignなんかでWebデザインを?
A. とにかく速いから。軽いからです。速さは正義。軽さは正義。

Q. どのくらい速い/軽いアプリなの?
A. Adobe XD(Adobe Experience Design CC)より速いと思います。
◎「ヌルサク感」はXDの方がよいので、体感的にはXDの方が速く感じるかも。

Q. Adobe XDなんて使ったことない。もっと一般的なアプリで比較して。
A. Photoshopよりも当然速いです。Illustratorよりも速いです(Illustratorはそもそも激重アプリ。使う人の気が知れない)。Sketchは使い込んだ事がないので保留ですが、バージョンアップを繰り返し重くなってしまったと聞いています。Fireworksも作業効率の良いアプリでしたが、総合的にはInDesignに負けます。

Q. 信用できない。
A. 一定数の文字列や画像を配置して、いろいろ操作してみてください。ファイルオープンの時間や保存にかかる時間、レインボーサークルの発生する頻度を比較すればわかります。

Q. 多少速いだけでは意味ないのでは?
A. 速さは正義。InDesignは「ページ」の概念があるアプリ。「アートボード」が数個あった程度で能率は上がりません。1〜数枚のデザインを作成するためのアプリと数十枚以上のデザインを同時に進めるためのアプリの違いです。

Q. 速いだけがメリットのアプリなの?
A. 商業印刷物製作のデファクトなめるな。圧倒的なメリットとなる特徴が他にも複数あります。もちろんデメリットもあります。

Q. 具体的なメリットとデメリットを教えて。
A. 独り言なんで詳細に書く根気がでません。とりあえず箇条書きで放置することとします。


メリット

  • 強力なテキスト制御による(日本語含む)デバイステキストのシミュレーション。
  • 強力なテキスト制御による文字画像の並行製作。
  • 「段落スタイル」によるcssライクで効率的なテキスト操作。
  • 「段落スタイル」によるcssライクなパディング処理。エレメント処理。
  • 「テキストフレーム」を利用したcssライクなパディング処理。エレメント処理。
  • 「文字スタイル」によるcssライクなインライン修飾。
  • 「段落スタイル」の継承による合理的な要素管理。
  • 環境設定とグリッド設定による厳密なpixelベースの作業。
  • 「マージン・段組」を利用した、合理的なグリッドシステムの適用。
  • 小数点以下の数値入力による、高解像度デバイスへの対応。
  • 「ページ」「マスターページ」の概念による、ページ間のグリッド・デザイン・共通要素などの連関維持。
  • 「フレーム」を使ったクリッピングマスク処理いらず、スマートオブジェクト化いらずの画像割り付けと作業ファイルの軽量化。
  • 読み込みファイル形式の充実と何も考えずに下処理いらずで放り込めるリンク管理。
  • 割り付けたオブジェクトは全て「リンク」として外部ファイルに。ファイル容量の軽減。
  • 「Links」フォルダ内の「暫定」画像を「本番」画像で上書けば、デザインファイルもアップデート。トリミング位置も維持。
  • 読み込み・書き出し時のシンプルで容易なカラープロファイル管理。
  • 背景透過png書き出しによる、基本的な画像書き出し(2x含む)対応。
  • 余白も制御可能なパーツ単位でのjpg書き出し・png書き出し。
  • PDF出力・紙出力との親和性。デザイン完成時にプレゼン資料も併せて完成。
  • 高品質なワイヤーフレーム作成ツールとしての活用。以降のデザイン開発へのシームレスな移行。

デメリット

  • 「pixel by pixel」表示の概念がない。作業中は脳内補正が必要。
  • 作業中の表示がそれなりに粗い(「書き出し」後の画像ファイルは完璧)。
  • ブラウザプレビュー、外部デバイスプレビューなど、完成イメージを何度も素早くチェックする機能がない。
  • Photoshopの「アセット」のような、実装用画像切り出しの効率化を助ける機能はない。
  • 切り出し画像に事前にファイル名を付与しておくことができない(書き出しごとに1枚ずつ逐次命名)。
  • 書き出したpngファイルにカラープロファイルが付かない(jpgには付く)。
  • jpg書き出し時に細かな圧縮率の調整ができない。
  • 「透明」カラーの操作が貧弱。
  • (バイキュービック/ニアレストネイバーなど)画像拡大縮小の方法は選べない。拡大縮小時のシャープネス追加も行えない。
  • (今となってはもう不要だが)アンリエイリアス無しのデバイス文字はシミュレーション・作成不可。
  • 文字画像書き出し時のフォントのレンダリング方法(「クリスプ」「滑らか」など)は選べない。