luci2 15:24:07

:

【ゆる募】InDesignからページをJPEGに書き出す時に、その絵の中にフレームグリッドも出力させる方法ってないのだろうか。それができた方が説明用の画像が作りやすいアレがあるんだけど‥‥‥。

　なんで今コレかというと実はまだ諦めてないからだけど、とはいえまあ、無理だろうなあ(^^;;;。

luci2 18:12:45	:	エクスポート時に直接レイアウトグリッドを可視化する方法はまだわからんが、PDF出力時にガイドを一緒に出すのは可能だったので、激しく冗長だが「ガイドごと出力してPDFを作る→テンプレートにPDFをページ単位で配置する→全ページ個別にJPEG画像化する」で、一応、升目付きの画像を得るなど pic.twitter.com/JbLiIjulb0
luci2 18:18:00	:	はんなり明朝とかに至ってはもう、ダーシ繋げる気がまったくないフォントであり(笑)、そもそもダーシ自体がこういう字形となると「平体ダーシ」の結果も悲惨。どうしても本文をはんなり明朝にしたい、しかしダーシは繋げたい。とかいうことだとすると打ち消し線に逃げるしかない。
luci2 18:21:33	:	縦組みすると自動で罫線が寝るフォントとそうでないフォントという差異もまたあり、例えば源ノ角ゴシックを縦組みして罫線でダーシを置き換えるなら縦向きの罫線を使う必要があり、同じことをMS明朝でやるなら横向きの罫線を使う必要がある。 pic.twitter.com/E6BuGfkHLj
luci2 18:24:10	:	取り敢えず本に書こうと思った段階では「だいたい何でも平体使っとけば大丈夫じゃね？」くらいの浅い考えだったんだけど、弄れば弄るほどドツボに嵌まるというか、こうした諸々をケースバイケースで見ないと最良の誤魔化し方が見出せないことに気づき始めてしまっている、というのが最近の状況‥‥‥

　わからんなりに力業で何とかしたのがここまでの話。
　職場のCS6にそんなオプションなかった気がしたんだけど、実際できてしまった今となっては気のせいかも知れない‥‥‥。

peprintenpa 21:26:20

:

@luci2 ファイルメニューの下の方見て！

　ということで、教えていただいたのが

　このダイアログのこと。

luci2 22:01:04	:	@peprintenpa できました‥‥‥必死でグリッド位置合わせしたのに‥‥‥(^^;;; pic.twitter.com/cW9zOzRm1q
luci2 22:13:02	:	@peprintenpa 直接JPEGにエクスポートする時にフレームグリッドが出せるワケではないんだな。PDFを経由して画像化の部分は一旦現行方針のままで。
luci2 22:31:03	:	一旦PDFを経由するかたちにはなってるけど、スクリプト一発でこういうのがJPEG画像になって出てくる仕組みが取り敢えずできた。 pic.twitter.com/O7XSUbDm14

　フレームグリッドを出力データに混ぜられるのはエクスポート先がPDFの場合とEPSの場合だけらしいので、まあ、InDesignドキュメントに貼って使う想定の画像なんだからEPS作ればいいのかもだけど、取り敢えず取り回し的にJPEGとかが楽なので、一旦PDFを出力し、そのPDFをページに貼って、貼ったページをJPEGエクスポートするというアレで(笑)。

//グリッドのプリントプリセット取得
app.gridPrintingPreferences.frameGridPrinting = true;
app.gridPrintingPreferences.layoutGridPrinting = true;
app.gridPrintingPreferences.pageItemPrinting = true;
app.gridPrintingPreferences.textPrinting = true;

//PDFエクスポート
document.exportFile(ExportFormat.PDF_TYPE, File(PDFファイル名), false, pdfExportPreset, true);

　スクリプトからPDFエクスポートする時にどうするかっていうのがパッと検索しても出てこなかった感じがするので、具体的なこともちょっと書く。
　app.gridPrintingPreferencesにtrueとかfalseとかをいろいろ設定する。その上で、document.exportFileメソッドの第5引数(defaultはfalse)をtrueにすると、app.gridPrintingPreferencesに書いてある通りの設定でグリッドも出力される。これだけ。簡単でよかった(^^;;;。

　2周目「第48話 暗黒の王、光の勇者」攻略中。

　遂にというか何というか、ガンダム・バディコンプレックスルートの「第45話 光る風の中」でSRポイント取得に失敗した。
　これがもうひとつ釈然としないのは、別に「難しいから無理だった」のではなくて、特に2度目以降は、僕の感覚的には毎回条件がクリアできてる(のに獲得できてない)から、ってところなんだけど。何度かやり直したし、都度条件には気をつけてるんだが‥‥‥これまで数回の試行から考えられる要因もひとつあるにはあって、もしかしたら、援護攻撃で撃墜する場合には援護攻撃の担当ユニットが『Exコマンド「スマッシュヒット」を使用』の状態じゃないといけない、ってコトなのかも知れない。それも条件に含まれるなら確かに失敗してる。
　つーか5機だかいる敵ボス(全部撃墜がSR条件)全部を『Exコマンド「スマッシュヒット」を使用』の状態で撃墜、っていうのもそれ自体が結構厳しいよねえ(苦笑)。そのために雑魚敵がいっぱいいるでしょって話なんだろうけど、初回はまんまと熱血サイフラッシュで雑魚敵を除去しまくった結果ExCが足りなくて失敗(苦笑)。でもそれ以降はちゃんとできてる筈なんだけどなあ‥‥‥。

　『try〜catch構文を使わず、fontsの配列を全部ループして名前の一致を確認する方法でもなく、「その名前のフォントが扱えるかどうか」をInDesign+ExtendScriptで知る方法』に関する話の続きの続きの続き。
　もうちょっとだけ続くんじゃ‥‥‥。

luci2 10:24:17	:	fontオブジェクトのプロパティ話の続き。fontStyleNameとfontStyleNameNativeに別個の文字列が入ってるフォントの場合、どっちを指定したらapplyできるのか調べてるんだけど、幾つか掻い摘んで実際やってみたところ、どうやらこれはどっちの値でもいいみたい。
luci2 10:25:48	:	例えば「ＭＳ ＰゴシックRegular」はfontStyleNameが「Regular」、fontStyleNameNativeが「標準」だけど、以下はどちらでも成功する。 story.appliedFont = "ＭＳ ＰゴシックRegular"; story.appliedFont = "ＭＳ Ｐゴシック標準";
luci2 10:26:44	:	あ、Twitterだからタブ文字が書けないんだけど、「ＭＳ Ｐゴシック」と「Regular」ないし「標準」の間にタブ文字が1個ある。

　割と迂闊な感じで「ウェイト文字列としてfont.fontStyleNameを使う」関数とか作ったんだけど、これがまた「font.fontStyleNameを使わないと死ぬ」場合と「font.fontStyleNameNativeを使わないと死ぬ」場合とかに分かれてたら嫌すぎて死ぬなあ、とかいうことを今朝ふっと思って、怖くてしょうがないので一応幾つか検証してみた(苦笑)。

story.appliedFont = "ＭＳ Ｐゴシック	Regular";
story.appliedFont = "ＭＳ Ｐゴシック	標準";

　font.fontStyleNameとfont.fontStyleNameNativeが異なる文字列であるフォントを幾つか選んで上記のような構文を試してみたんだけど、ウェイト部分に関しては、どちらを書いても成功することがわかって一安心。
　なので「ウェイト文字列としてfont.fontStyleNameを使う」でも構わない筈であり、昨日の関数はあのままでよい。よかったよかった(^^;;;。

luci2 10:26:44	:	あ、Twitterだからタブ文字が書けないんだけど、「ＭＳ Ｐゴシック」と「Regular」ないし「標準」の間にタブ文字が1個ある。
Uske_S 10:30:16	:	「フォントをapplyするメソッドにはファミリー名とウェイト名の間にタブが必要」ってことを知らなかった頃、すごい苦労したなぁw twitter.com/luci2/status/9…
luci2 10:31:32	:	@Uske_S ああ、わかります‥‥‥(笑)
Uske_S 10:32:09	:	@luci2 これを発見したときの感動はひとしおでしたねwww
luci2 10:34:25	:	@Uske_S font.nameをファイルに落としたものをExcelにコピペしたんですが、タブ文字だからフォント名とウェイトが自動で別セルになるので、「実はそこは2セル分で1項目だ」と気づくまでに相当頭を捻りました(^^;;;
Uske_S 10:44:42	:	@luci2 なるほどー！！！ スプレッドシート！僕は地道にESTKで謎解きしてましたw
luci2 10:50:03	:	@Uske_S ウェイトは違うけどフォント名は同じっていうのをフォント名の指定だけでどうやって表現するんだろう的な‥‥‥もしかしてlocation(ファイル名)で指定しなきゃダメなんじゃないかとか、fontStyleNameと2プロパティを同時に指定するんじゃないかとか‥‥‥
Uske_S 12:04:54	:	@luci2 試行錯誤の跡が……w

　確かに、「フォント名・タブ文字・ウェイト」っていうこの指定方法は、正直言って未だに違和感ある。
　もう結構前だけど、この辺のプロパティ弄り始めた頃は、本当にその違和感に騙されて『「フォント名・タブ文字・ウェイト」のセットがfont.nameの値そのもの』なのに「フォント名だけでどうやってウェイト指定したらいいんだ‥‥‥」とか真面目に考え込んでた時期もある(苦笑)。
　んでまた、僕はツイートにある通り「全フォントのfont.nameを一旦テキストファイルに出力してExcelのワークシートに貼る」みたいな観察手法をとってて、これ文字列がタブを含むとそこでセルが変わっちゃうから、font.nameは1個のプロパティなのに、Excelのセル数換算だと2セル分の情報が出力されてることになっており、でも当初そんなこと知らないから、「font.nameにはフォント名が入ってる(=ウェイトは含まない)筈なのにこの余計なウェイトの情報は何だろう？」的な、今にして思えばそもそも疑い方からおかしい、っていう感じになってた。

　「知らないことは知らないのだ」ということを正しく知っていないと、既に持ってる知識のせいでむしろ眼鏡が曇ることがあり、結果こういう変な予断で自滅することがあるので、そういうとこは今後も気をつけれ＞自分。

luci2 10:52:51	:	実はESTKほとんど使わないんだよなあ。ステップ実行できて変数の中身が覗けるのは最高なんだけど、エディタ部分がきもちわるすぎて嫌‥‥‥
luci2 10:54:57	:	今回みたいに「フォントの呼び出しが成功してる場合と失敗してる場合とで、オブジェクトに現れたプロパティの数や中身を見比べる」みたいなことをする場合には超・便利だし、いや便利っていうか「どのプロパティが見たいか」が事前にわかってないケースでは、そもそも他に手段もないんだけど

　さらにいうと、一覧作らないとデータの特徴がわからないんじゃないかと思ってそういう手法にしたんだが、ESTKで変数の中を直接見るチェックの方を先にやっていれば、誰がどう見ても「フォント名・タブ文字・ウェイト」のセットが設定されてるワケだから、拗らせる前に気づいた可能性が高い陥穽ではある、とも思う‥‥‥。
　でもESTKのエディタきもちわるい‥‥‥(^^;;;。

　金曜のあるふぁ（仮）さんの調査の中で、

peprintenpa 17:44:01	:	@luci2 \t以降を落さずにindexが取れるやつは落とすと全部-1になって、ちょうど真逆になるっぽいですね pic.twitter.com/XA9tgQGAoB
peprintenpa 17:45:07	:	@luci2 画像は↓の実行結果です for(i=0;i<300;i++){ f=app.fonts[i]; $.writeln(i+"\t"+app.fonts.item(f.name).index+"\t"+app.fonts.item(f.name.replace(/\t.+/,"")).index+"\t"+f.status.toString()+"\t"+f.name) }

　ここまでは調べがついており、かつ、僕もやってみた限りにおいて、職場環境とプライベートのどちらからも『「ウェイト文字列あり」と「ウェイト文字列なし」のindex値が両方-1であるインストール済みのフォント』はひとつも検出されなかったので、差し当たり、これを結論としてよいと思う。

luci2 18:33:10	:	取り敢えず職場PCにインストールされてる1724個だかのフォント全部について調べてみたけど、確かに「ウェイトあり」と「ウェイトなし」の両方でindexが-1になる奴はいなかったし、両方が-1でない奴もいなかった。
luci2 18:35:28	:	退勤したらプライベートでも調べてみるけど、「片方が0以上ならもう片方は-1」であり、「どちらかが0以上であるフォントは使える状態にある筈(なのにapplyできないとしたら多分なにか書き間違ってる)」ってことでよさそうかな。

　‥‥‥なんだろう、僕は最初に運よく取っ掛かり部分を場に出せただけで、それが本当に実用に耐えるアイデアなのかどうかを検証する段における大変な部分は大体あるふぁ（仮）さん任せになっちゃったような感もちょっとある(^^;;;。
　その節は大変お世話になりました。ありがとうございました。

　そんなこんなあってからの。
　『try〜catch構文を使わず、fontsの配列を全部ループして名前の一致を確認する方法でもなく、「その名前のフォントが扱えるかどうか」をInDesign+ExtendScriptで知る方法』に関する話の続きの続き、というか、まとめ。
　あるふぁ（仮）さんのを見習って「タブ文字以降を除去」の正規表現をシンプルにするなど、ちょっと手を加えた結果としての現在版チェック関数がこう。

//その名前をフォント名としてapplyしても怒られないかどうか調べる
function checkFontEnable(name)
{
	return (app.fonts.item(name).index + app.fonts.item(name.replace(/\t.*$/, "")).index !== -2) ? true : false;
}

　見出されたルールを要約すると『あらゆる「2通りの方法で取得したindexが両方-1(なので足し合わせると-2)でない」は怒られない』なので、怒られないかどうかが判明するだけでいいのであれば、究極、関数の中身はこれだけでよい。
　あんまり三項演算子とか好きじゃないんだけど、まあ、実は簡単ですねってことの表現として「1行で書けちゃいます☆」くらいのハッタリがあってもいいかも、的な。

//その名前をフォント名としてapplyしても怒られない場合はフォント名を返す
function getEnableFontName(name)
{
	var result = "";
	if(0 <= app.fonts.item(name).index)
	{
		result = name;
	}
	else
	{
		var check = name.replace(/\t.*$/, "");
		var font = app.fonts.item(check);
		if(0 <= font.index)
		{
			result = check + "\t" + font.fontStyleName;
		}
	}
	return result;
}

　「ウェイト文字列は間違ってる(かも知れない)がフォント名は正しい場合に、プロパティから取得したウェイト文字列で上書きしてからフォント名を戻す」バージョンの方はあんまり合理化の余地がないような。

　いずれにせよ、「ウェイト文字列を省くとindexが-1になるフォントで、フォント名は正しいがウェイト文字列が誤っている場合」を救うことは結局できないのだが、もうそれは仕方がないものと考えている。
　そういう理由により、「その名前をフォント名としてapplyしても怒られない場合はフォント名を返す」の方がより使いどころに困るというか、まあ要するに、「その名前をフォント名としてapplyしても怒られないかどうか調べる」の方だけ知ってれば取り敢えず問題ないのではないかと思う(笑)。

　昨日の試し斬りの様子を軽く纏めたり。

　1周完了。
　女の子主人公だったので、次は男の子主人公で即座に2周目開始。

　結局1周目は全てのSRポイント獲得にいきなり成功した。
　ゼルガードとサイバスターが強ければ普通のマップは大体何とかなるんだけど、やっぱVita版は全体的にスーパー系が有利なのでというか、体力の減ったボス敵相手のリアル系ユニットからの攻撃が本当に全然効かないので、グレンラガンとかWマジンガーとかダイターン3とか育てておくといい。リアル系に偏りきらせると苦労すると思う。
　‥‥‥つーか、Vita版以外のスパロボではガオガイガーくらいしかまともに育てないスタイルでお馴染みのリアル系で何とかするマンこと僕がマジンガーだのダイターンだのを重用している事実を、僕とスパロボをよく知る人は衝撃をもって受け止めているのではなかろうか(笑)。

　ちょっと前に遊んで楽しかったゲシェンクとナインタイルを押さえたので試し斬り大会。
　面子はパパさん&スイさん&僕。

　ほんと説明が全然要らなくて誰が誰とやっても楽しいのがすごいなこれ。
　お題のカード自体が正方形で、どの向きで出るかによって出題内容も変わることを考えると実質的に問題の数はカード枚数の4倍あることになり、いつまででも遊んでられるのもすごい。

　あとコレに関しては、まずパパさんが頭角を現し、次いでスイさんが覚醒し、僕に関しては最後までまったくいいところがなかった(笑)。取り敢えず今のところは、あんまり僕が得意なタイプのゲームではないのかも。

　思った通り、おもしろかったので後にもう一回やることになるくらい盛り上がった。
　これも説明簡単だし、ちょっと触ってみればすく勘所も掴めるし、場は盛り上がるしで言うことないなあ。

　大人同士でも全然楽しいなこれ。
　目が慣れてくるとだんだん普通のカルタになってくるのであんまり何度もは続けられないけど、何かと何かの間にすぽっと突っ込むのにはすごい向いてそう。
　ちなみにこれは僕とスイさんが成績よかった。

　実はまだ回してなかったので。

　これのことを書こうかどうしようかですげえ悩むのが‥‥‥ええと、マニュアル熟読の上、全員手札オープンの状態で1周、さらに普通のプレイも1周やってはみたものの、これはゲームとしてどこをどういう風におもしろがればいいのか、みたいなところが全然伝わってこなかった。「自分の行動」と「勝ち負け」の関係がよくわからず、だから自分が何のために何をしているのかよくわからないまま、枕を投げたり情報を公開したりカミングアウトしたりを作業としてやってるだけ、みたいな感じに。

　後述の「THE 残業」もルールをきっちり読み下した後であればちゃんとおもしろかったりしたワケで、どういうところにおもしろさのポイントがあるのか、みたいな部分を、わかってる人に一度説明してもらえたら見方が変わったりするんだろうか。

　前回遊んだ時にルール解釈に関する議論が紛糾したのを受けて、どういう時にはどういうカードを出していいのか、について独自に纏めた資料(zip圧縮のPDF)があるので、他にも迷ってる方がもしいらしたら参照していただければ。
　今回は最初からこれを場に置いてのプレイ。
　案の定、どう言う時には何をしていいのか、勝つためには何をどうしたらいいのか、みたいなことに先に整理をつけて、ゲーム自体の楽しさだけを受け取れるようになった結果、初回プレイの時よりも全然おもしろかったし燃えた。これでいいならまたやってみようって気になる感じ。

　そういえばこの面子ではやったことなかったので。

luci2 18:11:29

:

今日の横暴編集長(本採用会議)。ちょっと上げてあるタイトルが出版決定。 pic.twitter.com/KKvcTtJKir

　いや出せばおもしろいしみんな喜ぶのはわかりきってるんだけど、カードというか短冊が切りにくいし扱いにくいことには、正直、遊ぶ度に辟易する。みんなコレどうやって切ったり配ったりしてるの？(^^;;;
　あと、やっぱこのゲームはもっと人数が多い方がおもしろいなあ。他人の頭の中から何が飛び出すのかわからないワクワク感が、総勢3人とかだとすぐ途切れちゃう‥‥‥。

　これも悩むんだけど‥‥‥正直、マニュアルをどれだけ読んでも、何をどうしたらいいんだかよくわからなかった。あとカード同士がくっつきやすいというかカード離れがよくないというか、切ったり配ったりがものすげえやりにくい。
　総じて、このままだったらもう遊ばないと思う。ゲーム作るのって難しいんだなあ‥‥‥。

　ちょっと買い出しに行って戻り、録画してあった「孤独のグルメ Season7」の第1話とか観ながら夕飯。
　ドラマパートは同じ店のランチタイムを見せつつ、原作者がビール呑みに行くパートはディナータイムに時間をずらして両方を紹介する的な、店舗プロモーションとしての手際が明らかによくなってるのがおかしいやらほろ苦いやら。

　この「ゲシェンク」というオトナのワルい遊びは酒呑みながらやっても楽しそうだよね、という話になり、夕食後にビール呑みながら再戦。
　なお、ここからゲシェンクのパッケージ付属のトークンの代わりに手持ちのポーカーチップを使用、5色各20枚のうち3色11枚ずつを各自が持って開始。決着後、次戦の準備が飛躍的に簡単になってナイス。
　んでやっぱ酒が入ると各々プレイがちょっと変わってまた楽しかった。これはよい(w。

　昨日の仕組みを持ち帰ってInDesign CC2018で試してみたんだけど、でも実は、思ったより多くのフォントで適用不能判定が出ることにちょっと首を傾げたのだった。
　処理に渡してるリストの中身っていうのは基本的にfontオブジェクトのnameプロパティに書いてあること(「フォント名・タブ文字・ウェイト」の組み合わせ)なので、自分の中に書いてあることを自分に戻して上手く行かない筈はない‥‥‥と考える方が普通だと思うんだけど、だがしかし、理由はわからんが上手く行かないものがしかも結構あるっぽい、という結論だけを、昨夜の段階では確認するに留まった。
　メジャーなところでいうと、例えばMS明朝とかMSゴシックがP付き含めてこのパターン。メイリオでは問題は起きない。

peprintenpa 12:14:31	:	@luci2 使えるのに-1なのがウチの環境だと結構あったりします…
peprintenpa 12:26:32	:	@luci2 一応font.statusっていうプロパティもあります でもapp.fonts.item(n)の中にstatusがNOT_AVAILABLEなのがたまにあったりして闇が深いです。

　同様のことが他の人から指摘されたりもしていたんだけど、その後もあれこれ弄くり回してる中で、

//その名前をフォント名としてapplyしても怒られないかどうか調べる
function checkFontEnable(name)
{
	var result = false;
	if(0 <= app.fonts.item(name).index)
	{
		result = true;
	}
	else
	{
		var check = name.replace(/^(.+)\t[^\t]*$/, "$1");
		if(0 <= app.fonts.item(check).index)
		{
			result = true;
		}
	}
	return result;
}

　例えば「apply可能かどうか」が知りたいだけなのであれば、突き詰めるとこういう判定でよさそう、という感じのことが見えてきている。
　即ち、

• 「フォント名・タブ文字・ウェイト」の組み合わせ(font.nameに入ってるデータそのまま)の文字列を作ってapp.fonts.item()に渡し、font.indexの値をチェックする
• このfont.indexが0以上であるなら、そのままapplyしちゃって大丈夫
• このfont.indexが-1である場合は、「フォント名・タブ文字・ウェイト」の組み合わせからタブ文字・ウェイトを除いたフォント名だけの部分文字列を作ってapp.fonts.item()に渡し、font.indexの値をチェックする
• このfont.indexが0以上であるなら、「フォント名・タブ文字・ウェイト」を直接app.fonts.item()に渡した場合のfont.indexが-1であろうとも、applyしちゃって大丈夫
• このfont.indexが-1であるフォントは本当に存在しない筈なので、applyしようとすると怒られる

　こういう感じ。
　ただしこれは

• 「フォント名・タブ文字・ウェイト」の組み合わせからタブ文字・ウェイトを除いたフォント名だけの部分文字列を作ってapp.fonts.item()に渡し、font.indexの値をチェックする
• このfont.indexが-1であるフォントは本当に存在しない筈なので、applyしようとすると怒られる
• このfont.indexが0以上であるなら、「フォント名・タブ文字・ウェイト」を直接app.fonts.item()に渡した場合のfont.indexが-1であろうとも、applyしちゃって大丈夫

　こういうかたちで合理化しちゃうと逆に救えないフォントっていうのがあったのが嫌らしいところ。
　ウェイト付きなら-1以外が返るけど、ウェイトを省くとむしろ絶対indexが-1になってしまうフォントってのも存在することに注意する。例えば小塚明朝とかがそうっぽい。

　この辺の考え方を盛り込んだ改善版が既にあるので、今日はそれを持ち帰ってCC2018でも動作確認してみる。