しあわせにつつまれたまりーるいーず、
latest AFTERWORDS. || [2676.06.21.火.] > [2676.06.27.月.] [THIS PAGE.]
2676/06/27 21:35:43 [UPDATED.]
[2676.06.xx.] [SUBSTANCE.]
[2676.05.xx.] [SHORTCUT.]
SILENCE. / FORCEWORD. / list of AFTERWORDS. / MAIL. [OTHERS.]
[FEED.]
ゆきとさん / あすか / 妄想 / 志保ちゃん / huginn / markun壱 / mwa / nA / らいら / まこぴー [ANTENNA I.]
朝館 / ふにふに / kan / しあわせさがし / 杉田さん / 湯茶 / モラトリ / ゆんゆん / take-w1 / BLUE / then-d's / REV / fana / SSS [ANTENNA II.]
お知らせちゃん type-N [ANTENNA III.]
EWACS. type-T / type-F [PHOTOS.]
キッズgooはじかれサイト同盟 / mixi / Twitter / pixiv / Circle.ms / 体調不良部 / 庭には二羽 / NH3 / 飴玉魔力 [BELONG.]
通信販売のご案内 [SEKIGUCHI.]
おりくらはじめ / る印 [AUTHOR.]


[2676.06.27.月.]
[2676.06.27.月.] / 大宮ソフト/任天堂「カルドセプト リボルト」 / 『Wasshoi!ニンジャスレイヤーテレビジヨン祭り!!』のこと。
大宮ソフト/任天堂カルドセプト リボルト
 発売は07月07日なんだが、もう決済できる&ド頭のところが遊べて製品版にデータが引き継げる体験版「カルドセプト リボルト スタートダッシュVer.」が一緒に手に入る、ということで‥‥‥MOTHER2が終わってカレントのゲームが途切れてることもあり、DL版の決済を済ませて、体験版を弄り始めたところ。
 早速、ストーリーモードはここまでしか遊べませんっていうところまで既に到達しており、そういう意味ではクリア済み。あとはストーリーを適当にやり直したりとか、フリー対戦をやったりとか、そうして得た報酬で取り敢えずカードパックを買ってみたりとか(製品版じゃないとデッキの編集ができないのでカードを持つこと自体に実質意味がないが、レアリティがNのカードを買い増すことは可能)。

 前作の発売日が2012年06月28日だから、奇しくも今日でちょうど4年が経過、明日から5年目っていうタイミングだったらしいけどまあそれはそれとして、やってなかった時間があまりに長いため、もう遊び方のコツとかカードの内容とかほとんど覚えてないのが結構困ったところ。まあ案の定プレイング間違える間違える(苦笑)。前作やってた頃だって決して安定はしてなかったプレイングがブランク分だけしっかり錆びついてて酷い有様。取り敢えず頻出カードの内容を憶えるところからまた始めないと。
 そして、確か「あとマップ1枚2枚」くらいまでは攻め込んだものの、結局前作ではストーリーモードを解ききるところまで行ってない件も鑑み、いま改めて、この2つのリンクを貼り直す。
 今度は解きたい。その上で、可能なら周辺にプレイヤーを増やして、対人戦も遊んでみたい。
 ああ、何だったらリボルト製品版が来るまでの間隙を縫って、残り数マップを抜くまで頑張る、っていう手もあるなあ‥‥‥。
 そう、「はじめてカルドセプトをする人へ」の『戦闘のコツ:憶えておくのは「敵のアイテム」』にある
でも参照したい時に参照できない情報がある:それが「敵の手札」だ。
 という点に関しては今回、地味だけど劇的な変更が施され、全員の手札の名前を常時確認できるようになっている。‥‥‥いるのだけど、とはいえ手札の「名前」しかわからんというか、効果までは確認できない仕組みになってるので、結局のところ、せめて頻出カードの効果くらいは名前見た時にぱっと思い出せないと、せっかくの変更が活かされないよね、という側面もあるのだった。

 そういえば今作、ダイスが大きく変わってる気がする。
 歩数を決めるダイスは、確か前作は普通の6面ダイス1個(「フライ」使って2個)だったと思うんだけど、今回は、6の目が「C」のロゴでマスクされた6面ダイス2個になってる。ふたつ振ったダイスの片方がロゴの目だった場合、ロゴの方は「0の目」として計算されるらしい(つまり、普通6面ダイスは「1〜6のいずれか」が出るが、このゲームの6面ダイスは「0〜5のいずれか」が出る)が、両方ロゴの目だった場合に限り、両方とも「6の目」として扱われ、12マス進むことができる。
 ちなみに、「フライ」を使うとダイスを3個振るけど、全部ロゴの目だったら18マス進む、のかどうかはまだわからない。
 敵キャラが「フライ」使ったのに「C」「C」「1」で1マスしか進めなかったところは実際に目撃したけど。‥‥‥あれ気の毒だったのは、自分に掛かった「ホーリーワード1」をキャンセルするために「フライ」を使って、固定1からダイス3個に変更したにもかかわらず、そのダイス目で1が出ちゃったので、結論からいうとその「フライ」は使っても使わなくても一緒でしたね、って点なんだよな。しかも、敵が何故そこで1を嫌ったかというと、1歩先は僕の所有するレベル4地形であり、対抗手段がないのも目に見えていたからなんだけど。超・ごちそうさまでした(w。
2016/06/27 09:45:18
Wasshoi!ニンジャスレイヤーテレビジヨン祭り!!』のこと。
 この字面を係名として応募ハガキの宛書きに書かせるというジゴクめいた所業にヘッズ戦慄。
 いきなりペンで一発書きが成功したのはラッキーだった‥‥‥。

 というワケで、大分遅きに失した感はあるものの、今日の昼休みに応募ハガキを作成した。帰りに適当なポストに投函すれば申込は成立するであろう。
 ちなみに、既に電子版持ってるにもかかわらず、物理書籍のグラマラス・キラーズ急に3冊纏めて買ったりしてるのは、この応募ハガキを作るのに、応募券の付いた帯が複数枚必要だったから。
 ‥‥‥電子書籍のデメリットはこういうところにもあって、つまり「確かにその本を買いました」っていうことのエビデンスを提示するのが難しいワケね。
 あらゆるデジタルデータは捏造リスクと隣り合わせであり、そこを抜きにしてエビデンスを提示するとしたら、本人確認の上で、特定書籍に対する決済を実施したことを証明する資料をベンダから相手に提出させるとか、何かそういう小難しい手続きの話になっていく。
 これが物理書籍なら「本に付いてる帯の一部を切り離せば応募券になります」で済んじゃう。いやまあ、帯だけ万引きするとか、何だったら本ごと万引きするとか、そういう手順によって不正に得ることもまた可能になっちゃう部分は電子書籍では考えにくくて、そういうあれこれまで含めた話としては、どっちがいいとも悪いとも簡単には言えないんだけど。
2016/06/27 16:23:15
[2676.06.26.日.]
[2676.06.26.日.] / 偽DTPオペレータ部活動。
偽DTPオペレータ部活動。
 昨日買ったろんぐらいだぁす!(7)特装版」のCDメディアから音声データをリッピングしたり、昨夜の考えごとについて引き続き首を傾げたり、昨夜遅くにサンプル投げた反応に従って7月案件の本文フォントを変更したり、比較的穏やかに過ごす。
2016/06/26 18:07:04
[2676.06.25.土.]
[2676.06.25.土.] / 流浪。 / 偽偽DTPオペレータ部活動。
流浪。
 東京駅で森原せんせと合流。
 本題の受け渡しを手早く済ませた後、秋葉原に移動して何軒か本屋巡り。
 正直、「触手の描き方」以外は電子版全部押さえてる本なので、特に事情がなければ物理書籍とか買う必要ないところなんだけど。
 ろんぐらいだぁすは特装版のメディア目当て。
 グラマラス・キラーズはドラマCDキャンペーン応募用の帯が都合3枚手に入りさえすれば組み合わせは何でもよかった。そういう意味でベストなのはまだ電子に来てない「ニンジャスレイヤー殺」の1〜3それぞれに帯が付いてることだったんだけど、殺だけ講談社のコミックスだからなのか、殺の12にキャンペーンの帯が付いてる状態の本がどこにも見当たらず、だからといって3だけ3冊買うのも変な話なので、まあ「3冊で終わってる」ものを。
 触手のソレはつい出来心で。買ったからナニってコトは別にないというか、店頭で中が見られるなら買わなかったかも知れないくらいの感じ(苦笑)。

 山田太郎の街頭演説とか、政治家で初の握手会が云々言ってる街宣車の声を聞きつつ秋葉原を離れる。
 徒歩で神田の馬力に向かうが、最初に目指した店は知らないうちに閉店しており(^^;;;、その近くにあるとされた神田西口駅前店を探し出すまでにえらく手間と時間が掛かったりとか。

 で‥‥‥まあ僕は初見なのでよくわからないんだけど、潰れた方の神田の馬力とか錦糸町の本店とかには通ってたという森原せんせ的に不本意なことが幾つかあり、だから結局、そのままその足で錦糸町の馬力へ移動して飲み直すことに。僕史上初、別の立地にある同一店舗を梯子(笑)。

 最後に錦糸町駅併設のヨドバシカメラを冷やかして、錦糸町駅構内で森原さんと別れて帰宅。
2016/06/25 23:50:24
偽偽DTPオペレータ部活動。
 PDFファイルのプロパティの話の続きで、昨夜日記をアップしてから今日に至るまでに判明したあれこれ。
luci2
00:06:20
 : PDF書き出しプリセット、InDesignCCは設定項目「レイアウト」があり、互換性:Acrobat 7(PDF1.6)以上なら「見開きページ(表紙)」「連続見開きページ(表紙)」が選択できる。CS6の方は「レイアウト」自体ない。 pic.twitter.com/5zEyycXBqe
luci2
00:08:47
 : これ、CCで作ったプリセットを使ってCS6から出力したらどうなるんだろう‥‥‥(苦笑)
 といった次第で、この際、本当に必要なPDFプリセットの精査と整理をちゃんとやろう、と思い立ちつつある。

 例えばPOPLSPDF/X-1aに準拠したデータで入稿することを推奨してるけど、ではそこにPDF/X-4のデータとか持って行ったら何が起きるのか、に関する記載は特にない。
 となると‥‥‥入稿のためだけのデータが本の体裁に似ている必要は実は特にないので、そこは割り切ってレイアウト無指定のPDF/X-1a準拠データを作り、逆に、制作中の確認用PDFは本の体裁に似ている方が扱いやすいので、PDF/X-4準拠データにすることで自動的に適切な出力が得られるようにして、時と場合で両者を使い分けるのがよいだろう、と。つまり、
入稿用
  • 標準:PDF/X-1a(2001と2003はどっちなの^^;;;)
  • 互換性:Acrobat 4(PDF1.3)
  • レイアウト:(無指定)
  • ダウンサンプリングなし
  • トンボあり
内覧用L(奇数ページ始まり)
  • 標準:PDF/X-4:2010
  • 互換性:Acrobat 7(PDF1.6)
  • レイアウト:見開きページ(表紙)
  • ダウンサンプリングあり
  • トンボなし
内覧用R(偶数ページ始まり)
  • 標準:PDF/X-4:2010
  • 互換性:Acrobat 7(PDF1.6)
  • レイアウト:見開きページ
  • ダウンサンプリングあり
  • トンボなし
 この3つがあれば取り敢えず用は足りるんだと思うので、自作したプロファイルを一旦片付けて、この3つだけを改めて作ろうかな、とか。

 んで、こういうのを用意して、まあInDesignCCで狙った通り動くのはある意味当たり前ではあるものの、例えばInDesignCS6でもこれって同じように動くんだろうか、っていう問題はある(苦笑)。
 ちょうど今、職場のInDesignもCS6が主流になりつつあって、プライベートもInDesignCS6にしとくと同じデータに触れて楽だったりとか、そういう事情も鑑みるなら、まあCS6でも動くに越したことはないんだけど、その辺はどうなんだろうなあ。
2016/06/26 00:39:58
[2676.06.24.金.]
[2676.06.24.金.] / 偽偽DTPオペレータ部活動。
偽偽DTPオペレータ部活動。
 ブックからPDFを出力する試みが大体形になった、のトコまでは大変めでたいんだけど。

 次のステップ。PDFファイルのプロパティを編集したい。
 具体的には、通しのドキュメント上で先頭ページのノンブルが奇数なら、そのパートのPDFはページレイアウトを「見開きページ(表紙)」に、ノンブルが偶数なら「見開きページ」にした状態のPDFが欲しい。
 でもこれは、InDesign側のスクリプトでは設定項目自体がなくAcrobatをActiveX経由で操作するようなやり方でも無理っぽい
 Acrobatにアクションスクリプトを登録すれば核心部分の作業そのものが比較的簡単に実現できるっぽいのは実験が済んでるけど、それと組み合わせるにしても、特にコトの前後が結構いろいろややこしくて辟易中。
  • アクションスクリプトが処理対象にするディレクトリは固定する必要がある
    • このため、仕組みは作れても、第三者に配布するのがちょっと難しそう
  • InDesignスクリプトからアクションスクリプトが処理対象にするディレクトリへPDFを直接出力するのもなんか変なので、PDF出力先→アクションスクリプト用ディレクトリ→PDF出力先のファイル移送手段を実装する必要がある
  • バッチやWSHからアクションスクリプトを直接実行できるかどうかを調べていないのだが、実行できない(&終了タイミングを検知できない)とすると、アクションスクリプト部分だけはどうしても手動で実行せざるを得ない
    • 往路の移動が済んだら「アクションスクリプト処理完了後にOKボタンを押してください」ダイアログでも出しといて、そのダイアログが閉じたら復路の移動を始めるような奴でいい?(笑)
 ややこしいとは言いつつ、僕の手元に絞った話としては「多分どうにか仕組み化できるだろうな」って手応えもないではないものの、このアプローチだとそれを他人に渡すことの難易度が高すぎてなあ。
 CUIのPDF編集ソフトみたいなのも幾つか試してみた方がいいんだろうか。
2016/06/24 15:19:39
[2676.06.23.木.]
[2676.06.23.木.] / 偽DTPオペレータ部活動。 / 偽偽DTPオペレータ部活動(1)。 / 偽偽DTPオペレータ部活動(2)。
偽DTPオペレータ部活動。
 僕内部では「7月案件」と呼ばれている、夏コミ向けの組版&入校データ作成作業に向けた準備中。

 この話が最初にアクティブだったのって実はちょうど去年の6月くらいなんだけど、入稿先も決まってない中で適当に紙面サイズをググって出した新書判のサンプルと、今回入稿に使いたいとこの間先方から話のあったPOPLSの規定に則った新書判サイズが違う、ということに気づいてちょっと慌てた。
 つーか、思えば「POPLSを使いたい」って言われた瞬間にここまで考えが回ってるべきだった。
 本文(文章)の方は何とかできる余地がまだまだあるけど、去年版サンプルのサイズを元手に挿絵の発注出しちゃってたりするとそっちは大変なことになりかねないので、取り急ぎ先方にサイズの再確認(と、必要なら挿絵の発注先にサイズ変更を打診)を要請したり、こっちはこっちで新寸法に合わせたテンプレート周りの再作成に着手したりするなど。

 あと「データのやりとりにDropboxはいかがでしょう」的なセールストークもする(苦笑)。
 いやDropboxで直接ファイルがやりとりできるの本当便利なんだって。実際今、ほとんどの相談事はTwitterのDMとDropboxで完結しちゃってるし。
2016/06/23 14:22:06
偽偽DTPオペレータ部活動(1)。
 縦書きで左ページから始まるドキュメントをスクリプトから(でなくても)PDF形式にエクスポートする時に、レイアウトを「見開きページ(表紙)」に変更する方法を探しているんだけど、これがまったく見当たらなくて困り中(苦笑)。
 そもそもPDFExportPreferenceに該当値がないっぽいので、本当に不可能というか、手段そのものが存在しないんじゃないかと思われるんだが、不便だから何とかして欲しいなあ‥‥‥。
2016/06/23 15:23:57
偽偽DTPオペレータ部活動(2)。
 次の実験として、ドキュメントじゃなくてブックを対象にしたPDFエクスポートの手法を模索。
 これができると僕個人の作業についても夢が広がるし、今スクリプトを供給している先でも、こういう仕組みが存在するなら便利だろう。

 まず基本的なところで、
var book = app.activeBook;
var outFile = {※PDFファイル名};
book.exportFile(ExportFormat.PDF_TYPE, File(outFile), false, {※PDFプリセット名});
 これで、ブック全体がoutFileとして出力される。
 ちなみに{※PDFプリセット名}は、InDesignに登録済みのPDFプリセット名。名前の文字列指定でOK。
var book = app.activeBook;

//出力ファイル名の決定
var outFile = {※PDFファイル名};

//ファイル名が「_表」で始まるドキュメント以外を配列にpush
var contentArray = new Array();
for(var bookCounter = 0; bookCounter < book.bookContents.length; bookCounter++)
{
	if(!book.bookContents[bookCounter].name.match(/^\_表/))
	{
		contentArray.push(book.bookContents[bookCounter]);
	}
}

//PDF出力
book.exportFile(ExportFormat.PDF_TYPE, File(outFile), false, {PDFプリセット名}, contentArray);
 上記でcontentArrayと書いてあるところ、Bookオブジェクトのリファレンスでいう[whichDocuments]の部分は、book.bookContentsの配列要素を任意に選んで配列形式で渡す。
 ここにbookContentsオブジェクトを1個しか書かなければ、書いたドキュメントだけがPDF化される。
 また、例えばbook.bookContentsの配列要素が、0(先頭)から順に「目次、1章、2章、あとがき」だったとして、0番目(目次)と2番目(2章)だけをpushした配列を渡すと、目次のすぐ次に2章があって、1章とあとがきがないPDFが出力される。

 余談になるけど、それで上記の例は何をしているのかというと、『紐づけられたファイル名の先頭2文字が「_表」でない』オブジェクトを機械的に選り分け、配列に格納している。
 これは、表1は「_表1.indd」という1ページだけのドキュメント、同様に表2〜4にもそれぞれのファイルを仮置きするように全体を作っているから可能なことで、つまり、配列の中身は「表1〜表4以外の全内容」となる。‥‥‥ウチで個人誌作ってる時にこういう出力よくやるのよ。「表紙(表1)と裏表紙(表4)だけ」のデータを表紙の出力データ、「表1〜表4以外の全内容」を本文の出力データとして使い、印刷結果を複合機の中で組み合わせながら製本していく、っていう作業をいつもやってるワケなので、コマンド一発でコレができるだけでも一定の恩恵はあるのであった。
2016/06/23 17:30:13
[2676.06.22.水.]
[2676.06.22.水.] / 偽偽DTPオペレータ部活動(1)。 / 偽偽DTPオペレータ部活動(2)。 / 偽偽DTPオペレータ部活動(3)。
偽偽DTPオペレータ部活動(1)。
 こういうロジックのことを以前書いたが、これは間違いだった。
//何かドキュメントを開いている時は処理を実行
if(0 < app.documents.length)
{
	var result = "";
	var document = app.activeDocument;

	//activeDocumentの全テキスト変数を走査
	for(var valueCounter = 0; valueCounter < document.textVariables.length; valueCounter++)
	{

		//associatedInstancesの配列要素数が0であるテキスト変数は使われていない(多分)
		var textVariable = document.textVariables[valueCounter];
		if(0 < textVariable.associatedInstances.length)
		{

			//「{テキスト変数名}:{現在のテキスト変数値}\n」文字列を変数にストック
			result += textVariable.name + " : ";
			result += textVariable.associatedInstances[0].resultText + "\n";
		}
	}

	//ストックされた情報をalertで表示
	alert(result);
}
 とはいえ、「間違いだった」って言い切っちゃうのも厳密には正しくないんだけど。
 ‥‥‥ええと、associatedInstancesっていうのは多分、そのテキスト変数が実際にドキュメント内に配置されてる箇所のステータスを指してると思うのね。つまり、ドキュメント中で3箇所にそのテキスト変数が配置されていたら、associatedInstancesの配列要素数が3になる。でも文字列化して置いてある位置が幾つあろうと内容は絶対同じに決まってる(故に『テキスト「変数」』)ので、その配列の要素数が1だろうと100だろうと、そのうちどこを参照してもresultTextは同じに決まってるんだから、配列要素数でいう0番目のresultTextを参照しましょう、というアプローチで書かれてるのがこのスクリプト。

 だけどコレ、実をいうとロジック組んだ時点で既に違和感を憶えていたことがひとつあって。
 「テキスト変数として定義されてはいるけど、ドキュメント上のどこにも配置されてはいない」値っていうのが存在したら、「実際の配置先情報の中から値を読み取る」ことを意図した現在のアプローチからでは、そういう奴にはアクセスできない筈なの。
 やってみたら実際できなかった。‥‥‥それは、「やってみる」ことが簡単にできる、ってコトなのよ。イレギュラーな事態とかでは全然ないの。
//何かドキュメントを開いている時は処理を実行
if(0 < app.documents.length)
{
	var result = "";
	var document = app.activeDocument;

	//activeDocumentの全テキスト変数を走査
	for(var valueCounter = 0; valueCounter < document.textVariables.length; valueCounter++)
	{

		//テキスト変数のタイプが「カスタムテキスト」である場合
		var textVariable = document.textVariables[valueCounter];
		if(textVariable.variableType == VariableTypes.CUSTOM_TEXT_TYPE)
		{

			//「{テキスト変数名}:{現在のテキスト変数値}\n」文字列を変数にストック
			result += textVariable.name + " : ";
			result += textVariable.variableOptions.contents + "\n";
		}
	}

	//ストックされた情報をalertで表示
	alert(result);
}
 そこまで含めた話としては、こっちのアプローチの方がより正しい。
 これなら「テキスト変数として定義され、ドキュメント上のどこかに配置されている」値も、「テキスト変数として定義されてはいるけど、ドキュメント上のどこにも配置されてはいない」値も、区別なく拾いに行けることがわかった。

 実は、こっちに関しては先人の資料があることを予め知ってはいたんだけど、だったらなんで最初からこっちにしとかなかったのか、っていう部分に関しては言い訳があって。
 端的にいうと「variableOptions.contentsが絶対定義されてるオブジェクトばっかりじゃないせいでエラーが頻発する」ことを嫌ったためだったんだが、今回の用途で値の置き場に使うのは基本的にカスタムテキストだけであり、結局「カスタムテキスト以外は相手にしない」を明示するだけでそこの問題が回避できることが判明したので、それならこれでいいんじゃないの、という話に今回なった。‥‥‥先人の資料はどっちかっていうと「テキスト変数を書き込む」ことを主眼としたもので、「テキスト変数を全部読み込んで必要な値を得る」使い方が書かれてるワケじゃないから、そこのギャップの乗り越え方もこっちで考えなきゃいけなかった分だけ後れを取ってる形になった、ということじゃなかろうか。
2016/06/22 11:16:49
偽偽DTPオペレータ部活動(2)。
 いま適用されてるマスターページと同じものを二重に適用しようとするとテキストフレームが消失したりなどする、という問題がまずあった。
 その問題自体は、「いま適用されてるマスターページと同じものは適用しない」チェックをひとつ仕込むだけで回避できた。
 それはそれでよい。
luci2
22:35:28
 : 元々左ページだけが並んでるドキュメントに対して、適切に左右のマスターページを適用し直すスクリプトを実行すると、最初から左ページだったページの本文フレームがどこかへ消失してしまう、という意味不明のトラブルに頭を抱えていたことを思い出した。
luci2
22:37:03
 : 思い出しついでにちょっとこの問題と格闘してみたのだが、結局、元々左ページで合ってるページに対して左のマスターページを当て直す意味はないので、適切なマスターページと今適用されてるマスターページの名前が一致してる時は触らないようにしたらクリアできた。‥‥‥なにそれ(苦笑)。
luci2
22:39:18
 : 手動で当てても本文フレームがぶっ飛ぶのは一緒だったので、スクリプティングが云々じゃなくてInDesign自体そういうもののような気がするんだが、なんで違うマスターページに変更する時はそういう問題が起こらないのかとか、本当InDesignって時々ワケわからんよなあ(^^;;;。
 ここからが本題。
 上記のソレに対処する中でふと気づいた、自分の手癖みたいなことの話をこれから書く。

 前提。
 ドキュメントはマスターページ「左」が全ページに適用された状態になっている。
 ノンブルを渡すと、ノンブルの値と本の綴じ方向を鑑みて、見開き左右を考慮した適切なマスターページオブジェクトが返却される内部関数がある。
  1. 当初は、ドキュメントの全ページをループし、「内部関数から返却されたマスターページオブジェクトを適用する」処理を全ページに対して実行していたが、この際、元々マスターページ「左」が適用済みのページにマスターページ「左」をさらに適用しようとする場面で、テキストフレームが吹っ飛ぶなどの重大な問題が起きていた。
  2. もしかして、同一マスターページを二重に適用するのがよくないのでは、という仮定に行き当たった。
  3. そのため、「ノンブルを渡すと、ノンブルの値と本の綴じ方向を鑑みて、見開き左右を考慮した適切なマスターページオブジェクトが返却される内部関数」をforkし、
    • 「ノンブルを渡すと、ノンブルの値と本の綴じ方向を鑑みて、見開き左右を考慮した適切なマスターページ名が返却される内部関数」
    • 「マスターページ名を渡すと、該当するマスターページオブジェクトが返却される内部関数」
    を作った。
  4. 適用中のマスターページ名と「ノンブルを渡すと、ノンブルの値と本の綴じ方向を鑑みて、見開き左右を考慮した適切なマスターページ名が返却される内部関数」の戻り値が一致する時はマスターページ適用をskipする仕組みを作った。
 ごく自然に、こういう考えごとをして、こういうロジックの修正をした。

 の、だけど。

 上記でいうと4.の工程で、『適用中のマスターページ名と「ノンブルを渡すと、ノンブルの値と本の綴じ方向を鑑みて、見開き左右を考慮した適切なマスターページ名が返却される内部関数」の戻り値が一致する』かどうかを比較チェックしようとしている。
 いやチェックすること自体はよい。そこではなくて。
 これ、僕はわざわざ「名前の文字列同士を比較チェックに掛ける」ために比較的複雑な修正に踏み切ってるんだけど、言語仕様的な事情からいうと、そこは別に名前の文字列同士でなくていい。というか、『適用中のマスターページオブジェクトと「ノンブルを渡すと、ノンブルの値と本の綴じ方向を鑑みて、見開き左右を考慮した適切なマスターページオブジェクトが返却される内部関数」の戻り値が一致する』かどうか、って書き方でも同じチェックができる。
 もし先にそこに気づいていたなら、
  1. 当初は、ドキュメントの全ページをループし、「内部関数から返却されたマスターページオブジェクトを適用する」処理を全ページに対して実行していたが、この際、元々マスターページ「左」が適用済みのページにマスターページ「左」をさらに適用しようとする場面で、テキストフレームが吹っ飛ぶなどの重大な問題が起きていた。
  2. もしかして、同一マスターページを二重に適用するのがよくないのでは、という仮定に行き当たった。
  3. そのため、適用中のマスターページオブジェクトと「ノンブルを渡すと、ノンブルの値と本の綴じ方向を鑑みて、見開き左右を考慮した適切なマスターページオブジェクトが返却される内部関数」の戻り値が一致する時はマスターページ適用をskipする仕組みを作った。
 解法はこれでよかった筈。
 早い話、実際の手順における3.の内容が丸ごと余計。
 4.の修正内容についても、3.のための現物合わせを施した部分は不要だった。

 ところで、なんでそうなっちゃったのか、っていうのをそれからずっと考えてるんだけど。
 ‥‥‥いや僕が言語仕様をちゃんと理解しないで書いてるっていう根本的な問題はあるよ? あるけども、まあ、それはそれとして(苦笑)。

 「文字列にしないと比較できない」のは文字列を文字列として読み取りたい人間の事情で、「オブジェクトそのものが同じかどうか」は直接比較検証できるし、何だったらその方が手っ取り早いんですけどっていうプログラム側の事情との間に認識のズレがあり、そして、方針を決定する位置にいる僕は人間でした、っていうことが問題だったのかなあ、とか。
 「文字列にしないと比較できない」んだから一旦文字列を経由しなきゃ、っていうことを、関数をforkしてる時の僕がぐるぐる思ってたことはよく憶えてる。そこにそういう迷いがあること自体、「プログラムが」じゃなくて「僕が」比較検証する気でいた、としか考えられないよね(^^;;;。そんな筈ないのに。
2016/06/22 13:30:03
偽偽DTPオペレータ部活動(3)。
luci2
21:29:58
 : なんだこりゃ‥‥‥おのれInDesign‥‥‥
 テキスト変数の話の続き。
 退勤後、既に納品が済んでるプロジェクト向けのテストデータで修正後スクリプトをテストしてて発見した事象。
luci2
21:33:32
 : 項目値が中黒(・)を含むテキスト変数の項目値を、〜variableOptions.contents から取得した場合と、 〜associatedInstances[0].resultText とでは、得られる値が違うことが判明した。 pic.twitter.com/4jocb7Y1Im
luci2
21:35:32
 : 何故そうなるのかはよく知らないが、最初のダイアログのように入力しても、確定後に再度編集画面を呼び出すと中黒が^5に変わっている。この状態で、2通りの方法でドキュメントからテキスト変数値を取得した結果が3枚目の画像。
luci2
21:38:53
 : variableOptions.contents は設定値そのものから、 associatedInstances[0].resultText は設定値をドキュメントに出力した値のうち、配列序数0番目にあたる出力内容から文字列を取得してるんだと思う。
luci2
21:41:54
 : 内部的に^5である値を・に変換してからドキュメント出力する過程の、それぞれ変換前と後に対象が分かれてる。なら associatedInstances[0].resultText を使うのが正しいけど、「定義されたがドキュメントに出力されてないテキスト変数」がこの方法では扱えない。
luci2
21:45:37
 : まあ、associatedInstances[0].resultText が使えるならそっち、ダメなら variableOptions.contents から拾うように作り、かつ、使われないマスターページとかでいいから、必要なテキスト変数はどこかに出力されるよう気をつけよう‥‥‥
 同じ変数とその出力結果である筈なのに、variableOptions.contents と associatedInstances[0].resultText では意味する値が違うケースがある、という嫌な事実に行き当たってしまう悲劇(苦笑)。おのれInDesign‥‥‥。
//何かドキュメントを開いている時は処理を実行
if(0 < app.documents.length)
{
	var result = "";
	var document = app.activeDocument;

	//activeDocumentの全テキスト変数を走査
	for(var valueCounter = 0; valueCounter < document.textVariables.length; valueCounter++)
	{
		var textVariable = document.textVariables[valueCounter];

		//テキスト変数のタイプが「カスタムテキスト」である場合
		if(textVariable.variableType == VariableTypes.CUSTOM_TEXT_TYPE)
		{

			//「{テキスト変数名}:文字列を変数にストック
			result += textVariable.name + " : ";

			//「{現在のテキスト変数値}\n」文字列を変数にストック
			var textVariable = document.textVariables[valueCounter];
			if(0 < textVariable.associatedInstances.length)
			{

				//associatedInstancesの配列要素数が1以上である場合はそちらの値を優先
				result += textVariable.associatedInstances[0].resultText + "\n";
			}
			else
			{

				//associatedInstancesの配列要素数が1以上でない場合はvariableOptions.contentsを採用
				//(※中黒など、特定文字が別記号に置換されている場合がある)
				result += textVariable.variableOptions.contents + "\n";
			}
		}
	}

	//ストックされた情報をalertで表示
	alert(result);
}
 というワケで、「生のテキスト変数の中では特定の記号が別の文字列に置き換えられた状態になっている」問題と「テキスト変数として定義されてはいるけど、ドキュメント上のどこにも配置されてはいない値が採取できない」問題の両方をなるべく救いたい折衷案のサンプルは、大体こんな風になると思う。

 実際の処理も慌てて一部手直し。嗚呼。
2016/06/22 21:46:00
[2676.06.21.火.]
[2676.06.21.火.] / 偽偽DTPオペレータ部活動。 / それはそれとして。 / チラシの裏。 / 夏コミ落ちたので、
偽偽DTPオペレータ部活動。
 先週まで割とホットだったアレとは別のソレから、この夏向けに作業があるかもって話は前々から来ていたんだけど、大雑把なスケジュール感と共に、本当にやるのでよろしくお願いします的なことを伝えるDMが今日届いた。
 実際に僕サイドの作業が始まるのは7月に入ってからになるっぽいがまあその辺はさておき‥‥‥この夏はマジで何もしないかと思われたんだけど、これで少なくとも組版(というか、テキスト原稿と挿絵を組み立てて入稿用完パケPDFにする)作業がひとつあるのはほとんど確定。

 ところで。
 編集とか組版とかInDesignスクリプティングとかを手掛けるようになってもう随分経つけど、この話、組版とか編集寄りの作業オンリーによって依頼主から報酬を得るという、実は僕史上において初めてのケースになりそう。
 具体的な額面についてはまだ言えないというか、そもそもその額面も蓋を開けるまで確定しない方式をとったので今の段階では言いたくたって言いようがないのだけど、あわよくば他人の財布で焼肉が食えるかもしれない点に夢が膨らむ契約内容となりました、くらいまでは言っても大丈夫?(笑)
2016/06/21 14:41:14
それはそれとして。
 そうやって考えてみるとむしろ今までのうちにやっとかなかったことの方が問題なんだけど(苦笑)、VAIO Z(VJZ13A)Iconia Tab 8 W(NT.L7GSJ.001)Windows10化がまだ未着手。

 ↑の企画は入稿が7月末見込みなので、僕の作業も最大に長くて7月一杯くらいは掛かるかもって感じ。
 無償アップグレード期限の切れる7月29日の段階で全作業が完了しているかどうかは未定だし、本当にそこで作業できるか不明のタイミングを待つくらいだったら、いっそ6月であるうちにアップグレード作業をやってしまって、それから作業に掛かる方が勝算高いのではなかろうか、という。
 取り敢えずVAIO Zの手順は出てきた。
 Iconia Tab 8 Wの方はなんか出てきてないけど、まあこっちは別に、壊れたら壊れたで(w。

 あるいは、そもそも「Windows10にアップグレードしない」という、考え得る限りで最良の手段も残されてはいるんだが。
 実際自分で使ってて思うんだけど、Windows8.1だとここが嫌とかそういうの別にないからなー。今コレで動いてるんだから、このままでも全然問題ないんだけどなー(苦笑)。
2016/06/21 16:18:05
チラシの裏。
 編集とか組版とかInDesignスクリプティングとかを手掛けるようになってもう随分経つけど、って↑に書いてて、ふと気になったので思い返してみた。
 「随分」って、具体的にどのくらい「随分」だったのだろう?
■初めて同人誌に関わった
 多分だけど、1992年かその翌年か、くらいの筈。今年から見ると最長で24年前。
 編集っぽい動きはこの時からしていた。というか、編集作業を始める方が、本のために原稿書き始めるよりもちょっと早かった筈。

→ワープロ専用機からWindows PCに移行した
 大学4年の時だったと思うので1995年じゃなかろうか。21年前。
 PageMaker使用開始も同時なので、DTPソフト使用歴もそのくらい。

→PageMakerからInDesign CS2に移行した
 2008年と記録にあるので8年前か。
 ‥‥‥この時の活用できてなかったっぷりは、我がことながら目に余る(苦笑)。

→InDesign CS2からInDesign CS4に移行した
 2009年のことだったらしいので7年前。
 買ったこと自体の目的は「ダウングレード権を行使してInDesign CS3」を手に入れることにあったが失敗。バージョン合わせに纏わる苦難の時代が続く。

→メイン環境をPageMakerからInDesignに完全移行した
 PageMakerをまったく使わずにInDesignだけで作った初めての本、に関する記述が2010年5月にあるので、この時をもって完全移行を果たしたものとする。逆に言うと、ここまでは事実上「PageMakerの時代だった」としてよいであろう。6年前。

→InDesign CS5.5を導入した
 2011年5月には導入済みの記述がある
 ‥‥‥が、たまたま当時は職場環境でもメインがCS4で、スクリプト開発・テスト作業のシームレス化に有利だったので「CS5.5はあるけどCS4がメイン」の時代が長く続いてた筈。

→スクリプティングに手を染めた
 オーガスト10周年合同誌の作業過程で実現する必要に迫られたのが端緒なのでその頃。日記中に初めて「偽偽DTPオペレータ部活動」トピが出現するのが2011年10月21日だから、CS5.5導入共々、4年から5年くらい前?
 考えてみれば、最近活発なスクリプティング分野における秋さん(現在は別名義)との協業も、元を辿ればこの時のやりとりから始まってるんだなあ。

→InDesign CCへ移行した
 去年の8月、VAIO Z(VJZ13A)が手元に届いたのとほぼ同時。
 これをもって僕系内における対応バージョンからCS4とCS5.5を破棄し、以降CCもしくはCS6のみとする。‥‥‥これも当初は、敦賀せんせの編集作業にフォローで入るにあたって、敦賀せんせのCCにバージョンを合わせるため、っていうのがメインの動機。
 こうして振り返ってみると、PageMaker時代がえらく長かったことに驚く。
 InDesignへの完全移行が果たされるまでがPageMakerの時代だったと考えると、およそ21年に及ぶDTPソフト使用歴のうち、PageMakerの時代が実に15年を占めるのに比べ、InDesignの時代は開闢以来6年しか経過していない。
 完全な独学から入ったPageMakerでは道具に振り回されまくりの状況に喰らいついてるだけで精一杯だったけど、逆にこっちの都合でInDesignを振り回せるようになって、あまつさえスクリプティングまでやるようになって、広がった&深まった世界のサイズは最早、PageMakerの時代とでは大人と子供ほども違っている、っていう‥‥‥「できること」と「できるようにするまでの時間」の組み合わせを素直に考えたら、PageMakerの時代の長さをとっくにInDesignの時代が凌駕してないと絶対おかしい、くらいの差があるんだけど、でも実際には、僕にとってInDesignの時代はまだ、PageMakerの時代の半分にも満たないんだなあ。
2016/06/21 18:33:12
夏コミ落ちたので、
 COMITIA117に申し込みました。いや、何とはなしにCircle.ms見てみたら「今日の23時59分に募集締切」とか書いてあるのを見掛けてしまい、何というかつい出来心で。

 今回もいつもと同じく、既刊とか何もないので新刊出なかったら即死スタイルです。
 ‥‥‥コミケ落選が決まってる時くらい、わざわざ締切背負いに行かなくたってよかろうになあ(^^;;;。
2016/06/21 21:28:52


このサイトでは、オーガスト, May-Be SOFTの画像素材を借用しています。[COPYRIGHTS.]
無断リンクも直接リンクも諸々含めてご自由にどうぞ。直接リンクの要領はこちらです。 [NOTICE.]
[2676.05.xx.] [SHORTCUT.]
[2676.06.xx.] [SUBSTANCE.]
SILENCE. / FORCEWORD. / AFTERWORDS. latest : list / MAIL. [OTHERS.]