- [4406] インデザイン上で画像を拡大、または縮小するDTPオペレーターさんは 旧掲示板 2009/03/09 12:30
インデザイン上で画像を拡大、または縮小するDTPオペレーターさんは
いらっしゃいますか？
これを読んでおられる皆様は、そんなことはされていないと思いますが…。
以前、マックOS9でクォーク3.3で制作しておりました時は、縮小率は70％まで、拡大率は120％までと入稿先の指定がございましたが、RIPにかなりの時間がかかるとか、画像の劣化を防ぐとかで、すべて原寸で貼り込む方がいいと入稿先の現場の方々と相談して現在に至っております。
ところが、ウィンドウズでインデザインによる制作をはじめた3年前の頃のことでございます。
ときどき撮影されたまま、もしくは入稿されたままの画像をフォトショップで前処理せずに、縦横寸法を超特大のまま貼り付けて、インデザイン上で縮小（小さくしすぎた場合は拡大）しているDTPオペレーターさんがおられます。
理由を聞いてみると、煙草すったり、コーヒーすすりながらダベるヒマはあるのに、切迫した納期に追われてやる間がありませんとか、何かしらんができませんとか、よくわかりませんとか、めんどくさいのでしょうか? きちっと作業することを放棄しておられるようでございます。
皆様は、こういったきちっと作業することを放棄しておられるDTPオペレーターさんに、どのように指導されていますか。
週明けの真昼間から皆様は、お忙しいこととは存じますが、ご意見など頂戴できればありがたいです。
おこりん坊、あらため春は弥生 2009/03/09 12:30:11
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
001
質問に質問で返すのもアレなんですが、刷版もインデザインでやっているのでしょうか？
うちでは2年前から本格的にPDF運用に切り替えました。
私自身は刷版担当ではないのですが、特におこりん坊さんがおっしゃるような作業しても重い（遅い）といった苦情はないのです。（PDF作るときに遅くはなりますが…）
各オペレーターの判断でサイズをフォトショップで変えるか、インデザイン（クォーク方がメインですが）で変えるかは自由にしています。
無駄に大きすぎる場合にはサイズ小さくしますが、小さいものを大きくする際にはフォトショップ使ってません。
イラレの場合は極力100％画像を使用するようにしてますが・・・。
刷版用のパソコンにはフォントすらまともに入っていない状況（苦笑）
長くなりましてすみません。
みや 2009/03/09 16:26:11
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
002
DTPオペレーターという言葉。幅が広すぎますね。
デザイン・制作・製版等々…。全てDTPオペレーターに属します。
質問に登場する方はどの工程なのですか？
それによって答えが違うと思いますよ。
zzz 2009/03/09 16:39:25
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; ja-jp) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
003
私なんかは印刷会社の人間でして、
内部での作業についてはきっちりやってますが
外部で作ったデータについて、ましてや
そのデータの作成者に「指導」なんてできませんし、しません。
立場が違いますし。
「こんなデータの作り方してました、こういうやり方だとシャープネスとか同じように効かせるの困難ッス」
みたいなことは言いますけどね。
匿名その100 2009/03/09 18:55:22
Mozilla/5.0 (Macintosh; U; PPC; ja-JP; rv:1.0.2) Gecko/20030208 Netscape/7.02
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
004
編集者さんから画像とテキストの材料を受け取って、印刷所に（QuarkまたはInDesignの生データもしくはPDFで）渡すところまでをMacでやっている、いわゆるレイアウターとしてのオペレーターです。この工程での話です。
カタログのようにかっちりフォーマットが決まっていて、入稿される画像形式も一定のものであれば、トピ主さんのような運用もアリかと思います。
そうでなくて、校正で画像のレイアウトサイズに赤字が入ってくるようなものの場合は、ちょっと現実的ではないように思いますが。。。
もちろん、RGB→CMYK・解像度・ファイル形式・カラーモードなんかについてはソースごとにバッチ処理でできる限りムラなく事前に統一します。モノによってゴミ取り、モアレ取り、シャープネス等々の加工も必要に応じてやります。
しかしレイアウトサイズまで事前に加工してしまうのは当然無理な話ですし、【加工のしすぎはかえって画像の劣化になるので貼り込みサイズはレイアウトソフト上で調整するのが鉄則】というMac OS7時代くらいに教わったこと（笑）を盲信したまま今までクレームなくやってきてしまったので（最新はOSX10.4×CS3で制作）、、、ホント、どの段階でどういう不都合がどの程度生じるものなのか、逆に詳しく質問したいです。
昔の常識、今の非常識だったりするのかな。。。
あれ、もしかしてアタリで貼っておいてレイアウトが確定した段階で100%前後になるようにPhotoshopでリサイズしろってことですか？？？ それもものすごくキケンな作業のような気がしますが。。。
こういうことはハウスルール的なものに大きく左右されることだろうとは思うのですが、いずれにせよ詳しい内容をシェアしていただけるとうれしいです。
よろしくお願いします！！
op 2009/03/09 19:52:43
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; ja-jp) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
005
＞皆様は、こういったきちっと作業することを放棄しておられるDTPオペレーターさんに、どのように指導されていますか。
あんたアホですか？
なんであんたが指導できる立場だと思うんですか？
あんたは言われたことを言われたとおりにやってりゃいいんですよ。それしかできないんですから。
ビジネスで求められてるのは、完全なデータをつくることじゃないんですよ。
アホな出力オペは、そこのところを勘違いする。
＞RIPにかなりの時間がかかるとか
いつの時代の話をしてるんですか？
てか、設備投資しないんですか？
で、出力に時間がかかったら、何ですか？
そんなのはあなたの会社の問題で、
クライアントには関係のないことです。
出力に時間がかかるなら、
かからないように設備投資すればいい。
＞理由を聞いてみると、煙草すったり、コーヒーすすりながらダベるヒマはあるのに、切迫した納期に追われてやる間がありませんとか、何かしらんができませんとか、よくわかりませんとか、めんどくさいのでしょうか? きちっと作業することを放棄しておられるようでございます。
馬車馬のように働くことを美徳とするあなたの価値観を、他人におしつけてるだけじゃないですか。
相手はあなたのクライアントで、あなたがその姿勢にどうこう文句の言える筋合いのものではありません。
あなたは完璧なデータをつくることが仕事かもしれないし、それしかとりえがないかもしれませんが、
相手はそうではないということを認識すべきです。
原寸でデータを扱う、理想論ならそうでしょう。
でも、実務ではちがいます。
それぞれにそれぞれの仕事形態があって、
その人に与えられる仕事の概念もちがうし、目標としてるものも違います。
た・だ・し、
ですよ、
私もバカじゃありませんので、これだけは言っておきます。
＞ときどき撮影されたまま、もしくは入稿されたままの画像をフォトショップで前処理せずに、縦横寸法を超特大のまま貼り付けて、インデザイン上で縮小（小さくしすぎた場合は拡大）しているDTPオペレーターさんがおられます。
のように制作をされたデータを出力したとしてでですね、
「なんか、写真がねむたいんだけど」
とか、間抜けなクレームをクライアントがつけてきたらですね、
鼻で笑って、「あなたのデータどおりですよ」と言って下さい。
そして、本気で戦ってください。
その覚悟がおありならどうぞ。
戦うのはいやだ、
でも、データはちゃんとしてほしい。
ってな文句なら、そんなもん、クライアントは耳をかしませんよ。あたりまえのことです。
どうせ、あなたの会社のアホ営業が安請け合いしてきた仕事でしょう？
問題はあなたの会社にあり、つまり、あなた自身にあるんですよ。
そのことを自覚しなさい。
ただまぁ、クライアントも“アホ”前提で話してますが、
ただ単に素人で無知に由来するのでしたら、
早めに“指導”ではなく“アドバイス”するべきでしょう。
あなたがよくご存知のように「過度の拡大縮小をすると写真のシャープさをそこないますよ」と。
そういった、“コミュニケーション”を行うことのほうが、
あなたがこうやって、勝手に不満を掲示板にぶつけることよりも
ずっと大切なんですよ、社会という場ではね。
あなたにできますか？ それが。
営業まかせにしてませんか？
そこが問題なのですよ。
もうすこし社会を見ようと努力すればわかりますよ。
ラッキーアンストライク 2009/03/09 21:58:44
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
006
あと、余談ですが、
みやさんの
＞うちでは2年前から本格的にPDF運用に切り替えました。
は、限りなく正解に近いです。
●●で●●すると●●になるので、
全ての問題を解決できることになります。
理想論ですけどね。
最近のPhotoshopなんかを見てると、
adobeはそこを目指しているなとは感じます。
って会話についてこれる人が、どの程度いるか…
ラッキーアンストライク 2009/03/09 22:43:43
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
007
あー、何か商品写真的な結構クオリティにこだわる撮影画像のみのお話だったっぽいですね。
ひとくちに画像といっても画面キャプチャとかいろいろあるし、めったにそこまで画像クオリティにこだわるお仕事をいただけないぺーぺーなもんで（ショボン）、びっくりして余計なことを書いてしまったかも。すみません。
もちろんポジスキャンからのものや、写真をそこそこきれいに見せたい案件なら事前にある程度の出力サイズを想定して粒を揃えておきますし、本気でクオリティを求めるものなら逆にいじらずにアタリ画像にしておいて、印刷所さんに画像調整をおまかせしてしまう方法をとる場合もあります（もちろん打ち合わせの上でです）。
とはいえ今どきほぼデジカメでしょうし、質より安さにもってかれる時代なので（泣）、、、ものによってはトピ主さんの言うリサイズ作業が無意味な場合もあるわけです。
さらには撮影方法まで遡らなくてはならないこともあるわけで、一概にレイアウターさんだけの問題でもないような。。。
お気持ちはなんとなくわかりますが、「どういう内容のものをどういう条件で請け負って、どの段階で印刷所に出すのか」というあたりを明確にした上で、ご同僚なのであれば指導というよりは打ち合わせや作業方針の確認ということなんじゃないでしょうか。各自違う案件を扱ってるなら各自の問題だし、共同作業や引き継ぎ予定の作業なら互いに方針を確認することなく手をつけてしまっていること自体に問題があったりします。
また、トピ主さんのさらに下請けさんなのであれば、その作業をさせる意味をご自身が認識した上できちんとハウスルールを伝え、待遇面の確認もしてあげないとちょっとツラいかなー。。。
きちっとやることと、無駄なことまで強いることとは違います。もちろん後工程などに影響しない範囲でトピ主さんご自身が独自に極み（？）を目指されるのは結構なことですよ。
まあ画像の扱いよりもまわりの作業態度についてが本題っぽい気もしますので、、、そのあたりご自身の内面でこじれて絡まったひもを解いていくのが重要かと思います。。。こういうお仕事でこういうご時世だとどうしてもそういう迷路にはまりやすいんですよね。わたしもそういう時代がありました。
なかなか難しいのですが、あまり思い詰めないで早めに気分転換する方法を見つけられるといいと思いますよ。結局問題は自分の内面にあり、他人はその鏡であると。相手に変わって欲しいならまずご自分の接し方から変えていかないと。頭から他人を否定してしまうと回り回って自分が否定されることになっちゃいます。
って妙な精神論みたいになって恐縮ですが、職場でギスギスしてネット上でケンカして…ではあまりに生産性に欠けるので、トピ主さんの方針にも合致しないのではないですか？
ここで一歩引いて全体を眺める余裕を持てるかどうかが、どんな職種でも分かれ道のような気がします。わたしもそんなえらそうなことを言える状況ではないんですがー（ハァー）。ご参考までに。
op 2009/03/10 00:22:32
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; ja-jp) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
008
みや様
説明不足で申し訳ありません。
＞刷版もインデザインでやっているのでしょうか？
インデザインでしかできないところはインデザインで渡します。PDFで、と指示がある場合はそれに従います。
＞（PDF作るときに遅くはなりますが…）
確かに。弊社では古美術のカタログを制作していますが、1ページに商品画像をめいっぱい貼り込み、おまけに上からの要望で背景全体に模様の画像を配置していますから、重くて重くて…。
＞小さいものを大きくする際にはフォトショップ使ってません。
これに少々不安がつきまといます。解像度は大丈夫なんでしょうか？
zzz様
説明不足で申し訳ありません。
＞DTPオペレーターという言葉。幅が広すぎますね。
デザイン・制作・製版等々…。全てDTPオペレーターに属します。
出版社で小部数の古美術カタログ、書籍および書籍の広告などを制作してます。
おこりん坊、あらため春は弥生 2009/3/10 9:35
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
9
＞インデザインでしかできないところはインデザインで渡します。
最終がインデザインの形であればOKということなら、
いったんPDFにしてそれをまたインデザインに自動配置？をやれば無駄に重いという状況は回避できませんか？
＞これに少々不安がつきまといます。解像度は大丈夫なんでしょうか？
基本的には無理な拡大はしません。ものにもよりますけど、カラーで200dpi相当くらいまでは目をつぶります。
それをレイアウトして「もっと大きくして！」と指示がでたら、「今でも画質が半分になってて、これ以上拡大するとボケボケになるよ」と先方に報告します。
大概の先方は「他にないから別にいいですよ」と返事がきます。先方さえよければ、基本オペレーターの私としては言われたどおりボケボケの画像で校正だしするだけです。
まぁどうにかなりそうな画像ならフォトショップで加工しながら何枚か色校で提出して先方が気に入った物を使います。数百点とかになると現実的ではないですけど。
みや 2009/3/10 10:18
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
10
でかい画像を縮小で貼りこんであると、倍率の微調整がやりづらい。
実解像度の計算がしっかり出来ていれば、原寸かどうかはあまり気にしなくてもいいんじゃないかと。
Jos 2009/3/10 11:56
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7 GTB5 (.NET CLR 3.5.30729)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
11
どれだけ努力して堅実で確かな知識を身につけても、
難しい仕事に揉まれて現場で生きる技術を物にしていても、
人間、礼儀と人を敬う気持ちを欠いたらだめなんだなと、
改めて考えさせられる良スレになってますね。
鯨 2009/3/10 11:59
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
12
ラッキーアンストライク様
ご指摘・ご助言をありがとうございました。
＞あんたは言われたことを言われたとおりにやってりゃいいんですよ。それしかできないんですから。
＞ビジネスで求められてるのは、完全なデータをつくることじゃないんですよ。
他社はどうか知りませんがね。言われたら言われた以上のことをして、ミスを未然に防ぎ、完全データで入稿するのがあたりまえの出版社です。印刷会社に迷惑をかけてはいけない。
＞いつの時代の話をしてるんですか？ てか、設備投資しないんですか？ で、出力に時間がかかったら、何ですか？そんなのはあなたの会社の問題で、クライアントには関係のないことです。出力に時間がかかるなら、かからないように設備投資すればいい。
誰しもあなたと同じ環境で仕事しているとは限らないんですよ。
op様
ご助言ありがとうございました。
みや様
ありがとうございました。
＞最終がインデザインの形であればOKということなら、
いったんPDFにしてそれをまたインデザインに自動配置？をやれば無駄に重いという状況は回避できませんか？
やったことないんですが、可能かどうか入稿先に聞いてみます。
おこりん坊、あらため春は弥生 2009/3/10 12:09
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
13
これはケースバイケースでしょう。
あなたのように写真メインの仕事をする場合、それをする必要があると思います。
でも、読み物の場合、本当にそれが必要でしょうか？私は作業効率を一番に考えて仕事をします。
知っていてやらないのと、知らないでやっているのでは大きな違いがありますので、透明機能しかり、
前者であれば私は問題ないのと思います。（それを考えているのであれば）
まずは、そこをしっかり指導してみてはいかがですか？
一概にレイアウトソフトでの縮小・拡大を全否定することはできませんし、もちろん全肯定もできません。
指導も質問も言い方ひとつ。
7 2009/3/10 13:01
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322; .NET CLR 3.0.04506.30)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
14
このあたりのレスまで来てようやく全体像が見え、
僕と、おこりん坊あらため春は弥生さんは
ほとんど同じ境遇にいることが分かりました。
でも、考え方は全く違いますね。
別スレで
＞おこりん坊、あらため春は弥生さんは職場に不満があるならいっそのことラッキーアンストライクさんにリアル弟子入りしてみたらどうだろう。
と言ってる人がいるのですが、
弟子入りとかは冗談だとしても、
一度、仕事について話してみたいなぁ、とは思いました。
それでも意見は真っ二つに割れるんでしょうけど。
まぁ、おこりん坊さんからしたら迷惑な話でしょうし、
現実的に、そんなことしてる暇あったら
やらなきゃいけない仕事がやまのようにあるんでしょうが。
一つだけいえることは、
「論理的な矛盾がある仕事は、やっていて辛いだけ」
です。
ラッキーアンストライク 2009/3/12 21:38
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
15
私の職場では端物印刷が多いので、Ａ５／Ａ６程度の印刷物に1000万画素クラスのデジカメで撮ったと思われる写真がリンクされてたイラレデータが入稿されてくると、イラッとすることがあります。
というのも、10年位前のパソコンでそんなデータを寄こされた日には確実にフリーズしてましたから。
でも、ここ数年の環境変化のおかげで、そんなデータでも問題なく処理してくれるし、以前なら細部がつぶれてしまうような高解像度写真も普通にＲＩＰされてしまうようになってきたから有難いやら、今までが一体何だったのやら。
（むしろ、印刷機の精度も上がってきているから、従来の原寸350dpiだと勿体なくなってしまった）
それでも、極端なサイズのデータを送ってきたクライアントには、次回からは適正サイズにリサイズしてほしいとお願いしています。
自分からみると、この素人が〜〜と言いたくなる作業も、環境に適応してるんだって思えば納得しなくちゃならないんですかね。
よく考えてみたら、自分でもイラレにEPSじゃなく、PSDを貼り込むようになってました。
何事にも慣れろってことですね。
暇なんで、長くなりました。
失礼します。
まつもと 2009/3/13 14:45
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
16
そんなことも日常茶飯事でしょ。
縦横2000?なんて画像が、イラレ上で100?程度に
縮小されて20枚‥‥‥ なんてしょっちゅうよ。
当然、ほとんどはRGBだったりね。
単に知識もなく、ツールもソフトも持ってない御仁だとおもうけど、
早く消えて欲しいと思うのは私だけ？
JP 2009/3/16 0:33
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
17
そんなこと言われても、デザイナー風情だと画像ファイルに手を触れちゃいけないことも多々あるのですよ。
ふふん 2009/3/16 2:37
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; ja-jp) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
18
ハハハ、そういうデザイナー風情が修正を出力現場に押し付けてるのにね。
笑うよね 2009/3/16 9:40
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
19
＞縦横2000?なんて画像が、イラレ上で100?程度に
＞縮小されて20枚‥‥‥ なんてしょっちゅうよ。
今日、目にしました！
イラレ上で10％以下縮小が10枚。
それが50ページ。
とっても重たい！持ち運びもできない。
無駄無駄データだ＞＜；
誰かさんが、文句言わずに設備投資しろって・・・
んなこと言われてもなぁ〜〜＞＜；
なな 2009/3/17 15:27
Mozilla/4.0 (compatible; MSIE 5.17; Mac_PowerPC)
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
20
遭遇してしまいましたか、ご愁傷さまです（笑）
JP 2009/3/17 18:38
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; ja-jp) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
21
>JPさん
>単に知識もなく、ツールもソフトも持ってない御仁だとおもうけど、
>早く消えて欲しいと思うのは私だけ？
この先、さらに増殖すると思われます。
TBストレージも当たり前になってきちゃいましたからね。
メディアもDVDからBD入稿が当たり前とかなりそうな予感。
>>そんなこと言われても、デザイナー風情だと画像ファイルに手を触れちゃいけないことも多々あるのですよ。
>ハハハ、そういうデザイナー風情が修正を出力現場に押し付けてるのにね。
出力現場で修正してもらうにしても、バカみたいなデータを送ればパス切や修正にも時間がかかって余計迷惑ですね。
やはり、適度なリサイズは必要だと思ってます。
校正出力段階で、オリジナルデータとリサイズデータを付け合わせ印刷して、リサイズ校正の方がすんなり通ったら勝ちみたいな
まず、突っ込まれることはないですけどね。
まつもと 2009/3/18 23:01
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
22
パス切りは、
バカみたいなデータの方が切りやすかったりすることもあるんですけどね。
まぁ、なにごとも経験ですよ。
とりあえず、“レイアウトソフト”で、配置画像を拡大縮小することは、
ソフトの存在意義からして、まっとうですよ、誰がなんと言おうと。
そういうことをするためのソフトなんですから。
ただ、Illustratorって、
ソフトの名前からして、どう考えてもレイアウトソフトでないことは賛同しますけどね。
アンラッキーストライク 2009/3/18 23:36
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
23
>バカみたいなデータの方が切りやすかったりすることもあるんですけどね。
なるほど、貴重な現場のご意見ありがとうございます。
たまには自分でも試してみます。
まつもと 2009/3/19 9:21
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
24
>まつもとさん
どんな場合でもというわけではないですが、
確かに100%でパス切るよりは、
パス切ってからリサイズの方が効率がいい場合があります。
ぜひいろいろ試して、どういう場合か、ご自分の判断で見極めてください。
アンラッキーストライク 2009/3/19 21:22
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.48 Safari/525.19
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
25
ほどほどに考えたほうが良い問題だとは思いますけどね。
個人的にはイラレのバージョンにもよりますが9％以下に縮小すると再編集時に拡大されてしまう場合がある、とか、拡大すると眠くなる、とか考慮しまして、基準値を下は概ね20％縮小、上は120％拡大（画像解像度350dpi時）程度で考えております。20年も前のRIPであれば、拡大・縮小・回転などでオペレータが一晩徹夜でつきっきり作業ｗなんてこともありましたが、少なくともここ数年でリプレースしているようでしたら計算時の時間のロスは非常に軽微であると言えましょう。
切り抜きということであれば、細かい（自転車のスポーク等）商品でしたらあえて画素数を落とさず切ったほうがラクですし、何事も一概には言えないということです。
あほ 2009/4/12 22:59
Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
[4406] 旧掲示板 (2009/03/09 Mon 12:30)
