始めてしまった行き掛かり上、合間合間でコツコツやってはいるんだけど。

luci2 12:42:24	:	全滅してエリクシールで復活を3回くらいやんないと勝てないストーリー上のボスと戦うのはやはり時期尚早なのであろうか。そうやってゴリ押せば押すことも一応できちゃうだけに、どういうのは引き返すべきで、どういうのがゴリ押すべきなのか、全然区別がつかなくて困り中‥‥‥
luci2 13:05:54	:	@atslave 48章です。2/4に出た魔晶チビ将軍の1戦目をゴリ押しで抜いて、直後の3/4に再度出てきたので撤退しました。主人公とかパーティとかに関しては、プロフィールを今ゲーム側からツイートしましたってこれジョブしかわかんないのか(苦笑)。ランク48でした。
luci2 13:07:41	:	現在のステータスってこれでいいの？ pic.twitter.com/lsxy30AmgE
luci2 13:13:14	:	@atslave クエスト進捗がこちらです。やはり突っ込み過ぎでしたか‥‥‥ pic.twitter.com/FhoAHCRfA1
luci2 13:16:20	:	何となく突っ込み過ぎのような気もずーっとしてたけど、全滅時にエリクシール買う財源とゲーム内の(キャラにとっての)通貨が切り離されてるのは、エリクシールの財源はそういう風に使うもんですっていうメッセージなのかと思ってたりだとか。
luci2 13:26:55	:	だいたい今、敵ボスにオーバードライブで必殺技とか撃たれるとその場でフロントメンバーはほぼ壊滅する。レギュラーでエリカ入れっ放しにしてるのは、運がよければそこから立て直せるケースがあるため。そういうバランスのゲームなのかと今までずっと思ってたが、やはり勘違いだったっぽい(苦笑)。

　本当に何も見ないでやってるせいなのか、他の人というか普通の人というかそういう人がやりがちな普通の遊び方と全然違う感の進捗状況らしい(苦笑)。まあ第48章は★18って書いてあってうちのチームが今★13とかそのくらいなんだけど、具体的には、第48章とかを遊んでるチームでこんなに総合戦力が低いのは誰に見せても珍しいっぽい。

　始めちゃったからグラブルやってるけど、だから最近は仕事とグラブルしかやってない気がする(苦笑)。

　ウチのチームがどんなに忙しくて隣のチームがどんなに暇してても絶対に人を貸さない決まりなんだそうだが、ウチのチームの要員としてアサインされてた人たちを隣のチームが持って行くのはアリなんだそうで、それがほとんど常態化した結果として、もう結構長い間、「ウチのチーム」って実質僕ひとりのことになってる。
　で、まさに今、普通これ何人かで手分けするだろって量の作業がウチのチームに積んであるんだけど、だからといって隣のチームから貸してる要因が戻ってくるワケでも、別のどこかから要員が補填されるワケでもないから、あればあっただけ全部を僕がひとりで片付けないとチームが死んでしまう、という変な状況に。なにこれ‥‥‥。

　18時30分に定時を迎えて1時間が経過した職場からお送りしておりますYeah。

　ちなみに2日前が今くらいに退勤してると思う。昨日はさらに30分遅かったみたい。まあ「最近帰るの早くなりましたよね」「電車で帰れるようになったからね」みたいな会話しながら駅へ向かってたような時期もこれまでに何度かはあったワケで、そういうのに比べたらそんなに大したアレでもないけども(苦笑)。

　あとひとつには、HHKBは職場にしかないです、っていうのも(^^;;;。
　なんかこの打鍵感がだんだん好きになってきたような感もあるし、僕が馴染んできてるのも確かだと思う。一方でこのキー配置とかバインドに馴染み切れないのも確かで、そういう意味における最終形はやはりREALFORCE91Uなのかなあ。

　クロスボーンガンダムは個人的に好きなのでちょっと気にならないこともないというか。
　無印から「鋼鉄の7人」までとなると、そのクロスボーンガンダムに乗る人の変遷が結構あって、そこの時系列の部分はどう処理するんだろう、って意味でも見てみたくはある。

luci2 22:03:47	:	クロスボーンガンダムか。ちょっと考えてもよいかな。ヤマトのどこいらへんがロボットなのかはよくわからんけど。
stscd 22:27:24	:	@luci2 ア、アナライザー・・・ pic.twitter.com/09H89QzUUG
luci2 22:56:16	:	@stscd え、それが戦うの？(笑)
stscd 23:18:57	:	@luci2 人型ロボットとの直接対戦経験は無いけど確か宇宙戦車ぐらいなら投げ飛ばしたりしたことはあったはず(笑
luci2 23:19:30	:	@stscd マジか(笑)　そりゃ戦力になるわ

　それにしても‥‥‥何というか、そもそも「スーパーロボット」が出てこない(筈の)ヤマトがスパロボのラインナップに入ってる点には、率直に言ってすごい違和感を感じる。
　ヤマトにも確か艦載機は幾つかあったと思うし、あんたいっつもバルキリーはファイターでしか運用しない人なんだから、ロボにならない戦闘機が幾つかあっても同じことじゃないですか、って言われれば確かに大差ないのかも知れんけど(苦笑)。

　豊洲→月島→有楽町→八重洲あたり。
　その後一瞬だけ秋葉原に寄って買い物→八重洲で散会。このところ暫くは改装か何かしてた気がしたんだけど、アルプスまた営業再開してた。

　この何年かはずっとESET NOD32 AntiVirusの5PC版を単位で更新しながら使ってたんだが、SHT22・SHL25もいい加減その辺考えないといけないし、カレントでバリバリ動いてるPCも今はそんなに台数ないので、ESET ファミリーセキュリティに切り替えて、ひとりで全部使い切ることにした(w。
　昨日秋葉原に寄ったのはこれのパッケージを押さえるため。
　ところで5PC・3年版が税込店頭価格で5000円しなかったんだけど、NOD32の5PC・1年で概ねその2倍を毎年支払ってたっていう、今までの出費は一体何だったのでしょう‥‥‥(苦笑)。

　先行でこないだSHL25に導入したESET Mobile Security for Androidにもここからライセンスを払い出し。
　SHT22は確かなんか無料のセキュリティソフトが入ってたので、それをアンインストールしてESET Mobile Security for Androidを導入予定。
　VAIO ZとIconia Tab 8 WはNOD32 AntiVirusの期限は確か今月切れると思うので、順次アンインストールしてESET Smart Securityを導入の方向で。

　メモリンク。
　こんなのもあるのか。次があったら行ってみたい。

　この忙しいのに週末はCoCのKPだし。1日が72時間くらいないと準備が進まん(苦笑)。

　今回はそもそもPLが一度に5人だか6人だかいるっていう大所帯で、そういう大所帯向けのシナリオってものがそもそもあんまりないというか、PL3〜4人+KPくらいの規模がやっぱり多い中で、まあ何人いてもどうにかなるだろうっていうのを幾つか見つけた中から、実際どれを回すかについては未だに考え中。

　もう悩んでる時間がないので、幾つかあった候補の中からシナリオをひとつに絞った。
　遊ぶ相手がここ見てる可能性もあるので一応コメントアウト\。

　あとは、これを実際に回すための準備とか、シナリオそのものの読み込みやら分析やらを進めていく。

　必要なだけのキャラシートは、取り敢えずデータの上では用意が済んだ。
　あとでネットプリントか何か使って紙に出力し、明日の場に持ち込む方向。

　ちなみに今回、『「自分でキャラを作る」フェイズをほぼ丸ごと(少なくとも能力・技能を作り込む部分は)飛ばして始める』を実現するための準備の準備として、クトゥルフ2010のキャラシートに用意されている技能名の中から、指定した個数の技能名をランダムに抽出するスクリプト(Perl)とかを用意した。
　前から弄ってるキャラクター作成支援マクロ付きExcelシートの中にも能力値をランダムで決める仕組みがある(その部分のWeb版がコレ)のでそれと、それで能力値の決まったキャラにボーナスを割り振る対象となる技能名をランダムで抽出する機能との組み合わせで、なるべく僕の私情が挟まらない形で(笑)、多量のキャラ(今回はPC10人分)を一気に粗製濫造する作業を実施。
　ところでこれはごく個人的な感想だけど、CoCを遊ぶにあたってこんな変な準備作業をしたことのあるKPって、世界中探してもそんなにいないんじゃないかと思う‥‥‥。

　あとは、主だった作業の中で残っているのは、怪異周りのデータ化かな。
　今日はルールブック持って出勤しているので(w、退勤後にでもその辺をちゃちゃっと済ませたい所存。

サークル情報登録＆当落情報検索システムをご利用頂きありがとうございます。
このメールは「サークル情報登録＆当落情報検索システム」において、
当落速報メールの受信設定を"受け取る"にして頂いた方の、登録したメール
アドレスに対して、コミックマーケット90の当落結果をお知らせするものです。

◎貴サークル「CANDYFORCE」は、残念ながら抽選洩れになりました。

　はい消えたー。
　まあ去年の夏がちょっと熱すぎたので、そういう意味ではバランス取れてていいのかも知れん(苦笑)。

　でまあ、ご覧の有様により手が空いたといえば手が空いたので、規模とか締め切り次第によっては、この夏向けでもInDesign組版仕事とか編集補佐とかに入れるかも。困ってる人は何かの形で連絡くださいまし。

　内山靖二郎が「1998年以前」に作ったというシナリオ。
　なんで急にコレなのかっていうと、まずひとつにはPCの人数が多かったから。結局すらさん・義忠さん・久道さん・影守さん・ひではるさんで5人、予定通りならあと1人いる筈だったので6人だけど、大体CoCの既成シナリオは4人くらいのPCを対象にしていることが多いので、6人いても回せるもんなのかどうかがよくわからず、「想定人数について言及がない」ものの中から選ぶしかなかったっていう事情とかが。

　蘇芳家「かがみ姫」に続けて既製品のシナリオを回したんだけど、これはこれで問題あるなあと思うのは、実際始めてみると「意外とシナリオが理解できてない」ことに気づく感じのこと。んでまた、傍から見てればそれはわかることのようで、後からそこを指摘するメールが来たりして、それも尤もだなあと自分でも思うのだが、流れとかイベントとか、お話として読み込んでる時には確かに把握できてる筈のことが、それをお話として他人に話す段になるとバタつく事実はある。
　ではどういう準備をしたらいいのかっていうのを考えてるんだけど、一回バラして自分で書き直すくらいやんないとダメなんじゃないのかなあ。‥‥‥んで、もうそうなると、最初から全部自分で作るのと手間が変わらないじゃん、ってところでまた首を捻る(苦笑)。

　あとひとつ気づいたこととして、なんというか、TRPGには遊ばれ方が幾つかあるんだな、っていうのも。
　まあ最初に事件らしく事件を置かなかったせい(というかこのシナリオは、時間と共に状況が悪くなっていくだけで、人間に解決できるサイズの事件は最初からない)もあるのかも知れないけど、この日の卓というか面子はシチュエーションを転がすと勝手にロールプレイで遊び始める面子で、大体それだけやってればいいのはそれ以外のことをシナリオがあまり要求してないからで、TRPGってこういう遊びなんじゃないかと僕が思ってたものにはこっちの方がより近い気がしたんだがそれはそれとして、例えば動画サイトのリプレイ動画とか、誰かに呼ばれて遊びに行った時に出てくるシナリオって、複雑な謎解きをPLに要求するものとか、出てくる神性を直截に退けることを要求するものとか、そういう方向に極端であるものも含めて、「問題を解決する」ゲームっていう定義に沿うものが多いよなあ、と。
　いや「ホラーウォッチング」だって個々の腕の長さに応じた問題解決はするんだけど、結局のところ、根本的な何かがそれによって取り除けるワケではないし。

　‥‥‥で、恐らくは、この認識すらも何か偏ってるんだろうなっていう予感もあって、総体としてはもう何がなにやら(苦笑)。

　なんか今度は秋葉原で呑み会らしい。特に出る気なかったんだけど気がついたら出ることになってた。
　昼ごろ出てきてルノアールで偽休出中。昨日の日記を纏めたり、考え中のスクリプトを弄ったり。

　朝から降り続く雨のせいでバス遅延&電車遅延のコンボが。
　いつもより早く出掛けてるのにいつもよりバス乗る時刻が遅いので濡れてる時間がより長い、地獄のような状況。なにこれ。

luci2 14:13:57	:	艦これ検証部「ソース読んで出なおせ」→「出直しました」→ - Togetterまとめ togetter.com/li/985635 @togetter_jpさんから
luci2 14:17:44	:	kcvdb.jp/KanColleViewer もう艦これ自体に触らなくなって随分経つけど、触ってた頃は使ってた「提督業も忙しい！」には「検証DB送信機能を付与するプラグイン」があることを知った。これって、プラグインを別途インストールしないと有効にならない機能なんだよね？
luci2 14:19:27	:	「提督業も忙しい！」はそれ自体をインストールする以外の作業を何もしてないから大丈夫だと思うけど、そういうプラグインが入ってないか知っておく必要は一応あるし、帰宅後にでも起動してその辺見てみるか‥‥‥

　何のデータのどこからどこまでなのかを把握しないまま、自分とこのデータを勝手に送信させるとかいうのは、まずもって避けた方がよい。それは、相手が誰だからとか何とかいう理由や事情と無関係の、あるいはそこよりずっと手前の話として。
　んでその上さらに、送信先が大変おかしな人たちだったことまで発覚してる(というか次々自爆事故起こしてる)昨今であるからには、そんな変なもの導入した憶えとか全然ない僕であっても、「そもそもそんなプラグイン導入してない」ことは一応確認しておきたいなあ、とか。

　そういえばインターフェイス周りの研究を連綿と怠り続けていることを思い出したんだが(^^;;;、元々「Excelファイルから被ルビ文字・ルビ文字の組み合わせを取得し、ドキュメント中の初出被ルビ文字に対してルビを振る」スクリプトは提供済みで、でもそれは、ドキュメントひとつ(=ファイルひとつ)を単位として、初出の1回だけしかルビを振らない。
　それ自体はそういう風に動作させようと思って作ったので別にバグとかではないものの、これに対する改修要望っていうのが来ていて、それによってどうなって欲しいかっていうと、ひとつのストーリーを先頭から区切り(例えば空行が入ったらそこで区切り)まで、その区切りから次の区切りまで、幾つ目かの区切りから最後まで、のようなブロックに動的に分割し、ブロック毎に初出のタイミングで単語にルビを振る機能が欲しい、と。

　従来方式においては、全部にルビを振るにせよ、ストーリー中で初出の位置にのみルビを振るにせよ、チェックの対象がドキュメントそのものでよかった点は面倒がなかった。
　例えば、ストーリーの中身を任意の区切りでブロック分けすると3ブロックある場合で、それぞれのブロックの中に同一の被ルビ文字を3箇所ずつ抱えているとすると、3ブロックx3箇所の全部にルビを振るのが「全部にルビを振る」で、先頭ブロックの最初以外はルビ振らないのが「ストーリー中で初出の位置にのみルビを振る」。
　オーダーの来ている方式では、3ブロック全部に対して、その枠内の初出位置にルビを振るので、ルビが振られるポイントは3箇所になる。

luci2 18:51:07

:

ストーリー中のテキストをある単位で区切って、その範囲内で文字列検索、ヒットした最初の要素にだけ加工、のような動きをするサンプルができた。ここを越えたということは、現在オーダーのあるもう片方のスクリプトについても、技術的な目処は立った。

　で、実現する上でネックと思われていた(そういうスクリプトを書いたことがなかった)、「ストーリーをブロック単位で選択範囲に収める」、「選択範囲内に対してのみ被ルビ文字の存在チェックを行い、先頭位置に対してのみルビを振る」が、手を動かし始めてみたら思ったよりあっさりと実現できた(笑)。

　んでもって、この案件的には恐らく「全部にルビを振る」とか「ストーリー中で初出の位置にのみルビを振る」とか要らない(「ブロック単位で初出位置にルビを振る」だけ実現されればよい)可能性が高いので、その辺の整理も含め、次は実際のルビスクリプトに手を入れていくことに。

　ルビスクリプトの章分割対応続き。
　元あったルビスクリプトの一部を昨日作った仕組みに置き換え。また、別の技術的興味として、2014年に作ったらしい仕組み(JavaScriptからVBScriptを呼び出してExcelファイル中の全タブを個別にTSVファイル化し、そっちを全部読み込む)とは別に、「JavaScriptで直接Excelデータをインポートする」方向性をちょっと模索してみたり。
　‥‥‥模索してはみたものの、インポート時にタブ名か通番を指定するインターフェイスっぽくて、通番をループで回せば「あるだけ全部」みたいな挙動も可能だとは思うけど、タブの名前を持ってくる方法が見当たらなかったため、いま目論んでる扱い方には今ひとつマッチしないことが判明した、に留まるが(苦笑)。

　なお、

　んでもって、この案件的には恐らく「全部にルビを振る」とか「ストーリー中で初出の位置にのみルビを振る」とか要らない(「ブロック単位で初出位置にルビを振る」だけ実現されればよい)可能性が高いので、その辺の整理も含め、次は実際のルビスクリプトに手を入れていくことに。

　ここのところを先方に確認したところ「全部できた方がいい」的な回答が来たため(笑)、Excelデータの1件(=被ルビ文字・ルビ文字の組み合わせ1個)ずつにレンジと置換回数を設定するインターフェイスでやることにして、それの実現に必要な拡充も同時に加えるなど。
　諦めっ放しの画面系を除けば大体これで実用に足るのではないか、という状況までは持ってきたので、退勤後にでも先方に見せてみる方針。

　で、このルビスクリプトが先方環境で実用レベルに達すれば、多分だけど次は目次の算段が始まるまで出番がないので、あとは書くものの考えごとをする。‥‥‥つーか「書くかどうかはさておき」ってエクスキューズ入れといた筈だと思ったんだけど、いま見るとそう読める箇所が特にないので(苦笑)向うの解釈が多分正しいって話になると僕も思うのだが、すると一体、僕はどれの話と勘違いしてたんだろう？(^^;;;

　ルビスクリプトの話の続きの続き。
　あれほど思うように画面が作れなかったScriptUIによるダイアログ作成が、改めて手をつけてみたら意外とあっさり形になった。
　とはいえまあ、元々のとこで求めてた絵面とかと比べたら大分デチューン気味ではあるので、整理も含めてまだ弄るのは弄るんだけど、でも差し当たり、動かすのに支障ないところまでは作れてるんじゃないかと思う。

　つーか、以前の苦労は一体何だったのだろう‥‥‥(苦笑)。

　あるいは真を救うまでの遠い道のり。

　ダイアログ実装版のルビ一括適用スクリプトを渡したところで、現物合わせで改善した方がよい点と、処理系としての問題点がひとつずつ。
　まず要改善点。被ルビ文字とルビ文字の関係を管理するExcelシートにおいて、当初「タブが表現するもの」は著者名もしくはSSタイトルだったんだけど、先方の使い方からいうと原作(二次創作のネタ元となる一次創作の方)のタイトルが選べた方が扱いやすそうなので、それは現行処理に追加。軽くテストして、意図通りデータが取れてるのも確認済み。

　問題点の方なんだけど。
　例えば被ルビ文字を「九条」として候補をリストアップした時、その中には「九条ヶ丘」の先頭2文字も含まれる。
　で、「九条」とまた別に「九条ヶ丘」が被ルビ文字として存在するとしたら、処理の順序によっては、「九条ヶ丘」の先頭2文字には既にルビが振られている、ということも起こり得る。‥‥‥で、問題なのは、「先頭から何個を置換する(ルビを振る)か？」に具体的な個数が書いてある場合、例えば「先頭1個を置換する」とExcelシートに書いてある場合で、その「先頭1個」に該当する「九条」が既にルビ適用済みである場合、現行処理は、だからといってその次の候補を見に行くことをしない点。
　多分これはループの作り方を僕が間違えている。

　ループの話は置いといて、ここを逆転するのに使えるのではないかと考えていた要素技術がひとつ、まあ、あるにはあった。それは

//被ルビ文字(列)の決定
app.findTextPreferences.findWhat = rubyPref["contents"];
app.findTextPreferences.rubyType = NothingEnum.NOTHING; 	//この行を追加

　この設定行を追加したら『「rubyTypeがRubyTypes.GROUP_RUBYでもRubyTypes.PER_CHARACTER_RUBYでもない」を指定した』ことになるんじゃないか、故に最初にコレクションされる被ルビ文字のリストの中から、「コレクションする」段階でルビ付き文字列を除外できるんじゃないか、っていう仮説のことだったんだけど、実際やってみたところ、これは設定してもしなくても挙動はまったく一緒である、つまり、僕が望んだ効果は特にないことが判明した。
　だから多分これって、『「rubyTypeがRubyTypes.GROUP_RUBYでもRubyTypes.PER_CHARACTER_RUBYでもない」を指定した』んじゃなくて、単に『「何も指定しない」をわざわざ明示的に指定した』ように解釈されてるっぽい、と考えると辻褄が合う(苦笑)。わざわざ書かなくてもデフォルト値がソレなんですけど、的な奴。
　となると検索の段階で「既にルビが適用されている」を除外するのは恐らく無理なので、一旦引っ掛けておいて、ループの中でrubyFlagの真偽を見ながら判断していく方法以外はなさそう。やっぱループの方が間違ってるんや‥‥‥。

　昼食買いに行ったコンビニで一緒にポストイット買う。
　これはこのまま持ち帰ってTRPG荷物に放り込む用。

　実をいうと本当に欲しかったのは先週の土曜、CoCで遊ぶ前にルールブックの必要な箇所(ディープワンに関する言及がある箇所とか)に付箋を貼っておこうと思った時なんだけど、いや本当に新宿の(特に駅から歌舞伎町界隈の)コンビニ、見掛けた店には全部入ったと思うってくらいの勢いでコンビニ巡りをしたものの、何故か、付箋紙が売られてる店舗はその中に一軒もなかった。
　しょうがないからテキストエディタで必要な箇所のメモとってそっちを参照することでセッションはどうにか乗り切りはしたが‥‥‥ええと、もしかして、歌舞伎町の人は付箋紙嫌いとか、そういうの何かあるの？(苦笑)

　あるいは真を救うまでの遠い道のり。

　目次自動生成スクリプトの改修以降、そのドキュメントは作者が誰で(著者名)、ドキュメント自体のタイトルが何で(タイトル)、元にしたゲームのタイトルが何で(原作)、っていう情報はテキスト変数から拾うようになってる。
　被ルビ文字とルビ文字の関係を管理するExcelファイルにはそれら毎のタブが存在する(かも知れない)中、問題は「同じ被ルビ文字に別のルビ文字が設定されてたらどうするのか」。そこに関する話し合いの末、優先順位が高い方から順に

原作　＞　タイトル　＞　著者名　＞　「共通」タブ

　のルールで情報を読み込み、読み込み済みのデータとバッティングする要素が来たら読み捨てる(先優先)、という線で決着。
　これも含め、どういう問題は仕組みの拡充で拾うか、どういう問題は編集側の手動対応にするか、みたいな切り分けの話も一応した。

　あとは、その「被ルビ文字とルビ文字の関係を管理するExcelファイル」を作る作業自体にも各SS作家が関わることになりそうな流れなので、仕組みの制作側っていう立ち位置から準備中のreadmeにコメントを出したり、そもそも何がどうなる仕組みなのかっていう点について補足説明するための資料を作ったり。
　半角数値orNULL(or「？」なんだけど、「？」について個々のSS作家にアナウンスする意味はあんまりない)をセットして欲しいExcelのセルから全角数値とか読み込むと切ないので、全角数値だったら半角化するカラクリを仕込んだり。
　昨日書いた『「九条」と「九条ヶ丘」問題』を解決するためにループの構造を修正したり。
　ここまでの話と何にも関係ないけど、ルビと同じ感覚で圏点を扱えるようにするカラクリもついでに仕込んでみたり。

　例えば「被ルビ文字列と検索文字列の分離&検索文字列の正規表現対応」とか、「ダイアログをもっと格好よくする」とか、まだ他に追求できることも色々あるにはあるものの、とはいえ、どんなに追い求めても「手動作業を完全に根絶する」のは無理な奴だし、その辺のバランスも含めた話としては、そろそろ「大体やりきってる」領域に入ってく感じになるんじゃないかなあ。

　昨夜のやりとりで編集自動化系のモノ作りは一段落した。
　んだけど、そこのプロジェクトってそれと並行して「冬向けの合同誌にどういうこと書くか」っていうプロットか何か集める作業を進めてて‥‥‥冬向けの企画だっていうのに今の段階でそこまで動かしてるとか端的に言って慌て過ぎだけどまあ感心っちゃ感心、みたいなコト他人事みたいに言ってる僕はといえば、ここまで全力で開発仕事にかまけてた僕がそんなもの考えるアタマを残していた筈はない(というか、「こういうのやりたい」的なぽわーんとしたのは幾つかあるものの、そこから何にも掘り下げてないので、それがどこに着地するのかとか全然知らない)ワケで、ここまで先制先制でやってきたのに回が変わったらいきなり落ちこぼれてる切ない展開に全米が泣いた。

　でまあ、ここへ来てようやく時間ができたので、そろそろその辺ちゃんと考えようと思い、またBOOK☆WALKERが昨夜たまたまセールやってたのもあって、取り敢えず鈴木光司「リング」を買い直す(w。

　最初に申告していた話の内容とかヒロインとかでは、いま考えてる話の内容は成立しないような気がしてきたので、Dropbox上のデータをこっそり書き換える(w。
　‥‥‥つーか便利だなDropbox。これがあるのとないのとではワークフローが全然違う。

　とりたてて急ぎの用事もない(ように先週した)し、なんか異様に眠たい、という体調不良による有給消化。そんなこと上司には言わないが(w。
　世間的には割とズル休みっぽいアトモスフィアだと思うけど、でもまあ、黙っていても空調が効いてる職場の方がむしろ快適だったりとかするし、その辺は本人的にはどっちもどっちって感じ。

　先週まで割とホットだったアレとは別のソレから、この夏向けに作業があるかもって話は前々から来ていたんだけど、大雑把なスケジュール感と共に、本当にやるのでよろしくお願いします的なことを伝えるDMが今日届いた。
　実際に僕サイドの作業が始まるのは7月に入ってからになるっぽいがまあその辺はさておき‥‥‥この夏はマジで何もしないかと思われたんだけど、これで少なくとも組版(というか、テキスト原稿と挿絵を組み立てて入稿用完パケPDFにする)作業がひとつあるのはほとんど確定。

　ところで。
　編集とか組版とかInDesignスクリプティングとかを手掛けるようになってもう随分経つけど、この話、組版とか編集寄りの作業オンリーによって依頼主から報酬を得るという、実は僕史上において初めてのケースになりそう。
　具体的な額面についてはまだ言えないというか、そもそもその額面も蓋を開けるまで確定しない方式をとったので今の段階では言いたくたって言いようがないのだけど、あわよくば他人の財布で焼肉が食えるかもしれない点に夢が膨らむ契約内容となりました、くらいまでは言っても大丈夫？(笑)

　そうやって考えてみるとむしろ今までのうちにやっとかなかったことの方が問題なんだけど(苦笑)、VAIO Z(VJZ13A)とIconia Tab 8 W(NT.L7GSJ.001)のWindows10化がまだ未着手。

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

• [Windows 10アップグレード][VJZ13A*] Windows 8.1からのアップグレード情報

　取り敢えずVAIO Zの手順は出てきた。
　Iconia Tab 8 Wの方はなんか出てきてないけど、まあこっちは別に、壊れたら壊れたで(w。

　あるいは、そもそも「Windows10にアップグレードしない」という、考え得る限りで最良の手段も残されてはいるんだが。
　実際自分で使ってて思うんだけど、Windows8.1だとここが嫌とかそういうの別にないからなー。今コレで動いてるんだから、このままでも全然問題ないんだけどなー(苦笑)。

　編集とか組版とか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の時代の半分にも満たないんだなあ。

　COMITIA117に申し込みました。いや、何とはなしにCircle.ms見てみたら「今日の23時59分に募集締切」とか書いてあるのを見掛けてしまい、何というかつい出来心で。

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

　こういうロジックのことを以前書いたが、これは間違いだった。

//何かドキュメントを開いている時は処理を実行
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が絶対定義されてるオブジェクトばっかりじゃないせいでエラーが頻発する」ことを嫌ったためだったんだが、今回の用途で値の置き場に使うのは基本的にカスタムテキストだけであり、結局「カスタムテキスト以外は相手にしない」を明示するだけでそこの問題が回避できることが判明したので、それならこれでいいんじゃないの、という話に今回なった。‥‥‥先人の資料はどっちかっていうと「テキスト変数を書き込む」ことを主眼としたもので、「テキスト変数を全部読み込んで必要な値を得る」使い方が書かれてるワケじゃないから、そこのギャップの乗り越え方もこっちで考えなきゃいけなかった分だけ後れを取ってる形になった、ということじゃなかろうか。

　いま適用されてるマスターページと同じものを二重に適用しようとするとテキストフレームが消失したりなどする、という問題がまずあった。
　その問題自体は、「いま適用されてるマスターページと同じものは適用しない」チェックをひとつ仕込むだけで回避できた。
　それはそれでよい。

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してる時の僕がぐるぐる思ってたことはよく憶えてる。そこにそういう迷いがあること自体、「プログラムが」じゃなくて「僕が」比較検証する気でいた、としか考えられないよね(^^;;;。そんな筈ないのに。

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);
}

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

　実際の処理も慌てて一部手直し。嗚呼。

　僕内部では「7月案件」と呼ばれている、夏コミ向けの組版&入校データ作成作業に向けた準備中。

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

　あと「データのやりとりにDropboxはいかがでしょう」的なセールストークもする(苦笑)。
　いやDropboxで直接ファイルがやりとりできるの本当便利なんだって。実際今、ほとんどの相談事はTwitterのDMとDropboxで完結しちゃってるし。

　縦書きで左ページから始まるドキュメントをスクリプトから(でなくても)PDF形式にエクスポートする時に、レイアウトを「見開きページ(表紙)」に変更する方法を探しているんだけど、これがまったく見当たらなくて困り中(苦笑)。
　そもそもPDFExportPreferenceに該当値がないっぽいので、本当に不可能というか、手段そのものが存在しないんじゃないかと思われるんだが、不便だから何とかして欲しいなあ‥‥‥。

　次の実験として、ドキュメントじゃなくてブックを対象にした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以外の全内容」を本文の出力データとして使い、印刷結果を複合機の中で組み合わせながら製本していく、っていう作業をいつもやってるワケなので、コマンド一発でコレができるだけでも一定の恩恵はあるのであった。

　ブックからPDFを出力する試みが大体形になった、のトコまでは大変めでたいんだけど。

　次のステップ。PDFファイルのプロパティを編集したい。
　具体的には、通しのドキュメント上で先頭ページのノンブルが奇数なら、そのパートのPDFはページレイアウトを「見開きページ(表紙)」に、ノンブルが偶数なら「見開きページ」にした状態のPDFが欲しい。
　でもこれは、InDesign側のスクリプトでは設定項目自体がなく、AcrobatをActiveX経由で操作するようなやり方でも無理っぽい。
　Acrobatにアクションスクリプトを登録すれば核心部分の作業そのものが比較的簡単に実現できるっぽいのは実験が済んでるけど、それと組み合わせるにしても、特にコトの前後が結構いろいろややこしくて辟易中。

• アクションスクリプトが処理対象にするディレクトリは固定する必要がある
  • このため、仕組みは作れても、第三者に配布するのがちょっと難しそう
• InDesignスクリプトからアクションスクリプトが処理対象にするディレクトリへPDFを直接出力するのもなんか変なので、PDF出力先→アクションスクリプト用ディレクトリ→PDF出力先のファイル移送手段を実装する必要がある
• バッチやWSHからアクションスクリプトを直接実行できるかどうかを調べていないのだが、実行できない(&終了タイミングを検知できない)とすると、アクションスクリプト部分だけはどうしても手動で実行せざるを得ない
  • 往路の移動が済んだら「アクションスクリプト処理完了後にOKボタンを押してください」ダイアログでも出しといて、そのダイアログが閉じたら復路の移動を始めるような奴でいい？(笑)

　ややこしいとは言いつつ、僕の手元に絞った話としては「多分どうにか仕組み化できるだろうな」って手応えもないではないものの、このアプローチだとそれを他人に渡すことの難易度が高すぎてなあ。
　CUIのPDF編集ソフトみたいなのも幾つか試してみた方がいいんだろうか。

　東京駅で森原せんせと合流。
　本題の受け渡しを手早く済ませた後、秋葉原に移動して何軒か本屋巡り。

• さおとめあげは「ニンジャスレイヤー グラマラス・キラーズ 1」
• さおとめあげは「ニンジャスレイヤー グラマラス・キラーズ 2」
• さおとめあげは「ニンジャスレイヤー グラマラス・キラーズ 3」
• 三宅大志「ろんぐらいだぁす！（7）特装版」
• ポストメディア編集部・編「触手の描き方」

　正直、「触手の描き方」以外は電子版全部押さえてる本なので、特に事情がなければ物理書籍とか買う必要ないところなんだけど。
　ろんぐらいだぁすは特装版のメディア目当て。
　グラマラス・キラーズはドラマCDキャンペーン応募用の帯が都合3枚手に入りさえすれば組み合わせは何でもよかった。そういう意味でベストなのはまだ電子に来てない「ニンジャスレイヤー殺」の1〜3それぞれに帯が付いてることだったんだけど、殺だけ講談社のコミックスだからなのか、殺の1と2にキャンペーンの帯が付いてる状態の本がどこにも見当たらず、だからといって3だけ3冊買うのも変な話なので、まあ「3冊で終わってる」ものを。
　触手のソレはつい出来心で。買ったからナニってコトは別にないというか、店頭で中が見られるなら買わなかったかも知れないくらいの感じ(苦笑)。

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

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

　最後に錦糸町駅併設のヨドバシカメラを冷やかして、錦糸町駅構内で森原さんと別れて帰宅。

　PDFファイルのプロパティの話の続きで、昨夜日記をアップしてから今日に至るまでに判明したあれこれ。

luci2 00:06:20	:	PDF書き出しプリセット、InDesignCCは設定項目「レイアウト」があり、互換性：Acrobat 7(PDF1.6)以上なら「見開きページ(表紙)」「連続見開きページ(表紙)」が選択できる。CS6の方は「レイアウト」自体ない。 pic.twitter.com/5zEyycXBqe
luci2 00:08:47	:	これ、CCで作ったプリセットを使ってCS6から出力したらどうなるんだろう‥‥‥(苦笑)

　といった次第で、この際、本当に必要なPDFプリセットの精査と整理をちゃんとやろう、と思い立ちつつある。

　例えばPOPLSはPDF/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でも動くに越したことはないんだけど、その辺はどうなんだろうなあ。

　昨日買った「ろんぐらいだぁす！（7）特装版」のCDメディアから音声データをリッピングしたり、昨夜の考えごとについて引き続き首を傾げたり、昨夜遅くにサンプル投げた反応に従って7月案件の本文フォントを変更したり、比較的穏やかに過ごす。

　発売は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。

　この字面を係名として応募ハガキの宛書きに書かせるというジゴクめいた所業にヘッズ戦慄。
　いきなりペンで一発書きが成功したのはラッキーだった‥‥‥。

　というワケで、大分遅きに失した感はあるものの、今日の昼休みに応募ハガキを作成した。帰りに適当なポストに投函すれば申込は成立するであろう。
　ちなみに、既に電子版持ってるにもかかわらず、物理書籍のグラマラス・キラーズを急に3冊纏めて買ったりしてるのは、この応募ハガキを作るのに、応募券の付いた帯が複数枚必要だったから。
　‥‥‥電子書籍のデメリットはこういうところにもあって、つまり「確かにその本を買いました」っていうことのエビデンスを提示するのが難しいワケね。
　あらゆるデジタルデータは捏造リスクと隣り合わせであり、そこを抜きにしてエビデンスを提示するとしたら、本人確認の上で、特定書籍に対する決済を実施したことを証明する資料をベンダから相手に提出させるとか、何かそういう小難しい手続きの話になっていく。
　これが物理書籍なら「本に付いてる帯の一部を切り離せば応募券になります」で済んじゃう。いやまあ、帯だけ万引きするとか、何だったら本ごと万引きするとか、そういう手順によって不正に得ることもまた可能になっちゃう部分は電子書籍では考えにくくて、そういうあれこれまで含めた話としては、どっちがいいとも悪いとも簡単には言えないんだけど。

　ここ書いてるの翌日なんだけど、昨夜は本当に眠かったので何もしてない。
　平日→平日にしては珍しくトータル9時間とか寝てる。普段4〜5時間なのに。

　特記事項があるとすれば唯一、コンビニ受け取りの設定で注文してた三宅隆太「スクリプトドクターの脚本教室・中級篇」が届いたので、帰り際に引き取っただけ。‥‥‥初級篇共々、ただ積んでるだけでは何の実にもならんのだよなあ(苦笑)。どうにか読もう。

luci2 22:36:12

:

ショベルナイトDLして始めたところで風呂が沸いたので中断。まだ1面のチェックポイント2番目。よくも悪くも見たまんまっていう印象。

　最初の面を解いて村を通過、上と下が選べるので下から攻略しようとしてるんだけど、これ何か判断を誤ったかも知れない。

　跳ねてる蛙に下攻撃を当てたリバウンドで上空の足場に乗れ、って言ってる(ようにしか思えない)箇所があるんだが、そこがクリアできなくて難儀中。
　実際、同じ面の冒頭で、そうやらないと越えられない絶壁を越えてきてるワケだけど、動く足場に乗れるタイミングで蛙が飛んでくれるかどうか、そこに上から覆い被さることができるかどうか、を両立するのって相当ハードル高い気がする。そもそも手前の絶壁だって、今の腕前じゃ百発百中で越えられるワケでもないだろうしなあ。

　SHL25で使ってたソフトの使用期限が切れたこともあり、買うだけ買ってあったパッケージのシリアルを使ってユーザ登録を済ませ、IDとパスワードを得たんだけど、その情報を使っても「通信が失敗しました(21002)」とかいう謎メッセージが出て成功しない、という問題があることに、最初に気づいたのは実は昨日の日中。
　FAQを見てみると「ユーザー名、または、パスワードが正しく入力されていない場合に表示される」って書いてあるし、そんなこと百も千も承知の上で正確な入力を心掛けてるものの、でもまあ、ダメなものはダメで。
　しょうがないので今朝、サポートに電話で聞いてみたのだが。

　担当の女性が最初に尋ねたことは、「Google Playからダウンロードされましたか？」だった。

　率直な感想として「何言わされてるのかちゃんと理解してない感じ」だった先方が、恐らく説明したかったのであろうことを簡単に纏めると。
　Google PlayからDLできるのはグローバル版で、日本で販売代理店をしているキヤノンITソリューションズの発行するライセンスが機能するのは日本版なんだと思われる。多分だが、グローバル版のライセンスサーバとキヤノンの持ってるライセンスサーバが別のものなんだろう。
　なので、キヤノンITソリューションズが卸したパッケージ版のシリアルから得たユーザ名とパスワードは、ここからDLした.apkファイルを直接実行してインストールしたソフトからでないと、有効な情報として認識されないんだそうだ。
　そして勿論、事前に「提供元不明のアプリのインストール」設定にチェックを入れておく必要がある。
　‥‥‥セキュリティソフトをインストールするために端末のセキュリティリスクを上げないといけないとか、それ自体が矛盾を孕んでると思うんだけど何なのそれ。

　とはいえライセンス買っちゃったものはしょうがないので、Google Play版をアンインストールし、.apkから直接インストール。その後でアクティベーションしたらすんなり認証が成功したので、原因がそこにあったのはもう疑いようもない。
　また、いま調べたらまったく同じ事象について言及があった。‥‥‥この方は

非常に紛らわしいです。
できればもう少し目立つところにこういう説明は書いていただきたいとおいうか。
どちらというとライセンス認証の際のエラー画面に案内のリンクぐらいは貼っておいて欲しいところです。

　と仰るけど、僕が問題だと思うのは「Google Playのアプリ紹介画面の方に、それとわかることが何も書かれていない」点だと思う。‥‥‥だからまあ、コレを書くのはグローバル版のスタッフの仕事で、彼らの方は自分たちやってるグローバル版のこと以外は関知しないから、ローカライズ版(例えばキヤノンが販売する日本版)のことは日本版の販売元に聞いてね、っていう話なんだと思うけど、そこに捩じ込まなきゃ告知にならないだろうになあ。