DTPab

DTPにまつわるあれこれ

ちょっとした宣伝というか告知

DTPの勉強会(東京)に登壇

f:id:uske_S:20170924180614j:plain
【DTPの勉強会 第26回】開催のお知らせ&参加受付 - DTPの勉強会(東京)

まさか自分が…というのが正直なところですが、DTPの勉強会で登壇することになりました。僕なんかよりもスクリプトに詳しい方はたくさんいらっしゃるなかで、このようなお話をいただけたことは本当に光栄です。
開催概要、参加申し込みは上記勉強会のサイトからご確認ください。

セッションの概要

「品質を担保するためのInDesignスクリプトの紹介」
と題したセッションです。
スクリプトというと「作業の効率化」が注目されがちなのですが、例えばプリフライトのようにデータチェックを自動で行うという「データの品質担保・向上」といった使い方もできます。今度のセッションでは、そうしたスクリプトの紹介を通して、どのようにInDesignのデータを制御するのかお話したいと思っています。

登壇予定の方々

一方、一緒に登壇する予定のお〜まちさんは、スクリプトのもう少し基本的な事柄や本質的な部分についてお話くださるようです。
僕自身、お〜まちさんの「ディザInDesign」にはとてもお世話になっており、こうして同じ勉強会で同じところに立てるというのは、本当に感激です…。

また、DTPerのスクリプトもくもく会を共催しているこうちゃんのセッション「バージョン管理システムの概要と使い方」は、直接スクリプトを作るとか使うという話ではないかもしれませんが、特に業務の進行、スクリプトやデータ管理においてヒントになると思います(僕も詳細は分からないので楽しみにしています)。

僕はこのような場での登壇は初めてになります。至らない点もあるかもしれませんが、よろしくお願いします。ぜひご参加ください。

DTPerのスクリプトもくもく会#4を開催

dtpmkmk.connpass.com

隔月開催のスクリプトもくもく会#4を、11/4(土)に開催の予定です。皆さま奮ってご参加ください。
この記事公開時点(2017年9月24日18:00)ではまだまだ空きがあります。
もくもく会は、やりたいこと・作りたいスクリプトを同業の人たちと集まって作業しようという会です。その中で「この処理がうまくいかない」「もっとうまい書き方ないかな?」という疑問やコーディングのヒントを、一緒に参加しているメンバーと雑談しながら解決していく場にできたらいいなと思って開催しています。
全くスクリプトを作ったことがないという方も過去にいらっしゃいました。もちろん、「もくもく」できる何か(第一歩としては書籍やウェブのスクリプトの写経がいいと思います)とPCは最低限持ってきていただきますが、それらさえあれば、これからスクリプトに踏み出したいという初心者の方もOKです。
正直、僕がスクリプトを始めた頃にこんな会があれば良かったなと思っていますw

10月の勉強会、11月のもくもく会スクリプトのイベントが続くので、趣味がスクリプトになっている僕としては10月は楽しくも忙しい月になりそうです。
皆さまのご参加、お待ちしております^^/

もくもく会#3まとめ

  • はじめに
  • 会場について
  • モニターを使った発表
    • CEPとSUI(こうちゃん)
      • SUIで生成するフローティングウィンドウ
      • CEPで生成するフローティングウィンドウ
      • コールバック
    • スクリプト作成のためのスクリプト支援(kmutoさん)
    • Grepクエリマネージャ(自分)
  • 補足
    • CEPとSUI
      • CEPのインストール
      • SUI
      • JSON
    • オブジェクトモデルビューアのファイル
    • Grepクエリマネージャ
      • ダイアログを半透明にする
      • Undoを記録せずに処理する
    • 質問への対応
      • 単位換算関数
      • 単位設定を統一する

はじめに

もう1週間以上経過してしまいましたが、やっと開催報告です。
DTPerのスクリプトもくもく会#3、盛況のうちに無事終了いたしました。ご参加くださった皆さま、ありがとうございました。
今回は大型モニタをお借りできたということもあり、僕も含めこうちゃん(@macneko_ayu)、そしてkmutoさんがモニタを使って発表を行いました。
ただ、本来「もくもく」したかった方には煩わしかったかもしれません。そこは少し反省しつつ、たまには(といってもまだ3回しか開催してないですが)こういうスタイルも面白いな、とも思いました。

会場について

今回の会場は株式会社YUIDEAさん(http://www.yuidea.co.jp/)をお借りしました。実は今年になって合併によって社名が変わったそうで、元を辿ると株式会社シータスさんだそうです。シータスさんといえば、言わずと知れた古旗さんのご著書で僕もお世話になりました。

この書籍の出版に携わったシータスさんの方が実はもくもく会のメンバーとしてご参加くださっており、今回はそのご縁があって会場をお借りできました。この場を借りてお礼申し上げます。

モニターを使った発表

CEPとSUI(こうちゃん)

先述の通り大型モニターをお借りできたということで、まずは主催のこうちゃんより、CEP(CC2015以降対応のエクステンション)とSUI(スクリプトユーザーインターフェイス)の違いを発表がありました。「背景を透明に」の件のあのエクステンションスクリプトを元に、ふたつの構造の違い、コードの違い等を簡単に説明してくれました。

SUIで生成するフローティングウィンドウ

SUI自体はAdobeのアプリケーションで共通で利用できるユーザーインターフェイスです。基本的には、同じコードでInDesignIllustratorPhotoshopなどで利用できます。
さて、SUIで生成できるフローティングウィンドウですが、Windowオブジェクトをadd()する際の第一引数にそのウィンドウタイプを文字列型で渡します。使えるのはdialogpalettewindowで、dialogの場合はウィンドウがモーダル*1なります。
(詳しくは補足・SUIを参照)

CEPで生成するフローティングウィンドウ

CEP(エクステンション)で生成できるウィンドウは、HTMLとCSSインターフェイスを生成し、ほかのアプリケーションのパネルと同様に折りたたんだりドッキングしたりすることができます。
インターフェイス生成の注意としては、CSSの扱いがどうやら本来のブラウザの実装とちょっと動き方が違うらしく、ピンポイントで上書きするようにclassに仕込んでいました。

コールバック

SUIで作ったものは、インターフェイスを搭載したというだけでその実はスクリプトです。アプリケーション内で取得した情報を比較的容易にSUIに反映できます。
一方のCEPは、エクステンションとして動作させるmain.jsと、スクリプトとして動作させるjsxファイル(今回のCEPではhostScript.jsxというファイル)との間で、コールバックを設定してあげる必要があります。JavaScriptにおけるコールバックの説明自体は時間の都合省いていましたが、要するにスクリプト側(jsx側)で受け取った値をエクステンション側に反映させるための受け渡し処理です。
文字列型しか受け渡しができないことに注意してください、とのことでした。

スクリプト作成のためのスクリプト支援(kmutoさん)

続いて、Re:VIEWのkmutoさんが「スクリプト作成のためのスクリプト支援」と題して発表してくださいました。こちらでそのスライドも共有していただいてます。
スクリプトから検索置換を使うことは、特にInDesignでページ物を組むことが多い場合にはよく使うと思います。その現在の正規表現検索窓の設定を、スクリプトの記述に合わせて書き出すという、スクリプト制作者向けの支援スクリプトについてです。
特に面白かったのは、スライドにもある通り「U+E00B」という文字の扱いです。
検索置換パネルに登録する場合、文字・段落スタイル等は文字列かスタイルのオブジェクトそのものを渡します。それがグループにネストされているスタイルの場合は、例えば下記のように指定せねばならないところ、「U+E00B」でスタイル名をつなぐだけで指定できるというものでした。

//段落スタイルグループ「foo」の中の段落スタイル「hoge」を設定する場合
app.findGrepPreferences.appliedParagraphStyle = app.documents[0].paragraphStyleGroups.item("foo").paragraphStyles.item("hoge");
//これが、U+E00Bで挟むだけで済む!?
app.findGrepPreferences.appliedParagraphStyle = "foo"+"\uE00b"+"hoge";

これは衝撃です…!
ただ、kmutoさんによればこれも万能ではなく、TextやGrepでは大丈夫でも、オブジェクト、それもChageObjectでは使えないそうです。

Grepクエリマネージャ(自分)

kmutoさんがスライドの5枚目で僕のスクリプトに言及してくださっていたので、そのスクリプトをちょっとだけご紹介しました。前にツイートしていたものなので、その時のツイートだけ掲載しておきます。


ま、いまはこれを組み直しているので、もう全然違うインターフェイスになりつつあります…^^;;

*1:表示中はアプリケーションの操作ができない状態。反対にウィンドウを表示していてもアプリケーションの操作も可能な、所謂フローティングウィンドウ的なものはモーダレスダイアログ/モーダレスウィンドウといいます。

続きを読む

字形パネルの妙

今回はスクリプトではなくて、字形パネルの挙動が面白かったのでご報告です。
知っている方もいるかもしれませんが(そしていらっしゃったら詳細をお教え願いたい)、字形パネルの挙動が合成フォントの場合にちょっと変わった動作になるようです。
百聞は一見にしかずということで、まずは下図のようなデータを用意しました。
f:id:uske_S:20170905121537p:plain 左側はリュウミンPr6で組んだもの。対して右側はリュウミンPr6だけど合成フォントにしたもの。見栄えは同じですが中身が違う、という状態です。
f:id:uske_S:20170905121551p:plain この状態から、字形パネルを使って字形を変えます。今回は末尾にある全角字形の「c」を「⒞」にしようと試みました。
まずリュウミンPr6の字形パネルを参照します。
f:id:uske_S:20170905121712p:plain Unicode:249E
となっていますね。今度は合成フォントの方でも同様に字形パネルを参照します。
f:id:uske_S:20170905121758p:plain Unicode:FF43
となっています。

ではこの通り2つとも字形を変換してみると…。
f:id:uske_S:20170905121815p:plain 合成フォントの方はU+FF43(要するに「c」)のまま「異体字」としてハイライトされ、リュウミンの方はバッチリとコードポイントが変わっています。

これ、例えば正規表現スタイル等で問題になり得ます。
この例で言えばU+249Eを直接指定する正規表現((?<=\x{249E}). 等)だけでなく、正規表現スタイルの条件を「⒞」とした場合でも、右側の例ではコードポイントが変わっていないので正規表現スタイルが適用されません。正規表現スタイルはどうやらコードポイントを元に判断しているらしいからです*1
また、分かりやすいところではInDesignからテキストを二次利用した場合も問題になり得ます(テキスト化した際、異体字が基底文字に戻ってしまう)。
ただ、こうした字形パネルの挙動は、バグというよりは僕は仕様のような気がします。
(ちなみにCS6〜CC2017のバージョンで同様の動きを確認しました)

合成フォントかそうでないかを意識しながら字形パネルを使い分けるというのは、自分にはなかなか面倒です…。
文字(字形)を変換する際、目的とする文字の字形(CID・GID)を変えたいのか、コードポイントを変えたいのか。これを念頭に置きながら、字形パネルや検索置換を併用して作業しなきゃな…と改めて思ったのでした。

追記(2017年9月5日23:34)

やな推測だな - 実験る~む
あさうす(@assause)さんからコメントいただきました。この記事での検証はCS3ですが、「合成フォント機能は外部のCMapファイルを使って字形情報の処理をしている」というものです。
今回の件も似たような事例なのでしょう。なんとなく筋は通る気がします。

*1:過去の記事「OS間で気をつけるべき正規表現」などを参照