暖簾に腕押し

Aさんが他業務で忙しく、ま、代打として仕事を引き継ぎました。
一応、こうやってました的作業手順書らしきものをいただいたんで見てみたら、その手数の多さと煩雑さに仰天。
いや、指示が細かいのは大変よろしい。
でもね。これを毎回繰り返すわけ？
めんどくせー！！
たとえ1回でも嫌だわ。これは自動化するしかないでしょ。
Aさんがかかっていた時間よりもかなり早く終わらせられました。ふふん。
ふと思った。Aさんは今までこれをちまちまずっとやって来たのか。凄い忍耐力だね。あ、褒めてますよ。自分にはないものだからね。
自動化に取り組むか取り組まないかの違いって、忍耐力の有無の差なのではないかと思うときがあります。
あと、自分は時間の無駄遣いと残業が大キライなので、とにかく早く作業を終わらせたい一心で自動化している部分もあります。

でもこういったことが苦でない人は、難しいスクリプトとかの勉強をするよりはひたすらもくもく手を動かすほうを選ぶのではないかな、と。
InDesignやる人はせめて正規表現わかってたほうがよいんじゃないかなー、といくら言っても余計なお世話だったりするのでした。
糠に釘。

自動化する理由

今日はひさしぶりにIDのJavascriptを書きました。
今まで私が書いた他のもそうだけど、
「メニューからできるものをスクリプトで処理する」
という類のものです。
なんでわざわざ？とお思いになるかたもおられるでしょう。
【理由1】
勉強のため。スクリプティングそのものもですが、データの構造を理解するのによいと思います。
まあ、これはプライベートな理由です。

【理由2】
作業工程／結果を均一にする。
これが一番大きいです。
主に、他人（しかも大勢）が作業するときのためのものとして書くスクリプトです。
メニューからできるものをなんでわざわざスクリプト化するかというと、
・人によって処理が変わる（ex：AiでK100にプロセスを使うか、グレースケールを使うか）
・やり間違える
・作業モレ
これらを防ぐためです。
一人の人間が最初から最後まで同じデータを扱えればよいけれど、如何せん大量ドキュメントでは分業、流れ作業をすることになります。
そうなったとき、全員が同じ作業を同じように行ってもらわなければ困るのです。
全員が同じようなスキル（しかも高スキル）と経験値を持った人間ならば、こんな準備をする必要はありませんが。
テクニカルドキュメントならではの事情でしょうか。
作業者のスキルをアップするのと、どんなレベルの人でも作業できるような工程を考えるのと、どっちがよいんでしょう。悩ましい問題です。当然、両方を並行して行うべきなんでしょうが、なかなそうもいかないんです。
セミナーでのテーマや、懇親会で伺うお話なんかだと、一人で完結するような作業工程を前提としたものが多いんですよね・・・。

自動処理コワイ

やっちまったです。久しぶりに。

単純な作業なんですよ。
2つのpdfデータがあります。1つは本文、もう1つは表紙。
本文pdfの先頭に表紙pdfを挿入するだけなんです。
1セットだったら手動でやりますが、いっぱいあるんですね。
で、Acrobatのバッチ処理をしました。
何回かにわけて入稿されるので、来た分で検証。
表紙pdfになぜか白ページがついていて2ページになっていたので、本文pdfに挿入後、2ページ目を削除という処理を、付け加えました。
たった、これだけ。
このときはうまくいってたんです。
それなのに。

何日か経って、次の分が入稿されたので、何の疑問も抱かずにバッチ処理。
そしたら。
本文の1ページ目が消えた？？？
・・・。
表紙pdfの余分白ページがなくなっているじゃないかー！
勝手に仕様を変更するなよ・・・・。
まあね、こっちも勝手にバッチ処理でしているので。文句は言えません。
他人が作ったデータを処理する自動処理は怖いですぅ・・・。

ここ数日のわたし

• 久々にXMLの仕事をする。既に構造化されたFrameMakerデータの修正作業。ところが原稿作成者がまるで構造化文書を理解していない。無駄なところに労力を使って、大変疲れた。
• で、それとは関係なくFrameMakerの問い合わせ。テキストフレームをインラインのアンカーにしても構造上大丈夫かどうか、と。わからなかったので、そういえばFrameMakerでブログ書いてる人はいないのかな、と検索したら前の会社がヒットしてしまった・・・。あまり円満とはいえない退社の仕方だったので、辞めたあとどうなったのかはまるでわからない。執筆陣の名前を見ると（実名で書いていた）、知っている人ばかり、というか、あんたまだいたの？てな具合。しかし、あのころはまだ新人で、ほとんど私が教えたような人たちばかりが、まぁ、大人になったじゃないの。とまるで親戚のおばさん気分。結局、FrameMakerについては未だわからず。
• あちこちから次回セミナーの案内が届く。10月にいたっては、二週連続。（大阪、名古屋）さすがに両方は行けない。テーマ的に行きたいのは大阪。でもその日は予定が・・・。名古屋はカワココさんと鷹野さん！個人的に両名のファンなのだが、ちょっと腰が引けている。（すみません）なぜかというと、今月のシルバーウィークにちょっと散財する予定が・・・。11月にはDTP Boosterが早くもやってくる。こちらは参加予定。

レジストレーションカラーをグレースケールに

寺での話題。Illustratorです。

今までも、Kのつもりでなぜかレジストレーションカラーを使っているデータを見たことがあります。
［カラーを編集］では変えられないんだね。知らなかったです。
こんなときも、スクリプトならすぐに対応。

カラー関係のばかり書いているな、最近。他のテーマを見つけよう・・・。

何が必要？

今日はDTPの話ではありません。でも最終的に着地させてみせましょう。ふふ。

昔、翻訳会社に勤めていたことがあります。
翻訳コーディネータ兼DTPオペをしていたのですが、ちょっと翻訳の勉強もしたいな、と思ってベテラン翻訳者の方に指導してもらったことがあります。
そのときに言われた、翻訳者にとって必要な資質。

　「一に日本語（orターゲット言語）、二にその分野の知識。三、四がなくて五に英語（orソース言語）」

いくら英語ができても、最終的な表現方法となる日本語のチカラがなくては、文章（作品）として成立しない。
逆に英語ができなくても、その分野の知識と正しい日本語の使い手であれば、読み手にとって意味の通じるものを作ることができる。
極端に言えば、英語力だけあってもダメ。伝えたいという気持ちと、それに見合う表現力が備わっていなければダメ。
さて、何で今日こんなことを書いたかというと、とある案件の、クライアントの翻訳に対するある指摘がきっかけです。
どうやら、「High」「Low」の訳し分けの問題のようです。
何から何まで全部「高い」「低い」とやってしまってはだめなんですよ。ものによっては「大きい」「小さい」という表現にしなければならない。
※例：電圧→高い、低い　電圧降下→大きい、小さい
英語が不得手でも、電気関係に明るかったら訳し分けられるでしょう。
英語、電気関係が不得手でも、日本語能力が高ければ、降下を表すときに『高い』という表現はおかしい、と気づくでしょう。
英語しかできない人、言葉ヅラでしか仕事をしていない人には、その違いはわかりません。
翻訳って深いですよね。そう思って、その道は諦めました。

さて、DTPに戻ってきましょうか。
DTPって、何ができればヨシ、となるんでしょう。
っていうか、DTPって何？
そう思ってつけたタイトルが「What' in DTP」なんです。
「What's DTP」じゃないですよ。
DTPって何？じゃなくて、DTPには何があるの？（何が必要なの？）という気持ちなんです。
最近、セミナーやセミナー後の懇親会でいろんな方々とお会いして、ほんとーに！自分はまだまだだと痛感しております。
着地できたかな？（＾＾；）

CS4をINX保存するときの注意

以前書いて、下書きのままになっていたネタ。
ちょっとINX絡みの業務が出そうなので、曝します。

6.0.2で解消されているからもう期限切れのネタだろうか。 InDesign Secrets以外、見つけられなかったんだけど。そもそもINX書き出しの需要そのものがあまりないのか。

リンク切れしているCS4ファイルをINXに書き出すと、CS3で開いたときに次のようになるそうな。

1. プレビューがなくなり、グレーのフレームになる
2. リンクパネルが正しいファイル名でなく「fo」となる
3. 再リンクできなくなる

InDesign Secretsの事例にもあるけど、デザイナー／オペレーターに.inddファイルだけ支給して修正させるというのは、割とありがちなワークフローだと思うんだよね。
「上から下までバージョンを全て揃えるのがセオリー」、確かにその通りなんだけど、下位バージョンしか持っていない人にはINXファイルでしか支給できないわけで。