InDesign:文字の位置そのままで揃え方向を変えたい時に使うやつ


アケスケなタイトルにしてしまいましたが。。

ページのタイトル部分に、こーゆー赤字が来たとします。いや来てます。
まるきり違う番組になってますけど


で、ファイルを開いたら、このような可愛らしい作りになっている事があります。
冗談みたいだけどホントにあります。あるんです。


で、コレどうぞ


InDesignCS3以降
CS3、CS5で動作確認済み



ダイアログが出ます。
こういう事で困らされる時、たいがいデフォルト(左/上揃え)なので、
リストのデフォルト表示は逆の右/下揃えにしてあります。


とりゃえず下のチェックボックスは無視して、
目的のテキストフレームを選択して、希望の揃え方向を選択しボタンを押します。
はい押した! いま押した!


…というスクリプトです。ゴチャッとした月刊誌を多くやる人には便利なハズ。
チェックボックスがオフの状態では回転のかかったテキストフレームでも安心して使えます。
単に前後のhorizontalOffsetとbaselineを比較してるだけなので。
そういう事情でフレーム内に最低でも1文字ないと無視されます。
また、上の例のような用途を主眼としているので基準は1文字目手前の挿入点にしています。
選択ハニーはテキストフレーム限定です。グループ、文字列、挿入点すべて無視します。
 これらの仕様は、あとで自分が不便なら直すかも知れません。直さないかもだけど。


下の「可能であればフレーム位置は固定でインデント値で制御」にチェックを
入れると、フレーム移動はせずに左右インデントで元位置をキープします。
この場合は回転のかかったテキストフレームは非対応なので無視されます。
以下、使用例。

この状態から、


一旦中央揃えにしておいて、


左揃えを選択して、チェック入れてボタンカチ


やったー


※例のような用途の場合、1行目が一番文字数がある状態でないといけませんが。。
 多少このぐらいの落ち度がある方が異性のウケはいいんだそうです(本読んだ)
 

あ、誰かIllustrator版作ってください。
ちょっぴりの書き換えで済むはずなので。。
Facebooktwittergoogle_plus

テンプレ:スクリプトのかわいいねだり方



本来、基本的に人望の分厚い方が言ってこそ、な事ではありますが、
そもそもそういう人はこういう事は思ってても言わないので
(でも、思ってはいるんだ、と思っておいた方がいいと思います)
掲示板などに於けるおねだりの心得をテンプレ化しておきます。
 毎度毎度の誘導などに使って頂いて結構です。
ウチは、当然こんな事少しも思っていませんよ?
 ただ、誰かがやらねばと(以下誰も聞いてないので略)
たぶん、一番これを言ってはいけない人間である気もするんですが。。



あなたが得する、おねだりの心得

・まず、使うほうを大丈夫に
スクリプトをファイルとしてもらってきたら、入れるべき場所に入れてアプリ上から実行します。
次に、掲示板上で本文欄にダーッとスクリプトの構文を書かれたとき。
 コピー&ペーストして保存したらスクリプトファイルの出来上がりですが、
  テキストのエンコーディングは確認しましたか?
  拡張子は正しいですか?
この時点でもうわからない人は、そこまでは自分でなんとかしましょう。


・書く人/書かない人 を明確に
掲示板に寄せられる質問などでよく見かけるのが「スクリプトを使って作業していますが新たな困難が」。これを読んだ側は
これが自作の品で逐一調整しながら使用しているのか、他者の作品で自分は実行に徹しているのか、わかりません。
あなたがスクリプティングを勉強中で、極力自力でどうにかしたい中での助言を求めているのか、
それともカチカチするだけで幸せになれる完成品を求めているのか、そこははっきりさせた方がいいです。
回答者および提供者は、自分が過去に覚え始めた頃の、さっぱりまったくわからなかった時期の辛さを覚えています。
 また、これから習得しようとする方に提供するハードルの高さ加減も心得ています。
あなたが「明日からやってみようと思っている」程度であれば、「スクリプト初心者です」とは言わない方がいいです。
 提供されるスクリプトは、途端に出題形式へと変わります。
覚悟しましょう。


・状況説明、要求をしっかりと
土台となるドキュメントの状態、要求する処理内容がホンワカ曖昧なのでは回答者は何もできません。
わりとよくある光景が、要求に答える前に「それはどういうこと?」という訊き返しが発生したり、
見当違いのスクリプトを書いて押し付けてしまったり…すみません全部自分のことです orz

要点
 とにかくOSとバージョンは必須。
  服が欲しいなら性別とサイズは絶対不可欠なように(ユニセックスなスクリプトもありますが)
 可能であれば画像を添付して頂ければ伝わりやすいです
 マニュアルに載っていない俺用語は混乱を招くので極力使わない。不勉強の露呈にも繋がります
 別の意味にも読み取れる文章になっていないか、条件に書き漏らしがないか確認しましょう
  〈例〉スクリプトを教えて → 学習支援募集かブツだけ欲しいのかはっきりしない
     画像を順番に配置したい → どういう順番でどういう並び?
     グリッドに → 何グリッド?


・方法論を自分で限定しすぎない
作業に対しての最終的な要求があったとして、
そこまでの工程を自分一人で小さくまとめてしまわない方が無難です。
回答者の中には、いい意味でズル賢い方がたくさんいます。
差し支えなければ、任せてしまった方がいいです。
まわりくどい手段を自動化するよりは、もっと単純な良い方法を示してもらえる場合もあります。


・そして単刀直入に
「スクリプトでできると思うんですけど…何かいい方法があれば教えてください」と書いたとします。
スクリプト以外の手段で済むならそれに越した事はないが、という謙虚な気持ちが書かせる表現ですが、
多くの場合、過去に同様の需要があって(またはそれを想定して)作られたスクリプトを提供するわけですが
スクリプシャン各位は、
 自作の既存のスクリプトがあるが、細かい部分に不満があり書き直してしまう
 他者の既製品があるが、自己研磨の一環としてイチから書いてしまう
などの事情から、ついうっかり今回のためにわざわざ書いてしまう事がしばしばあります。
あればいいなあ、なければ諦めます、的な弱い姿勢では、回答者も書いていいのかどうか迷ってしまいます。
あったら教えて、なければヒマな人書いてみて、ぐらいの前向きさを出すべきです。
そこまでは頼んでいない、大きなお世話だ、と思われるかも知れませんが、
スクリプトはそうやって発展しているのです。誰にも止められません。
今回の為に見ず知らずの方がわざわざ喜んで書いてしまう事は恒常的に起こりますが、
それについては遠慮も躊躇もせず、ズバッと頼んでしまって下さい。
奥歯に物の挟まったような文言は、逆に失礼にあたります。空気読めとかやめて下さい。


・それでいて謙虚に
スクリプトの多くは、ネット上に転がっていてタダで使う事ができます。語弊を含んでいますが。
ソースコードの文字列さえ手に入れば手元で作れてしまいます。
料理ではなくレシピであると言えます。いや呪文?
ま、ま、とにかく基本タダです。
「どっかにタンポポ生えてるとこない?」ぐらいの気持ちで探す事ができます。
まあ、いくらむしっても減らないタンポポなので、踏んだり首チョンパして遊んだり…はしないにせよ、
そのタンポポは自生している物ではなく、一つ一つがハンドメイドである事はおわかりますね。
スクリプトが既製品であれオーダーメイドであれ、人の手の温もりは感じてあげてください。
媚びろと言っているわけではありません。
ただ、その場では機嫌をとってあげた方があなたにとって得な結果が生まれるでしょう。
また、その時助けてもらった協力者に以後まったく関わらない可能性は低いです。
えーと、ちゃんとしましょう。
大丈夫です。気持ちさえあれば、あとはほっといても文面にはそれが出ます。逆も然りです。


・ほこさき
ネット上に転がしてあるタダのスクリプトの置き場所を教えてくれた人が優しい人ですが、
ネット上にスクリプトをタダで転がしてくれている人の事も忘れないで下さい。
拾ってきたスクリプトを改変したい旨、自分の持ち物のような扱いで申し出て来る人もいますが、
その掲示板、たいがい作者さん本人ちゃんと見てますから。恥をかかないように気をつけた方がいいです。


・仕上げに、かわいく、かわいく(省略可)
一般に、一部の例外を除いては
おねえちゃん > おにいちゃん > おばさん > おっさん
の順でかわいがられます。うまく利用しましょう。
掲示板で老若男女をアピールできるのは大きく二つ。文面とハンドル名です。
文面は、いくらおねえちゃんといっても、あまりギャルッとした書式は控えましょう。素朴っぽいのが好まれます。
 業界に棲息する人材の多くの好みの問題から、
 隙だらけで警戒心がなくて純情で無邪気で、粉っぽくない方がいいです。
ハンドル名は、あ
まりファンシー寄りだと嫌われます。
 北欧の、友達が少ない病気がちの子を思わせる意味不明の横文字がいいでしょう。
もちろん、実際にあなたがヘソの周りに毛の生えているような方であっても、これは通用します。
 積極的に狙っていきましょう。掲示板はその場の第一印象と後味とモチベーションが全てです。


以上の点をふまえて、掲示板でホットなスクリプトをゲットしましょう。




…すいません、責任とりません。
Facebooktwittergoogle_plus

InDesign:move()メソッドの思い違い

InDesignでオブジェクトを移動するにはmove()を使いますよね。使うんですよ。
 Illustratorだと left だの top だの使えば左や上を基準にした座標値で指定できるんですが。
それの代用として、geometricBoundsを書き換えた配列に置き換えたりしていると、いつか痛い目を見ます(見てます)。
 が、move()には魔物が棲むという噂が絶えないのであります。バグだバギーだバギーちゃんだ、言われてます。

なんかしっくりこなくて、オブジェクトモデルビューアで説明を見直した。
 こう書いてある。


PageItem.move (to:any, by:Array of number) 
Moves the ^Object to a new location. Note: Either the ‘to’ or ‘by’ parameter is required; if both parameters are defined, only the to value is used.
to: Data Type: any 
The new location of the ^Object,in the format (x, y). Can accept: Array of 2 Units, Spread, Page or Layer. (Optional)
by: Data Type: Array of number 
The amount (in measurement units) to move the ^Object relative to its current position, in the format (x, y). (Optional)



ま、↑それはどうでもいいとして(よくないが)
 上記の流し読み、及びmove()メソッドの用法間違い、書式間違いによるエラーメッセージにより、
こういう使い方↓だと思ってたんですが


 pageItem.move(e1, e2);
 第一引数 e1には“to”“by”が入る。“to”だとe2で指定した座標に移動。“by”だとe2で指定した距離を移動
 第二e2には[x, y]で移動値を入れる
  で、“by”は思ったとおりに動くけど“to”を入れても“by”と同じ挙動になるなあ、
  試しにe1を省略したら“to”っぽく動いたからヨッシャこれでいこう



↑これ、まるっきりの思い違いでした。違うんです。いやとっくに知ってたらすいませんけど。そう思ってたんだからしょうがない。
 あっちこっち覗いてきた中、同じ思考の方を散見したので、現状自分でわかったぶんだけここにまとめておきます。
まだ思い違いがあったら指摘して頂ければ結婚してください。

とりゃえずモノグサせずに、ちゃんとビューアの説明を読み解く。たぐいまれな英語力で。


PageItem.move (to:any, by:Array of number) 
俺訳:(to:てきとう, by:数値の配列)
Moves the ^Object to a new location. Note: Either the ‘to’ or ‘by’ parameter is required; if both parameters are defined, only the to value is used.
俺訳:オブジェクトを新たな位置に移動する。 のて:”to”か”by”が必要となる(←だまされポイント)。
もし両方とも指定されていたら、”to”の分だけ使われる(←おかしいかもポイント
to: Data Type: any 
The new location of the ^Object,in the format (x, y). Can accept: Array of 2 Units, Spread, Page or Layer. (Optional)
俺訳:データ型:なんでも
(x, y)形式で、オブジェクトを新たな位置に移動する。 入れられる物:2つの単位の配列、スプレッド、ページまたはレイヤー(たこ)
by: Data Type: Array of number 
The amount (in measurement units) to move the ^Object relative to its current position, in the format (x, y). (Optional)
俺訳:データ型:数値の配列
(x, y)形式で、オブジェクトの元の位置から定規の単位に即して移動する(たこ)



‥というわけです。
単にpageItem.move([10, 10]); とした時は、[10, 10]は第一引数として扱われるので上記の俺訳の通り、ドキュメント上の[10, 10]の位置にドビッと移動する。
pageItem.move(“by”, [10, 10]); とした時は、第一引数“by”は何の意味もなくなり「なんじゃそらペッペッ」と無視され、第二引数の[10, 10]は上記の俺訳の通り、現在地から[10, 10]ぶんプリッと移動する。
つまり、一所懸命“to”とか“by”とか入れてもぜんぜん意味がなかったわけです。あー恥ずかしい。
 同じ事を思っていた方は、“to”と “by” 以外の何か、なんでも入れてみるといいです。
pageItem.move(“Google”, [10, 10]); とか。なんでもいいです。“by”だと思ってた挙動をするはずです。


ここまでのまとめ:
配列[x, y]
オブジェクトの座標指定に使いたいなら第一引数に、
オブジェクトの移動量に使いたいなら第二引数に入れればよい



で、俺訳を振り返る。
if both parameters are defined, only the to value is used.
もし両方とも指定されていたら、“to”の分だけ使われる(←おかしいかもポイント

試すべく、pageItem.move(activeDocument.layers[0], [10, 10]); としてみた。 
 額面通りならレイヤー移動だけして座標は据え置くはずが、レイヤーは移動せず座標が移動した。
矛盾してるじゃんすかよう。
 ここが先様の書き間違いなのか、ウチの思い違いの思い違いなのか、どっちか。
たぶん前者だけどここは謙虚に卑屈に。嫌味に。

次。
第一引数と第二引数、配列の説明が少しちがうこと
to: Array of 2 Units
by: Array of number
toの方は単位つき文字列なんかオッケーでbyの方は数値の配列限定なの?
 という事で以下の2つ試したんです。記憶だけで書いてるから単位ちがうかも。
pageItem.move([“10mile”, “10yard”]); 
pageItem.move(“Google”, [“10mile”, “10yard”]); 
 結果、どちらも指定分だけ指定単位の座標および距離で動いてくれました。
これは気にしなくてよかったようだ。

pageItem.move() 大まとめ
以下、duplicate()もまったく同様です。お〜まちさんよりご指摘いただきまし
第一引数には「移動先」を、第二引数には「移動量」を渡す。
第一引数に用事がある時は、渡す引数は1つにしなければならない
第二引数に用事がある時は、第一引数になんでもいいから入れておけ
・よく見る「pageItem.move(“by”, [10, 10]);」の“by”は、リファレンスの文中にある“to”, “by”とはまったくの無縁。
 たぶん、File.open(“r”); 的な物との混同による誤用なのだと思う。
 ただ、何を入れといてもよい第一引数への埋め草としてわかりよく、という意図で“by”と入れておくのはアリかも。
“to”を入れても指定座標に行かないんですー、は論外。問題外。対象タト。マイトガイ。


ここまでで、思い違いがあったら指摘して頂ければあなたの子を産むわ。
 とりゃえず、スクリプシャン各位よりも、5000円以上もするリッパな本を出している先生には特に認識して欲しいところではありますが。買ってないくせにこういう事言ってすみませんけど。。

Facebooktwittergoogle_plus

IFA_id/読み物


お時間があればぜひ読んでもらいたいです。

昔、地元の某大型スーパーの一角に、かわいい文房具を揃えた売り場がありました。確か「原宿ノートハウス」と看板がついていたように憶えています。うわー恥ずかしいみっともないダサい。


それができた当時、小学校中〜高学年のウチの姉は足しげく通ってはイラスト入りのノートや香りのいい消しゴムなんかを買い漁っていました。
売り場の片隅には「オリジナルグッズ作る屋さん」のカウンターがありました。カウンターといっても駅前の宝くじ屋さんぐらいの規模ですが。
 つまり、描きしろのあるプラスチック製品、下敷きやキーホルダーなどに自分のオリジナル図案を入れられるサービスでした。カウンターにはブスなお姉さんが座っていて、作りたい旨申し出ると備え付けの紙と鉛筆を差し出し、図案を描けと促すのでした。
姉は、せいぜいファンシーなキャラクターを描き、周囲にはハートだの星だのをちりばめ、図案の完成を見るやお姉さんに手渡します。
受け取ったお姉さんは、カウンター内で商品の無地部分にハンディルーターを構え、図案を丁寧に模写して出来上がり。
…このシステムを「自分の草案をキレイに仕上げてくれて嬉しい」と見るか、一生懸命ひねった微妙なタッチ、繊細なラインが全てマルかいてチョンにならされてしまって悔しい、と見るか、それは人それぞれなのですが、少なくともウチの姉は満足そうでした。しかし血の繋がっているはずのウチは全く逆の考えでした。

そのような感情を抱いたまま、イザ印刷業界の末端工程現場に足を踏み入れてみたら、あの日のイヤな感じの作業が毎日当たり前のように行われていたわけです。おおいやだ。しかも、自分がマルかいてチョンする側に立つとは。。


DTPという枠の中では、デザイナーとオペレーターはほぼ同じ道具を使います。これは周知です。しかし、作業コンセプトはやっぱり全然ちがうわけです。何を今さら、と言われそうですけど。
それでも、ひと昔前はまだ納得の行く理由がありました。カラー原稿があり、デザイナー側でてきとうにスキャンした荒画像用でレイアウトを組みカンプを作り、出力屋は改めて印刷品質の解像度で色分解を行い、同じ位置に貼り込む。これなら諦めもつきます。実際ついていました。
今はどうでしょう。写真素材はほとんどのほとんどが、のっけからデジタルデータです。
デザイナーは最初から最終工程に持っていける画像を手にしているわけです。
それをわざわざ、解像度落とす、回転かけながらトリミングする、ファイル名もテキトウに変える(基本、出力屋側は画像のトリミング、直角以外の回転は御法度の所がまだ多いのではないでしょうか)。
その気持ちもわからなくはないのですが。。大きさのバラついた被写体をページ上に同じ大きさで並べる為には、余白を等間隔にトリミングする方法が安直にして手っ取り早いのでしょうし、絵柄の水平・垂直を取るにもPhotoshopの定規ツールが最強の安直ツールですから。後工程に配慮があろうとなかろうと料金は変わらないわけで、だったら軽く速く済ますのは当然でしょう。ウチだって自分がやるならそうします。
ただ、それを受け取った側は本気でたまったもんじゃないわけです。

手間ヒマかけて作ったおいしそうな食品サンプルと同じ料理を作らなければならない…いや違う、もっとひどい。食べ物を材料にして作った食品サンプルと同じ料理を作る、です。
解像度さえ落としてくれなければそのまま使えるデータなのに何する者ぞ、です。おそらく何かケツを持ちたくないとかいう理由でそうする慣例があるのでしょう。
…たぶん。

このIFA_idは、20世紀の製版工程(色分解の倍率出し)をヒントに考案されました。デジタルの仇をアナログの技で討っています。
ちょっと気持ちがいいというか、この時代に及んでアタリ画像と実画像の差し替え工程をあって当たり前と思っている連中のハナを明かしてやった、業界に対するザマミロ感があります。
この思いに共感して頂けるだけでも、ちょっと嬉しいのですが。
どうもお目汚しでした。

リファレンスマニュアル トップページへ

 

Facebooktwittergoogle_plus