Photoshop:ヒストグラムを維持してカラーモード変更


どういう事かというと、RGB各チャンネルのヒストグラム情報をそのままCMYKで使いたい時のTipsです。

各チャンネルを複製してからカラーモード変換して、あとで悠々とアルファチャンネルを使う、でも構わないんですが、遅い上に当たり前すぎてつまんないので(またそういう事いう)
よりスマートな方法を提案してみます。RGBの全チャンネルが必要な場合、という事になりますが。

 そもそも、そういう手法の需要がどこにあるのかというと、あまりなさそうなんですけど
自分にはあったわけで。。何に使うのかは業務上のアレでちょっと。

サンプルフォルダより、アイランドガールを借りてきました。
なぜか逆光がすごいので、シャドウ&ハイライトをデフォルト値でかけておきました(冗談)

作業開始。目印として、レッドチャンネルにだけ手を加えておきます。

モード変更「マルチチャンネル」
なぜか各チャンネルの名前がシアン、マゼンタ、イエローになります。
いや、なぜかっていうか自分がわかってないだけですけども

これにチャンネルを1つ追加してやります。どんなんでもOKです。
新規スポットカラーチャンネルにする場合はカラーをK100にしてやれば自動で「ブラック」と名前がつきます。でも、どんなんでもOKです。

 なんとなく白で塗り潰しておきます。

モード変更「CMYK」。
来ました。らくがき部分はC100、MとYのチャンネルにはらくがきの痕跡なし。

レッド → シアン
グリーン → マゼンタ
ブルー → イエロー
と、チャンネルがそのまま流用された事になります。

…えーと、やったー。

ほんとに、自分以外の需要がまったく想像できませんけども。。

Facebooktwittergoogle_plus

InDesign:FitTextFrame_ j だジェー

というわけで、今週ずっと一人で勝手にもがいていたわけですが、
 ようやく「自分で使える」物になったので改めて。

これまでの経緯
1.角カチカチと辺カチカチと「フレームを内容に合わせるボタン」でフィッティングの
 結果に誤差がある事に超今さら疑問(CS3のみのバグと判明)
2.代用品たりえるスクリプトを、ふんわりと書くもバグだらけ穴だらけ(f)
3.バグをとことん駆逐するも、別に自分では需要なし(g、h)
4.保留していた類似スクリプトと相性がよかったので、くっつけてメデタシ(i)
5.のつもりだったけど欲が出て業務の書き出し待ちの時間を利用して機能付加(j)

ver_h のあたりから、毎回「これで最終」と言っていた気もしますが。。
 ジェイソンと呼んでください orz



バージョン_ j
InDesignCS3で動作確認 上位互換の可能性あり




概要
・ページ(またはスプレッド)に収まる範囲でテキストフレームをテキストにフィットできる
・フィッティングの基準点は段落揃え方向(と上下揃え)かアンカーポイントから選択
・フィッティングは字送り方向、行送り方向それぞれオンオフ可能
・字送り方向は段落内の次行送り込みが解消するまで拡張する任意オプションあり
・背面にある帯オブジェクトを、フィッティング後の文字位置に対して追随変形可能(字送り方向のみ)
 また、帯オブジェクトのみの処理も可能

フレームのフィッティングには以下の要素を考慮してある
・フレーム内マージン
・フレームの線幅
・組み方向
・段落揃え方向(最初の)
・テキスト配置方向(横組み時は上/中/下、縦組み時は右/中/左 のアレ)

逆に、認識はあるがサポートしていない要素は
・インデント
・段落上下のアキ設定
・縦組みテキスト内の無回転1バイト文字
・行頭/行末の約物(全角として扱う)
・行頭/行末の回転のかかった文字


といったところでしょうか。
 起動するとダイアログが出ます。




ラジオボタンで基準となる要素の選択、
チェックボックスは上から順に、まあ読んで字のニョ…ですが、
 2つ目の頭が落ちている物は1つ目がオンの時のみ反応します。オフでグレーアウトします。


角カチカチ、辺カチカチを疑似的に模した使い方は過去記事の通りですが、
 ここでは自分用の使い方を紹介しておきます。

まあ、こういう形で入稿されます。
 ダミー文字の入ったテキストフレームと、その背面にオビがひいてあるんです。
  …雑誌系の案件ではよくあります。



これにテキストを流し込みます。POT2で流し込みます(かるく宣伝)。
 一方は字数足らず、一方はオーバーフローです。


字数足らずの方はともかく、溢れた方はフレームを伸ばしてやらないといけませんです。
 その後、それぞれの帯をイイ感じに長さ調整してやらないといけないわけです。
作り込みが甘い。しかし、時間をかけていられないつまらない物でもある。。

テキストフレームと、必要であれば帯オブジェクトも一緒に選択してスクリプト実行。
 出現直後のチェックボックスのオンオフは極めて自分用にセッティングしてありますが
このままプリーズボタンを押します。
 はい、プリーィズウゥ


オーバーフローはなくなり、帯は字送り方向に拡張されました。やったー。


溢れていない方は帯だけで済むので一番下のチェックを入れてプリーズしてみます。
 帯だけ処理されるわけです。



また、チェックボックスをこの状態にする事で、行長だけをズンドコする事が可能です。

 場合によっては「ギョギョーム」より手軽です。
ただし、背面に半調長方形などがある場合は追随してきません(字送り方向のみとなります)。

と、字送り方向、にチェックのあり、送り込み解消にチェックがない場合、
 段落コンポーザとジャスティフィケーション設定の兼ね合いによっては
行の折り返し位置がズレます。あまつさえオーバーフローする場合があります。
 仕様です(きっぱり)



なお、テキストが中央揃えの場合は、
 先にテキストフレームを処理した時点で帯との位置関係が狂うため、
例外的に行頭方向と帯の距離差を使うようにしてあります。
 何言ってんだかわかりませんね、はい。いいですいいです。

で、ぜひ使ってやろうという方に向けて、内部処理の内訳を簡単に出しておきます。
・選択ハニーを判別。1つのテキストフレーム、
 または2つのアイテムで片方がテキストフレームなら処理開始。
・テキストフレームを複製
・それの回転をナシに
・それを行送り方向のみフィッティング
・更にページ(スプレッド)いっぱいまで拡大
・伸び切ったテキストの文字座標からフレームのサイズを算出
・複製したフレームを削除
・元のフレームを変形、回転してあれば元通りに
・帯があれば処理
・帯を回転ナシに(チェックがあればテキストフレームに与えた角度だけ回転)
・(テキストの幅+((基準となるテキストの端座標-帯の端座標)×2))÷帯の幅 ぶん変形
・帯が回転してあれば元通りに

…というわけです。
帯の種類によっては使い物にならないので、使えない例を挙げておきますと
・線幅を有する物(現状、拡大/縮小のエジキ)
・拡大するとまずい物(角
丸の実体パスの長方形など)
・中味を拡大するとまずいグラフィックフレーム
・一見縦長なのに、よく見ると横長を90°回転して使用している物
・2つ以上のオブジェクトからなる帯(それがグループになっている場合はセーフ)

…みたいな場合は、手に負えないわけです。。


では、よき下っ端ライフを!
Facebooktwittergoogle_plus

ば関数:見た目優先のアンカーポイントを使う

今週もがきまくっているFitTextFrame.jsxですが。。
 当該のテキストフレーム単体に関してはver_i 以降でまぁまぁ安定という事で。
例外的にフィットしない局面もしばしばあるですが、これは実用を重ねながら追い込むです。

個人的に問題なのがオマケ機能の「別置きしたオビの調整」。
 こっちが実用面ではメインなのですが、極度に回転してあるブツに対してかなりよろしくない。

例えばこういうコード。以下ぜんぶInDesignCS3でやりました。
左上を基準にして15°回転するテスト。


tmObj=app.transformationMatrices.add(1, 1, 0, 15, 0, 0); //15度回転するマトリクス…的な
app.selection[0].transform (CoordinateSpaces.PASTEBOARD_COORDINATES, AnchorPoint.TOP_LEFT_ANCHOR, tmObj); //左上を基準に変形


これを、



こいつらにそれぞれ実行してみますと



こうなります。 おい、岩清水。

 このせいで、帯があらぬ方向に行く事がありまして。
つーか、横長いオブジェクトを90°回転して縦組みの見出しの下にひいて寄越す奴が悪い。。
 しかも困った事にザラに見る。
CoordinateSpacesとAnchorPointは無関係みたい。ぬかよろこび。
 このへん、未だに意味のわかっていない関数 resolve() あたりが怪しいと密かに思ってるんですが。
  わかりたいんですが、さっぱりわかれません。座標系のウンタラらしいのは確かなのだが。
 とりゃえず今回は関わらないようにして(関われないので)、

なんとかする関数を作りました。


function anchorSwitch(obj, anc){ //戻り値は [新しいアンカー, 90°ごとの補正値]
 if(arguments.length<2){ //引数省略の時はウィンドウのアンカーポイントを使用
  anc=app.activeWindow.transformReferencePoint;
  }
 if(anc==AnchorPoint.CENTER_ANCHOR || anc.reflect.name==“Array”) return anc; //中央と任意座標は未処理
 var rot=obj.rotationAngle;
 var anchorAry=[ //左上から時計まわりに
 AnchorPoint.TOP_LEFT_ANCHOR, 
 AnchorPoint.TOP_CENTER_ANCHOR, 
 AnchorPoint.TOP_RIGHT_ANCHOR, 
 AnchorPoint.RIGHT_CENTER_ANCHOR, 
 AnchorPoint.BOTTOM_RIGHT_ANCHOR, 
 AnchorPoint.BOTTOM_CENTER_ANCHOR, 
 AnchorPoint.BOTTOM_LEFT_ANCHOR, 
 AnchorPoint.LEFT_CENTER_ANCHOR  ];
 var rotateVal=Math.floor((rot+360+45)/90)*2; //45は見た目対策、*2で90度ぶん
 var newAnc;
 for(var i=0; i<8; i++){
  if(anchorAry[i]==anc){
   newAnc=i;
   break;
   }
  }
 return anchorAry[(newAnc+rotateVal+8)%8];
 }


要は、90°単位でアンカーポイントを見た目優先で融通する関数です。
 引数は(対象オブジェクト, 変換を要するアンカーポイント)
 引数2を省略した時はウィンドウに設定してあるアンカーポイントが使用されます。
 戻り値は変換後のアンカーポイント。
この関数を絡めてテストするコード。左上を基準に15°回転。


var doc=app.activeDocument;
var aW=app.activeWindow;
var sel=doc.selection;
for(var i=0; i<sel.length; i++){
 var asObj=anchorSwitch(sel[i]);
 var tmObj=app.transformationMatrices.add(1, 1, 0, 15, 0, 0);
 sel[i].transform (CoordinateSpaces.PASTEBOARD_COORDINATES, asObj, tmObj);
}


実行結果




この関数のキモは見た目を優先するというところなので、
 今度は45°を境に、水平寄りの物と垂直寄りの物に振り分けて回転するテスト。
45度ちょうどの時は反時計周りが優先となります。ここだけはしょうがない(ことにしてください)


for(var i=0; i<sel.length; i++){
 var asObj=anchorSwitch(sel[i]);
 var moyoAngle= sel[i].rotationAngle%90;
 moyoAngle=Math.abs(moyoAngle)>45? (Math.abs(moyoAngle)/moyoAngle*90)-moyoAngle : -moyoAngle;
 var tmObj=app.transformationMatrices.add(1, 1, 0, moyoAngle, 0, 0);
 sel[i].transform (CoordinateSpaces
.PASTEBOARD_COORDINATES, asObj, tmObj);
 }


実行前



実行結果



できましたな。

さぁ、FitTextFrame.jsx の完成が待たれます。
 何しろ自分の手元での使用頻度の高さといったら。。すごいのだ。
完成しだい、がっつり説明します。


Facebooktwittergoogle_plus

InDesign:FitTextFrame_g

引き続き、昨日のグダグダなスクリプトを少しかなり直しました。

InDesignCS3で動作確認
CS3以上であれば問題なく動作すると思われます




ver_fは、行の折り返し解消のために「各geometricBoundsを200ずつ外に拡張する」という処理がありました。
  …はい、ほぼ一発でペーストボードの外にハミ出てしまってテキストの座標系プロパティを拾えなくなります。
 アホすぎる。
これを、ページ(見開きならスプレッド)のサイズまで拡張、としました。
 テキスト長がよっぽどでなければこれでなんとか。よっぽどの時は諦めてください。

また、ちょっとかっこいいと思って
 story.characters.everyItem().baseline.getElements().sort().reverse()[0]
などとやっていたらクソバカ重くなってしまっていました。
 昨日は4〜5字で試したので気づかなかったのです。
これも、つまんない書き方に直してそこそこの速度になりました。

あと、実行前に出るダイアログも新しくなりました。
 これでようやく自分の実用に堪えるわけ(じゃ昨日のはなんだったんだ)
画像
字送り方向のフィッティング有無、
 行の送り込み解消(↑のオプション)、
行送り方向のフィッティング有無。

とりゃえずこれで、どうにか戦って下さいまし。
 なんであれ、長方形以外では使わないで下さい。

次回、土台が安定しきった所で、ようやく肉付けを
・フレームの線幅を考慮
・フレーム内マージンも
・各行のインデントも、まあ、いちおう
・背面に別置きしたオビの追随機能
…あとないか。もうないか。ありますか。
Facebooktwittergoogle_plus