にせねこメモ

はてなダイアリーがUTF-8じゃないので移ってきました。

「フレンズの会」まとめ

アニメ

2017年4月29日と6月3日に「フレンズの会」という、アニメ『けものフレンズ』の制作スタッフが集まり作品について話すトークイベントが行われた。基本的に2回とも同じ内容であり、6/3は再公演という体である。今更だけどメモをまとめておく。

メモから起こしているし時間も経っているため、あやふやな所もあると思うのでご容赦いただきたい。他の人がまとめているものがあると思うので比較しつつ読むとよいかもしれない。

以下、基本的に敬称略とした。

プロデューサーパート

プロデューサー・細谷(テレビ東京)、アニメーションプロデューサー・福原(ヤオヨロズ)

4/29

  • ニコニコ超会議でけものフレンズのキャラ(のグッズを売ってるところがあった)
    • 2次創作推奨してるけどちょっと頒布のレベルを超えてるというか…
  • ヤオヨロズのやり方は何がなんだか分からない(細谷)
  • 3行位の各話のあらすじが去年の夏前に
    • 普通はシリーズ構成の人が全体の骨子をかき、シナリオライター・脚本の人がシリーズで4～5人、あと何度も見ていく
  • 「作り方違うっぽいんで大丈夫です」(と言っていた) (細谷)
  • 最初の方嫌いでした(細谷)
  • 最大の功績はあきらめたこと(細谷)
  • 委員会十何社、何でヒットしたか誰もわからない(福原)
  • 黙ってたことだけが仕事(細谷)
  • 「たつきを信じろ」が、委員会でも同じ感じ(福原)
  • ファミマプリント、サーバーが落ちた
  • 基本全部落ちてる
  • ラインスタンプ、使い勝手がよい
    • 6話までのファン投票
    • 『ゔっ』(バスにはねられるサーバル)は使い勝手が悪いからだめだとライン社に言われたが、通した
  • 5/26一挙配信 LV30館くらい
  • 舞台 結構前から決まってた

6/3

  • 三行のあらすじだけで10月、11月までひっぱった
  • 前特番のバラエティ(0話)に金田さんと小林さんを使いたかったので本編に入れてもらった(細谷)
    • 金田さんはトキを、小林さんはツチノコを知らなかった
  • 0話をいつにするか会議をしていた。初めにしてよかった(7話位に入れる案もあった, 制作側としては途中で挟まった方が楽)

ほか権利的な話、けものフレンズは二次創作を推奨してるけれど、商業みたいなのはちょっと…みたいな話。同人の範囲なら、とか

制作パート

美術監督・白水、作画監督・伊佐、監督・たつき、アニメーションプロデューサー・福原
1～4話の映像を流しながらコメンタリーという感じ。
2回の話をマージするのも難しそうだったので左右に並列させた。横ぶち抜きの見出しはシーンの目安だが厳密でない。

4/29の回6/3の回
  • 美術監督の役割は普通のアニメと同じ感じ
  • 作画監督の役割は普通のアニメの総作画監督と作画監督の役割
  • コンテの描き方
    • Vコンにするか、コンテ作った後にVコンにするか
    • 5種類くらい2～3話まで試した
一話最初
  • サバンナの乾燥感を出すのが難しかった、かさかさしてる草の感じ(白水)
  • 一話、キャラクター紹介がいっぱい出てくるのではなく、かばんちゃんとサーバルちゃんしか出てこない、美術の重みが大きい(福原)
  • 空と草と遠くに山(白水)
    • どこを向いても草原しかない
  • (省力化のために)壁をどうにかして(作りたい)と冗談で言ってみた
  • シマウマには悪いことをした
  • 難所を通る
    • (調べても)平原しかない。「あるからもっと調べろ」と言われて、探したら雨季の時削られた川、湖(があった) (伊佐)
  • 伊佐が設定周りを一貫してやっていた(たつき)
    • (それによって)深みがでた(白水)
  • 美術、作監、設定にも強い。ボードの作成など途中でも情報共有ができた(福原)
    • 結構スイッチする
  • サバンナの乾燥感を出すのが難しい(白水)
  • カットごっそりなくなったりとか(福原)
  • ミライさんとか出るか出えへんかとか(たつき)
  • 何回か作り直した(伊佐)
  • サバンナは大体が美術(福原)
    • 何もない。草、山、空、木…(白水)
  • 場面設定上起伏がある地形について調べて見つからなかったが、たつき監督に「絶対あるからちゃんと調べて」と言われて調べ直したら、雨季と乾期があるところで、流木などで起伏があるところがあった(伊佐)
  • はじめ、1話乾期、2話雨季とかだったが、だるいから切った(たつき)
  • 引き(の画)が多い(キャラが小さい)。自然物が多い。パーク感を出す(たつき)
  • 1話は世界観が分かる映像を持ってこないといけない(福原)
  • CGで全身写すと大変(たつき)
  • やっとサバンナの書き方に慣れたらすぐ密林に(白水)
  • 設定は使い捨てじゃんじゃんいく(たつき)
テーブル
  • だんだん文明物が出てくる(たつき)
  • 最初はかばんちゃんに名前がなかった、主人公って呼んでいた(白水)
  • 11話くらい、主人公のままオーダーを出してた(たつき)
  • しんざきさんとトークイベントしたい(福原)
  • テーブルなどの人工物を匂わす程度に出して行く(たつき)
  • バオバブの木のシーン…ストーリーが改変になって追加で作ったカット、没になった後に作り出した(伊佐)
  • 原作が無い作品なので、一回、結構つくって、半分くらいつくって、だいたいこんな感じの作品だねって感じで(たつき)
水場のシーン
  • 湿気…最初の乾燥感と差を出す(伊佐)
  • サバンナの水場の感じが難しい、さいしょ岩清水、日本庭園っぽくなった(白水)
  • つかみかけたところでさよなら、ストックができない(白水)
  • 最初の方話は聞いてた、ラフを用意してたが、どんどん変わるので軌道修正(伊佐)
  • ゲストキャラを使えるかどうかわからない、探り探りやっていた(たつき)
    • 4～5話でだいぶ確定
    • モデルとして使えるキャラで、その地域にでてくるキャラ(たつき)
  • サバンナ、雨季も出してもよかった(たつき)
  • ボード段階では雨季も描いてた(白水)
  • 2話は雨季の予定だったがジャングルと被る(たつき)
  • よくあるCGアニメはメインとなるステージつくっとけば、そこでしゃべってれば新しいモデルを用意しなくていい(福原)
  • モデルのリスト3～40体出すってことに「死ぬのか」って(福原)
  • 1話1体じゃしょっぱい(たつき)
  • お客さん目線のたつきと作る方のたつきといる(福原)
  • 動物の特徴を盛り込むってのに苦労した(伊佐)
  • サバンナの水場なので、どれくらい水々しくしたらいいか、日本の岩清水のようになってもいけない(白水)
  • (美術を描いてて)ジャパリパークがどれくらいの広さなのか分からなかった(白水)
  • (福原に見たことある景色なのか聞かれて)ちょいちょいどこかで見たとこあるな感がある(たつき)
  • 日本ではないので乾燥感をつけて差別化(たつき)
  • 硬い感じの葉、ブラシを作成して描いた、イネ科など(白水)
  • 調べるとイネ科だけでたくさんある(伊佐)
  • (映像をちょっと巻き戻して)見たこともない顔があった(たつき)
    • (ネットとかでよく見るサーバルちゃんのまぬけな顔)中割だった
ゲート
  • 1話、テイクが多かった(たつき)
  • 1話は結構作り直した(伊佐)
  • 没カットが雑誌に出てた
  • 雑誌の取材用に没カットに手を加えて嘘カットを作った(対セルリアン)
  • 劇伴は、ナチュラルな世界だけどセルリアンだけ異質感、デジタルな感じ
  • 最初強いなあと思ったけど、何回もかかるんで
  • カバの髪の毛は監督がつくった
  • 目の種類は意識して多くつくった、ハンコ絵になりにくい様に(たつき)
別れのシーン
  • 1話の脚本とシリーズ構成の相似性(福原)
  • 一話をまず上げて、全体と並行して構成と脚本同時にできたので、2～10話で全体で細かいところを回収していった(たつき)
  • 結構隠してる。後から気づいたり、人から教えられて知ることが多い(伊佐)
  • 全部を共有してるわけではない(白水)
  • 少しずつ小出しにされた(伊佐)
  • わかってかいちゃうとだめということもある、顔とかで分かるとだめ(たつき)
    • 声優とか顕著(福原)
  • アニメーターがキャラに感情を載せすぎるとだめなときがある(たつき)
  • 最初2話分を一話に圧縮(たつき)
  • 紙飛行機をスタッフの人にヨレヨレにつくってもらったが、ヨレヨレ感が足りなかったのでもっとヨレヨレにした(伊佐)
  • ヨレヨレにするのはCGでは難しい。「下手にすんのが下手」(たつき)
  • (再会のシーン) (この木実際にあるの?に対し)ユーフォルビアという木(白水)
  • 雨季エリアの設定、ゲートでサバンナから雨季に(白水)
  • ゲートは国境のイメージ(伊佐)
    • 日本人としては土の上に境目があるのはぐっとくる(たつき)
  • 一話最後鳥とかが飛んでいく(福原)
    • 精一杯の言い訳を……鳥もいることをできるだけ早くに示そうとした(たつき)
  • アフリカの夕焼けのイメージ
  • 色の設定、色の感覚は監督が一番強いので何度もダメ出しをされた(白水)
  • (作ってるので)見るのあんまり慣れてない、ラッシュチェックでおなか痛い(たつき)
  • (クリエイターは永遠に作り続けるので)完成しないよね、締め切りってものがなかったら納品されないな(福原)
再会
  • ここでミライさんが(福原)
  • 10話かの犯人もここでいれていくっていう(たつき)
  • かばんちゃん、初めは名前が決まってなくて、主人公って呼んでいた。後半になってもかばんちゃんでなく主人公と呼ばれていた(白水)
  • 委員会で「かばんちゃん」って言う名前だと伝えたとき、みんな「はて？」って感じだった(福原)
OP
  • あまり記憶に残ってない、一ヶ月ぎりぎりでここで作らなきゃってときは、まじか(伊佐)
  • 1話狩りごっこ、OP、最後11,12話の勝負、どれか詰めたらどれか減る(たつき)
  • 一話けっこう頭から、その時点では12話まで作業工程は見えてた(たつき)
  • 全体にフラットに(たつき)
  • アニメーター、美術の時間感覚で全体見てると気が狂いますよね(たつき)
  • カットが1話300超えないように(たつき)
  • アニメ背景美術、一日に20～30枚かかないと(白水)
  • 勝負カットは1日1枚とか(白水)
  • カメラワークで大きく振るやつはほとんど映らないので書き込まない(白水)
  • (ボスとサーバル何かを持ってかばんに近づくシーンで)これは一体なんだったんでしょうか(たつき)
  • 昆布ってかかれてる(福原)
  • 一応答えはある(たつき)
  • 後半OP変えた時もぎりぎりまでまってもらった(福原)
  • 主人公の方しか喋らない。ラッキービーストの向きを修正させられた。あまりやるとサーバルいじめに加勢してるようで(伊佐)
2話 ジャングル
  • 1,2話で水場から見下ろすサバンナ全景、背景が主役(白水)
  • 広さ、どこまでがパークなのかつかめなかった。最初「こんなに大きく描いていいのかな」と戸惑いながら(白水)
  • 最初知らされてなかった(伊佐)
  • (監督は)ダミーを仕掛けてくる。最初、西ノ島を調べさせられた(伊佐)
  • サーバル・かばん二人との情報量を現場で合わせたい(たつき)
    • 「罠にはめてやろう」
    • なるべく美味しく食べてやろう
  • ジャングルの植物…身近な植物ではだめ、日本の森になる(白水)
    • シダなど
  • 2話でフォトショのブラシを10種類ほど作った(白水)
  • 普通のアニメのバンク、使いまわしがあまりない(福原)
  • 動物だし動かして相談しながらやってた
  • 調べることも多かった(福原)
  • エンターテイメントなので、最終的に(たつき)
  • 「塩をなめるか調べろ」(と監督に言われ)海外サイトで見つけた(アクシスジカ) (伊佐)
  • 動画は必ず一回見る(たつき)
  • ジャングル…11話で後ろにバスが走る
  • ジャングルの美術ちょーヤじゃない?(福原)
  • ちょーヤ……苦しみました(白水)
  • でも一話でブラシもさよなら(福原)
  • シダの葉っぱは再利用できないので、ここだけでしか使えない(白水)
  • ジャパリまん初登場(たつき)
  • 撮影の旭プロダクションの方で木漏れ日を綺麗に入れてもらって質が上がった
  • 最後はみんな愛で動いてた(福原)
  • 美術は全然バンク作ってないよね(福原)
  • バンクが全然できない(白水)
  • ボス、だんだんここら辺からギャグキャラに
川のシーン
  • 川、岸、増水とかで道が途絶えた設定(伊佐)
  • カワウソ、はじめおらんかった(たつき)
    • レア1、アプリ版で人気なかった(福原)
  • ここ一回全部すてた（はじめサル系だった) (たつき)
  • 石で遊ぶ
    • 石を見てない(伊佐)
    • このシーンの間の感じ、たつきくんの笑いの間はあんな感じ(福原)
  • ジャガーめっちゃいい人(たつき)
  • その場であるもので船をつくる、歩道で(伊佐)
  • 船の設定とかなんやかんやしてた(たつき)
  • ウォーキングコースとは変わるけどジャングルだし(白水)
  • どのような形にするか?作った感がでると文明レベルが上がってよくない(伊佐)
  • かばんちゃんが物を加工しはじめるのでそっちに割り当てたい(たつき)
  • 橋の浸水例などを調べて設定をつくった(伊佐)
    • 自然の摂理
  • コツメカワウソはゲームでは☆1で、ハズレ感(福原)
  • お手玉、あれをみて衝撃を受けて入れた(たつき)
  • 水場、普通の川と違ってねっとりしている。波にはこだわった(伊佐)
    • 撮影さんとの合わせ技
    • 美術で反射まで描いたり
    • 5話湖面のキラキラのエフェクト
Bパート
  • バス、最後にまで出る。リテイク。パークにある感じ、アトラクション感。プラモデルとか(伊佐)
    • 構想段階から(テイクが)4,50近い
  • 川の、主塔という吊橋のパーツ、設定を考えたのは監督のアイデア(白水)
  • (橋のパーツが)何でわかるんですか?(伊佐)
  • お客さんがネットで見つけてきたり(白水)
  • 6割くらいはもともとの知識、3～4割はけもの合わせで調べた(たつき)
  • 普段から天井ダクトがむき出しになった写真を撮っていた
  • 廃墟とか好き、軍艦島(たつき)
  • サーバルがバスをもって跳ぶシーン。マックスの馬鹿として早めに提示しておこう、3話崖から落ちても行ける、限度(たつき)
    • ものさし(福原)
  • 知能的にはカワウソが低い(福原)
  • 後半、文明レベルが上がるので、前半が野生っぽい(たつき)
  • バスはなかなかOKが出なかった(伊佐)
    • 前後に分けようとしたのは途中から(白水)
  • シリーズ構成のメモ出てきてちょっと怖かった、気触れてる感じが(たつき)
  • コツメカワウソははじめサル系だった
  • サルが木からブランブランして登場するアニメーションを作ってたが消えた(伊佐)
  • 動物ものは類人猿出ないなあ(制作時にズートピア公開) (福原)
  • 見たいもの作って評価されたのが(たつき)
  • たつき監督の知識の広がり
  • 浅くひっかけとく感じ(たつき)
  • アクシスジカが土なめるとこ
    • 海外の動画サイトで塩舐めてるのを見つけた(伊佐)
    • エンタメなので、本当か嘘かでは、嘘でも面白ければいいけど、できるだけ調べたい(たつき)
ED
  • 廃墟。明暗の暗部分。アニメのふり幅の下部分(たつき)
  • 実は立体的に動かしている。写真に見える美術(白水)
  • 美術をやらないといけない、モデルを作ってBOOK貼り付け(たつき)
  • 立体的な動かし方(の度合い)を段々上げていく(たつき)
  • 観覧車がラストカット最終回に繋がる(福原)
  • 一枚写真ではなく、書き足したり、モデルを別に作ったりした(たつき)
次回予告
  • 音を聞いて初めて内容を知る(たつき)
3話
  • (ラッキービーストの)「まかせて」、一周してから見ると面白い
  • ロープウェー、監督が「登り切ったところで最後下がるはずだ」と(伊佐)
  • たつき監督が「きっとこうだ」と言って、調べるとそう、というパターン(福原)
  • 平野から縦に(福原)
  • (3話)前半と後半で少しだけジャングルが再利用できる(白水)
  • ゴンドラは色々調べた(伊佐)
    • 実際に行ってみた
トキ
  • トキ、(金田さんが)すごいたくさん歌ってくれた(たつき)
    • 隙間を作っておいた(たつき)
    • 録り直し4つ5つ(セルフリテイク) (たつき)
  • 2話からOPにキャラクタがどんどん増えていく
  • トキの羽は監督がつけた(白水)
  • アニメーターとして触ってるところもまばらにある(たつき)
  • 3人ともまたがる領域の部分が多い(福原)
  • 飛ばす上下動が間違うと危ない動きになる(たつき)
  • 3DCGは歴史の蓄積がないので(手探り) (たつき)
  • フルCGのセルルックで1クール30分をやったのはポリゴンピクチュアズ、サンジゲン、ヤオヨロズくらいでは(福原)
  • 崖、何個かカットなくなった(たつき)
  • プレスコとアフレコ(のやり方を)この辺りまで(擦り合わせていた) (たつき)
  • プレ:アコが6:4、4:6とか、アフレコ寄りのプレスコ(たつき)
  • アルパカが出てきた後がつらい、できるだけ空に居てほしかった。空は素材兼用してカロリーを(削減した) (白水)
  • 熱心にやってもらって2テイク目くらいでいい感じだったが、3回4回やっていただいた(たつき)
  • 前半のキャラ変なやつ多い(福原)
    • ちょっと強め置いてるとこがありますね(たつき)
  • この辺りから元が動物であることを匂わせていく。細谷Pが「崖登るもんだな」と(福原)
  • ここまでは(ジャパリまんは)ピンク色(福原)
    • 前ブルーハワイ味とか……(福原)
    • 青色6号でしょ(たつき)
  • 日付の関係でトキ→かばんではなく、録るのが逆の順になってしまった(たつき)
  • ロープウェイ、途中で支柱の上に乗るシーンがあると聞いていた(伊佐)
  • 監督が(ロープウェイの到着地点が)一度上がって下がると言い張った(伊佐)
ジャパリカフェ
  • 元ネタはシャッツキステ
  • この店で脚本を書いてた(2, 3話) (たつき)
  • 池袋、ホワイトボードのペン立ての裏に書いて帰ってきた(たつき)
  • マルイ、なくなった時用にポストカードを持って行った、持って行った時には何にもなかった(たつき)
  • マチュピチュっぽい感じ
  • 3話、設定美術の仕事多かった(たつき)
  • 筋書き読んで実際に行ってみたいとわくわくしていた(伊佐)
  • 紅茶の淹れ方を監督がシャッツキステのメイドさんに聞いていた(伊佐)
    • 最初コーヒーだった、コーヒーの木について調べた(伊佐)
  • アニメオリジナルなので、表面に映った物の後ろで捨ててるものも多い(福原)
  • ゴンドラも設定の方でどうやって動かすかという、これも監督が足漕ぎであるはずだと(伊佐)
  • 遊園地感を出していく(たつき)
  • トキの目のハイライト、絵を描く人は気づいていた(福原)
  • 吉崎先生が後ろで仕込んどるんで見のがしがないか恐い(たつき)
  • たまたまシャッツキステで脚本書いてて、その後コラボが決まって、「見張られてる…」(たつき)
  • コーヒーから紅茶に変えた。コーヒーは喉にはあんまよくない(たつき)
  • シャッツキステで紅茶の淹れ方を取材してた(伊佐)
  • 卓上メニューはたしかシャッツキステそのまま(白水)
  • 自然物がサブの時はいいけどメインとなると難しそう
  • 自然物の方がごまかしがきく、ブラシでざっくり。ただ、いつまでたっても決まらないので、人工物の方が決めやすい(白水)
  • テーブルは3Dモデル? (福原)
  • ベースは3Dモデル、2D美術でかなり書き足している(白水)
    • (3Dモデルを)レイアウトとして
  • (トキの歌)さっきよりちょっと上手くなってる、でも下手に(たつき)
バス～ED～アラフェネ
  • バス、手で描くと死人が出る(たつき)
  • 「ゔっ」お客さん笑ってる
  • 酷いアニメです、これ狂ってますね(たつき)
  • あんたのアニメだよ(福原)
  • 吉崎さん、すごく感想を送ってくる(たつき)
  • アラフェネ、2話はなかった(福原)
    • 2人に対する贖罪(たつき)
    • おさらいができる感じ(白水)
    • 前のキャラクターが一度きりでなく、もう一度見れるのでうれしい(伊佐)
  • 最終話までなくならない電池。科学力(たつき)
  • 普通に考えて先頭に電池あったら危ない(福原)
  • 3話で頑丈さのマックスを示しとこうかなって(言い訳しとこうかなと) (たつき)
  • 監督の提示してくるワードからさぐりさぐりで作ってみる。「ここは一体どこなんだ?」(白水)
  • 声優さんにほどよく知ってもらう(たつき)
  • 出てきたとき、発見があったことを(演技に)乗せてもらえる(たつき)
  • Bパート、細かいところで動きのダメ出しが何回も(伊佐)
  • 監督と相談できるので、見栄えを考えた上で物を置ける(伊佐)
  • ただ今回ちょっとしんどすぎた(たつき)
  • 芯が決まってからは人が増えても大丈夫(たつき)
  • その前は人が増えても(だめ) (たつき)
  • 普通テレビシリーズ12話全部を(一人で)演出することはない(福原)
  • 気ぃ狂いますのでやらん方がいいですよ(たつき)
4話、砂漠
  • ここら辺で気づいた、「まかせて」を被せていけるんじゃないかと(たつき)
  • CGでガイドを作ってそれをなぞる(感じで作っている)? (福原)
    • まちまち
  • CGだと結局手を入れてなじませないといけない(伊佐)
  • パースから出してもらって一から描く、草原とかは描いた方が早い(白水)
  • 監督の方で素体つくってそれを元にモデルを作る(伊佐)
  • 作ったモデルをレンダリングすると1時間とか(伊佐)
    • 監督のだと早い、自分たちが作ると1時間くらいはかかる(伊佐)
  • (レンダリングの速さについて)考えてます、そこで短縮しないと3話位落ちしてまう(たつき)
  • (レンダリング中に食事する)レンダ飯、レンダリング時間短いとできない(福原)
  • マシン2台用意してレンダリング中に作業(たつき)
  • 8人くらいでやるのは? (福原)
    • 恐怖、50～100人用意してどうにか(たつき)
  • 「木陰のまま走れる感じ」サーバルちゃんが自分の知識で話してる感じがある(伊佐)
  • セリフはかなり考える(たつき)
    • 文字見た時のやつ「かばんちゃん何に言い出すの?」ねちっこく考えて(たつき)
  • 完全に知らないってことの説明がないが、察するに十分のやり取りがある(福原)
  • 「かばんちゃんは人間だから文字が読めるんだね!」という説明だと、工数の省略ができるが、不粋、下品(福原)
  • キャラに入り込むと雰囲気が出る、自然にするために工数が3倍とかになったり(たつき)
  • (動物紹介コーナーの)スナネコの落描き、岩と砂だけだとあまりにも寂しい(白水)
    • 勝手に描いた? (福原)
    • こっちで描いてそのまま通った(白水)
  • 後半は(スタッフ間で)ピント合ってくるのでそのままスルーって感じ(たつき)
  • マッドマックスっぽいよね(福原)
  • スナネコ、地がキャラらしくて、演技すると外れる(たつき)
  • サーバルの尾崎さんも
  • (指示について)共通言語が多いので猫らしさ、キャラらしさ、愛らしさがコンパクトに伝わる
  • Vコン先行で伝わりやすくしてるものの(福原)
  • ピント合わない人だと(難しい) (たつき)
  • サーバルらしい台詞、らしさ
  • キャラとか整合性あっていい(福原)
  • 台詞とからしさからずれないようにとか(たつき)
  • ジャパリまんの袋はファミチキの袋が(モデル) (伊佐)
    • 会社近くにファミマあるからね(福原)
  • 廃墟っぽくて好き(たつき)
  • バイパスって響きが怖い(伊佐)
地下迷宮
  • ツチノコ、このエリアにいて良い動物だから
  • ゲームにも出てきた(たつき)
  • 実在するかわからない奴が人間、こっちの歴史を語ってる(伊佐)
  • 3話～5話くらいまでに世界観を示す(たつき)
  • 人間が「あいつ絶滅してたっけ?」って感じのことを言う感じで人間に向かって言わせたかった
  • 迷路…ポートピア連続殺人事件
  • 最初ここ描いてて何で溶岩があるかわからなかった(白水)
    • ここに溶岩描いてって言われるだけ? (福原)
    • そう(白水)
    • たつき流監督術(福原)
  • 楽しみを残したまま作るのは面白い、騙されてくれたり(たつき)
  • 楽しんで作ってたり、ライブ感
  • 行き当たりばったりででなく詰め込めるものを詰め込んだ感じ(たつき)
  • (アニメでジャパリコインって呼ばれてるものが)ジャパリコインじゃないって(福原)
    • らしさをとった、2種*1あると混乱する(たつき)
  • ハンドルを1回もラッキービーストは触ってない(たつき)
    • ちょいちょいニャンってやるよね(福原)
  • この辺とかジャガーの下りとか順繰りには作りづらい(たつき)
  • ばらばらに走るところなどVコンでないと伝わりづらい(たつき)
  • 蛇の尻尾なので、しなりとか動きは頑張ってる(伊佐)
  • 急にテンションが上がる感じ、声をつけたときにギャップがあり修正が(大変) (伊佐)
  • なぜ溶岩があるか知らされてなかった(白水)
  • 3話4話くらいでパークの裏側を気にする、(ツチノコは)視聴者と同じ立場(たつき)
  • 遊園地とかの巨大迷路をモデルとした(たつき)
  • このときはパーク全体の地図はできてなかった? (福原)
  • この後何が出てくるって情報はあったが、地図としてはなかった(白水)
洞窟の外
  • 実際にパークがあってそれをアニメにしてる感じがある
  • ツチノコ、オタクっぽくていい。短いにしては支離滅裂、三つくらいの役職(たつき)
  • 上手い声優は根元を押さえた上で外される(外した演技をする) (たつき)
  • 撮影結構粘らせてもらえる、ラスト1日でいろいろいじったり(たつき)
  • 洞窟の外結構粒子見れるんですね(福原)
    • 埃のきらめきなどを足す(たつき)
  • これ録ってる時、声優さんもわかってない感じ(たつき)
    • 委員会でも(福原)
  • 昔何かあったんだなーって感じをこの時間軸で(伝える)の、綱渡り的な感じがあった(たつき)
  • アラフェネ、ことごとくアクシデントにあうのが可愛らしい(伊佐)
  • つちのこ館、すごい喜んでた。お客さんが増えた(福原)
  • 外で明るいからミライさんが見えてないってことだよね(福原)
    • 明るいところで映すようにはしてましたね(たつき)
  • ツチノコが人類のことを話してるのが面白くてですね(伊佐)
    • 存在していない動物が人類のことを話してる(福原)
  • よく声優さんの声がぴったりはまったね(福原)
    • 微妙にプレスコ部分もあって、あまりにひどいところはアニメーションの方を作り直しに近いところでしたこともあった(たつき)

*1:アニメ版でジャパリコインと呼ばれるものはNEXONアプリ版のジャパリゴールドのデザインで、ジャパリコインは別のデザインとなっているらしい。参考: https://dic.nicovideo.jp/a/%E3%82%B8%E3%83%A3%E3%83%91%E3%83%AA%E3%82%B3%E3%82%A4%E3%83%B3#h2-2

AutoHotkeyで入力キーボートレイアウトの切替を行う

AutoHotKey 入力

Windowsでは複数の入力言語やキーボードレイアウト(IMEを含む)を設定できる。日本語IMEは日本語入力のオンオフを切り替えられるのでそれだけを利用している場合には触れることは少ないかもしれないが、Google日本語入力やATOKのような別のIMEを併用したり、中国語、タイ語など他の言語のIMEやキーボードを使う場合、切替が必要となる。

この切替は「Alt+Shift」(入力言語の切替)、「Ctrl+Shift」(同言語でのキーボードレイアウトの切替)、あるいはWindows 8以降では「Windowsロゴキー+Space」(入力言語・キーボードレイアウトの切替)のショートカットキーで行うことができる。また、設定で特定のキーボードレイアウトへ切り替えるショートカットを指定することができるが、設定できるキーの組合せに制限があったり、うまく設定が反映されなかったりすることがあるので、AutoHotkeyでキーボードレイアウトの切替を定義できれば便利だろう。


AutoHotkeyはSendMessage命令を利用してWindows APIのウィンドウメッセージを投げることができる。これで望む入力言語・キーボードに対応するinput locale identifier (入力ロケール識別子)を指定してWM_INPUTLANGCHANGEREQUESTを投げると、入力言語・キーボードを切り替えることができる。
したがって、このinput locale identifierを適切に取得すれば、指定したキーボードレイアウトを切り替えるホットキーが定義できる。これを取得するために、Windows APIのLoadKeyboardLayout関数やGetKeyboardLayout関数を利用することができる。

検証環境

Windows デスクトップ アプリケーションのいくつかで動作を確認したが、動かないアプリケーションもあるかもしれない。

方法1: LoadKeyboardLayout関数を使う場合

LoadKeyboardLayout関数のsyntaxは次のようになっている。

HKL WINAPI LoadKeyboardLayout(
  _In_ LPCTSTR pwszKLID,
  _In_ UINT    Flags
);

LoadKeyboardLayoutの引数のpwszKLIDは「input locale identifierの名前」であり、16進数の数字8文字のからなる文字列で、レジストリの

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Keyboard Layouts

の下にある項目のものである。ここから、利用したいキーボードを表す8桁の16進数字をメモしておく。

なお、既定のキーボードについては次のページからも参照できる。


目的のキーボードを探すのに役立つ情報として、pwszKLIDの下4ケタはlanguage identifierである。language identifierは次のページから参照できる。

また、上4桁については、その言語のデフォルトキーボードは0000となるようである。ある言語のキーボードレイアウトにいくつか種類がある場合、0001, 0002, と上4桁の番号が順番に増えたりするらしい。一方でMSKLCなどでキーボードレイアウトを自作した場合などは上4桁がa000などとなる場合もある。

実装例

ここでは、例として「日本語・Microsoft IME」と「ロシア語 (タイプライター)」に切り替えるホットキーを設定してみる。
まず、pwszKLIDとして与えるべきものは

キーボード pwszKLID
日本語・Microsoft IME 00000411
ロシア語 (タイプライター) 00010419

である。

これらを引数に指定してLoadKeyboardLayout関数を呼び出してinput locale identifierを取得し、取得したinput locale identifierを指定してPostMessageでWM_INPUTLANGCHANGEREQUEST (0x50)メッセージをアクティブウィンドウに投げれば切り替えができる。

F11で日本語・Microsoft IME、F12でロシア語 (タイプライター)に切り替えるAutoHotkeyスクリプトは次のように書ける。

F11::
  ;日本語・MS-IMEへの切替
  ja := DllCall("LoadKeyboardLayout", "Str", "00000411", "Int", 1)
  PostMessage 0x50, 0, ja,, A  ;WM_INPUTLANGCHANGEREQUEST
Return

F12::
  ;ロシア語 (タイプライター)への切替
  ru := DllCall("LoadKeyboardLayout", "Str", "00010419", "Int", 1)
  PostMessage 0x50, 0, ru,, A  ;WM_INPUTLANGCHANGEREQUEST
Return

方法2: GetKeyboardLayout関数を使う場合

いちいちレジストリエディタ開いてinput locale identifierの名前を調べるのは面倒である。どうせ切り替えるキーボードは普段使っているものなので、現在使用しているキーボードから直接input locale identifierを取得してしまえばよい。


GetKeyboardLayout関数は現在選択されているinput locale identifierを返す。
しかし、LoadKeyboardLayoutの場合と異なり、32ビットのinput locale identifierのMSB (最上位ビット)が1の場合でも正整数が返ってくる。要するに32ビット符号なし整数扱いになっているようだ。
一方でPostMessegeでWM_INPUTLANGCHANGEREQUESTを投げる時に指定するinput locale identifierは符号あり整数にする必要があるようで、GetKeyboardLayout関数が返した数値をそのまま用いると、32ビットアプリでは動くが、64ビットアプリでは動作しないようである。
そのため、自分で変換する必要がある。


まず、次のようなスクリプトを使って、使っている入力言語・キーボードレイアウトのinput locale identifierを取得する。
結果はキー入力として出力されるので、テキストエディタなどを開いて調べたいキーボードレイアウトに切り替えた状態でF10を押す。

F10::
  SetFormat, Integer, H
  WinGet, WinID,, A
  ThreadID:=DllCall("GetWindowThreadProcessId", "UInt", WinID, "UInt", 0)
  InputLocaleID:=DllCall("GetKeyboardLayout", "UInt", ThreadID, "UInt")
  Send, %InputLocaleID%
Return


すると、次のようなinput locale identifierが取得できる。

キーボード input locale id
日本語・Microsoft IME 0x4110411
ロシア語 (タイプライター) 0xF0080419

日本語・Microsoft IMEの場合は32ビットのMSBが0であるため問題ないが、ロシア語 (タイプライター)の場合はMSBが1なため負数で表す必要がある。

次のWebサービスのようなものを用いて、32ビット16進数表記を符号あり10進整数に変換する。

すると、0xF0080419は-267910119であることがわかる。これをWM_INPUTLANGCHANGEREQUESTメッセージのlParamに指定する。


F11で日本語・Microsoft IME、F12でロシア語 (タイプライター)に切り替えるAutoHotkeyスクリプトは次の様になる。

F11::
  ;日本語・MS-IMEへの切替
  PostMessage 0x50, 0, 0x4110411,, A  ;WM_INPUTLANGCHANGEREQUEST
Return

F12::
  ;ロシア語 (タイプライター)への切替
  PostMessage 0x50, 0, -267910119,, A  ;WM_INPUTLANGCHANGEREQUEST
Return

参考

文字のデザインに筆記具が与える影響

文字

Type& 2015「ロゴの多言語化：デバナガリとアラビア文字」

2015年11月21日にType& 2015の「[3]ロゴの多言語化：デバナガリとアラビア文字」を聴講した。これは、まずデーヴァナーガリー及びアラビア文字の特徴についてそれぞれタイプデザイナーであるVaibhav Singh氏およびNadine Chahine氏から簡単に紹介がなされ、さらにラテン文字のロゴと各スクリプト*1版作成の実例が紹介された。その後、実在の日本の会社のロゴタイプを題材に、実際に両氏が各スクリプト版を試作したというものであった。


この後半のローカライズロゴ試作においてお題に使われたうちの一つがWonders! by Panasonicのロゴであった。
ここで注目したいのが感嘆符「！」で、上の縦棒部分の下端がカーブして切り取られ、左側にとがっている。一方で、試作されたデーヴァナーガリー及びアラビア文字版ロゴではそれが左右逆になっていた。図解すると次のようである*2。
f:id:nixeneko:20151124001702p:plain
アラビア文字はラテン文字とは逆に右から左へと書き、疑問符などの記号も左右反転させて使う(“؟”)ので、デザインが左右反転しているのも納得できるが、一方でラテン文字同様左から右へ書くデーヴァナーガリーでもデザインが反転しているというのは不思議である。
このことは公演中にデーヴァナーガリー版ロゴについて小林章氏がVaibhav Singh氏に質問していたことなのだが、Vaibhav Singh氏はその理由について「その方が自然だから」と返答していた。

筆記具が影響した?

ここからは私の仮説であるが、伝統的に文字を書くのに使われていた筆記具が影響しているのではないかと思う。各スクリプトが伝統的にどのような筆記具で書かれていたかをみていくことで確認してみたい。

ラテン文字

ラテン文字は長らく羽ペンで筆記されてきた伝統をもつ。次の動画で羽ペンの作り方や筆記のやり方が解説されている。現在のラテン文字セリフ書体のデザインは羽ペンで書かれた文字の形を元にしているという。
www.youtube.com
羽ペンは平らなニブ(ペン先)をもち、縦方向に動かすと太く、横方向に動かすと細く線がかける。
現在の欧文カリグラフィーで使われるペンにも同様に平たいニブをもつものがあるが、ニブ(ペン先)を上に向けて外側からみたときに、傾きがなく横まっすぐになっているか、あるいはゆるやかに右肩上がりになっている*3かのどちらかのようである。
ペンを当てるときはペン先が水平から反時計回りに角度がついた状態で書かれることが多いようだ。これは、oなどの円形の文字の左上と右下が細くなり、反対に左下と右上が太くなることに影響している。
f:id:nixeneko:20180113164152p:plain
(フォントはTimes New Roman)

アラビア文字

イスラム世界ではアラビア文字による書道が発達している。アラビア書道用のペンは葦ペン等の平らなニブをもつ筆記具が用いられる。ペン先は斜めにカットされていて、ニブを上に向けて外側からみたときに右肩上がりになる場合が多いようだ。アラビア文字を書く場合はペン先の角度が直角に近く、ペンを横に向けてに持つ感じになる。次の動画でペンの持ち方が解説されている。
www.youtube.com

アラビア文字フォントでも、ペン先を傾ける方向はラテン文字と同様反時計回りでありながら、角度はかなり急峻になっているのがみてとれる。
f:id:nixeneko:20180113171052p:plain
(フォントはTimes New Roman)

デーヴァナーガリー

デーヴァナーガリーは伝統的に葦ペンでかかれる。

次の動画では、デーヴァナーガリー用のカリグラフィペンは、ペン先が欧文カリグラフィー用とは逆の傾きをもち、右肩下がりになっているという説明がある。
www.youtube.com
実際に文字を書いているところや書かれた文字をみると、ペン先の当て方がラテン文字やアラビア文字とは傾きが逆で右肩下がりになっている。
www.youtube.com
次の動画では基本的なストロークを紹介しているが、ここで書かれている円は右上と左下が細く、左上と右下が太くなっている。
www.youtube.com

全体として、ニブの当て方が逆であることから、ラテン文字やアラビア文字とは線の方向と太さの関係が逆になっていることがみてとれる。線の端についても、左上から右下に傾いていることがわかり、これもラテン文字と逆である。
f:id:nixeneko:20180113172941p:plain
(フォントはAdobe Devanagari)

まとめ

カリグラフィ用のペンのニブの形状(傾き)の違いと、ニブをどの向きで紙に当てるかについてを次図にまとめた。
f:id:nixeneko:20180113173314p:plain

ここで、なぜアラビア文字とデーヴァナーガリーで試作ロゴの感嘆符「！」の向きが一致したのかを検討してみたい。

アラビア文字で感嘆符が反転したのは書字方向が反対になるのに合わせたということだろう。

一方で、デーヴァナーガリーは、伝統的にラテン文字とは逆方向の右肩下がりにペン先を当てるため、線の端は右肩下がりになるのが自然であり、線の端が右肩上がりになる要素は不自然であると考えられる。そのためラテン文字と書字方向は同じだが、「！」の縦線が右肩下がりになる形を採用し、デーヴァナーガリーのエレメントに合わせたのではないか。


結果としてアラビア文字とデーヴァナーガリーで「！」の形が一緒になったものの、どうして元のラテン文字のロゴから左右反転したような形を採用したのか、その理由は2つのスクリプトで異なっているようにも感じられる。
文字のデザインはそのスクリプトが書かれていた筆記具に影響されるというのは正しそうではあるが、必ずしもそれだけでデザインが決定される訳ではなく、他の要因との複合で最終的な形が作られるのだろう。

*1:この「スクリプト」は、ラテン文字、アラビア文字、デーヴァナーガリーなどの文字体系のことを指す。用字系、書字系などとも。script.

*2:蛇足ではあるが、“Wonders!”の“s”に当たる部分を、デーヴァナーガリーではs, アラビア文字ではzに相当する文字で転写しているのも面白い。

*3:ペン先に角度がついているものをobliqueという。Difference between an italic, an oblique, and a stub? | Classic Fountain Pensによると、usually about 15 degreesとのこと。

キーボードの言語によってDvorakJの有効無効を切り替える

入力 AutoHotKey

随分前に、DvorakJを利用して英字入力はDvorakにし、日本語入力はJapanist 2003を利用して親指シフト(NICOLA)をエミュレーション利用していた。一方で、ロシア語やタイ語等を入力する要求がでてきて、DvorakJはこの様な日本語以外のキーボード言語の入力時に無効にする設定ができず、まともに入力ができないため、Dvorak配列を使用するの自体をやめてしまっていた。

やりたいこと

キーボードの配列を次のようにしたい。

  • 日本語入力時(キーボード言語が日本語かつIMEオン): 親指シフト(NICOLA)
  • 英字入力時(キーボード言語が日本語かつIMEオフ): Dvorak
  • 他言語入力時(キーボード言語が日本語以外): Qwerty相当 (キーボードの入力そのまま)


これは、2回の場合分けによって表現できる。

  1. キーボード言語による場合分け(日本語か?)
    • 日本語でない→キー変換を行わない
    • 日本語である→2へ
  2. IMEのオンオフによる場合分け
    • オン→日本語入力用配列
    • オフ→直接入力用配列


ここで、現行のDvorakJ (2014-06-07版)ではIMEのオンオフの検出で日本語入力時と直接入力時で別々の配列を適用することができる(つまり、2.は実装されている)が、一方で日本語以外の言語に切り替えたときも直接入力用の配列が適用されてしまって、日本語以外の言語を入力することができない。
なので、うまいことキーボードの言語が日本語であるかどうかで場合分けを行い、日本語である場合にだけキーリマップを適用する様にしたい。

方針

DvorakJはAutoHotkey_L用のスクリプトが公開されているので、それを改変し、条件分岐部分を追加すればいいのではないかと思う。

AutoHotkeyで現在のキーボード言語を取得するには次のページのようにするといいらしい。

ここに挙げられたコードを引用する。ただし、このコードはコンソールでは使えないとのことである。

F11::
  SetFormat, Integer, H
  WinGet, WinID,, A
  ThreadID:=DllCall("GetWindowThreadProcessId", "UInt", WinID, "UInt", 0)
  InputLocaleID:=DllCall("GetKeyboardLayout", "UInt", ThreadID, "UInt")
  MsgBox, %InputLocaleID%
Return

要するにInputLocaleIDが現在のキーボードを識別するIDのようである。

WinAPIのGetKeyboardLayoutの項によると、

The return value is the input locale identifier for the thread. The low word contains a Language Identifier for the input language and the high word contains a device handle to the physical layout of the keyboard.

GetKeyboardLayout function (Windows)

だそうで、下位2バイトは入力言語のlanguage code、上位2バイトはキーボードレイアウトへのデバイスハンドルらしい。

最新のWindows 10 (バージョン1709)において、実際に取得したInputLocaleIDは次のようになっている。

言語 キーボード InputLocaleID
日本語 Microsoft IME 0x4110411
タイ語 タイ語 Kedmanee 0x41E041E
ロシア語 ロシア語 0x4190419
ロシア語 ロシア語 - ニーモニック 0xF0330419
ロシア語 ロシア語 (タイプライター) 0xF0080419
モンゴル語 伝統的なモンゴル文字 0xF0B20850

その言語の標準的なキーボード配列においては上4桁(2バイト)は下4桁と同じになっているように見える。
キーボードによって条件を変化させるのであれば全体を比較すればよいし、言語によって変化させるのであれば下2バイトだけ比較すればよいことになる。

Language Codeについては、AutoHotkeyのドキュメントにも次の様な記術があるが、

WindowsのLanguage Codeの一覧は次のページから参照することができる。


DvorakJのソースをみてみたところ、DvorakJ全体を一時停止するキーショートカットが設定できるので、これに使われてるロジックを利用して、キーボードが日本語以外に切り替わった場合に一時停止するようにし、反対に日本語に切り替わった場合には一時停止を解除するようにしてみる。

環境

改変

DvorakJのAutoHotkey_Lスクリプト版の src/init/set_various_timers.ahk を開き、27行目付近の

	;;; IME の状態を定期的に調べる
	SetTimer, IME_GET, %IMEms%

の下に

	SetTimer, Keyboard_GET, %IMEms%

を挿入し、更に末尾に

;; キーボードの言語を一定間隔毎に取得し、日本語以外だったら動作を停止する。
;; 日本語だったら動作を再開する。
Keyboard_GET:
  SetFormat, Integer, H
  WinGet, WinID,, A
  ThreadID:=DllCall("GetWindowThreadProcessId", "UInt", WinID, "UInt", 0)
  InputLocaleID:=DllCall("GetKeyboardLayout", "UInt", ThreadID, "UInt")
  If ( InputLocaleID & 0xFFFF = 0x411 ){ ;Japanese
    If ( A_IsSuspended ){
      toggle_status_of_dvorakj(False)
    }
  } Else { ;otherwise
    If ( !(A_IsSuspended) ){
      toggle_status_of_dvorakj(True)
    }
  }
return

を追加した。

要するに、一定時間ごと（今回はIMEの状態を定期的に調べる間隔(IMEms)を流用した）に現在のキーボードの入力言語を取得し、

  1. 入力言語が日本語であり、かつ、DvorakJが無効である(Suspendされている)場合は、Suspendを解除する
  2. 入力言語が日本語でない、かつ、DvorakJが有効である(Suspendされてない)場合は、Suspendする

という処理をもともとのソースコードに追加している。

感想・課題

しばらく使ってみたが、親指シフト回りがあまり快適でなかったのでやめてしまった。DvorakJ自体を利用するのが久しぶりであるのに加え、親指シフトのエミュレーション用として利用したことがなかったため、問題の切り分けができていない。そのためはっきりしたことが言えないので今後も検証が必要である。

  • 親指シフトのエミュレーションの同時押しの検出がやまぶきRより精度が低い感じがする。そのため、入力ミスが多発した。
    • 急いで入力すると「にゅうりょく」が「にけをりょく」や「にゅうりいる」になったり。やまぶきRでも時々なるけれど…。
    • やまぶきRと同様の設定にしてるつもりであるが、設定によって改善が可能かもしれない。要検証。
  • ウィンドウを切り替えたときや別の入力フィールドに移ったときなどにうまく入力ができなくなる場合があった。
    • 改変部分が原因かもしれないが、素のDvorakJを最近使ってなかったので比較ができない。
    • やまぶきRでもなったことがあるように思うので一概に何ともわからない。別のウィンドウ切り替えた後で戻すと復活したりする。
  • DvorakJに用意されていた一時停止機能を勝手に利用しているため、一時停止してもキーボードが日本語であればすぐ再開されてしまい、一時停止機能が使えない状態になっている。
  • 本当にこんな改変で大丈夫なのか……?


頂いた情報によると、DvorakJとやまぶきRではいろいろと同時押しエミュレーションのロジックが異なるので入力感は同じにならないとのこと。


なかなか難しい。

Adobe Illustrator CS6日本語版でタイ文字やアラビア文字を組む

文字 Illustrator

Adobe CS6ソフトウェアを学生版の買い切りで購入して以来愛用しているが、InDesignはともかくIllustratorはタイ文字やアラビア文字といった複雑なテキスト配置を要する用字系(complex script)をまともに表示できなかったりと不満があった。しかし、Illustratorでも裏技的な方法でタイ文字やアラビア文字などを正しく表示することができるらしい。

Adobe InDesign CS6日本語版の多言語対応

Adobe InDesign CS6日本語版では「段落」パネルのメニューから「Adobe 多言語対応コンポーザー」が選択でき、それによってタイ文字やアラビア文字を一応まともに組むことができる。
f:id:nixeneko:20171213120147p:plain
文字を入力してみると次のようになる。
f:id:nixeneko:20171213160221p:plain
フォントはアラビア文字がTimes New Roman、タイ文字はAngsana New、ヒンディー語はAdobe Devanagariを指定した。

ただし、「段落」パネルは書字方向の設定(RTL)に対応していない様で、RTL言語を組むための機能が揃っているとはいえないようだ。RLM (U+200F RIGHT-TO-LEFT MARK)を挿入することによって一応右横書きとして妥当な表示にはなるので、日本語の中にアラビア語を挿入するなどの場合には十分使えるのではないかと思う。

Adobe Illustrator CS6日本語版の多言語対応

一方、Adobe Illustrator CS6日本語版では多言語対応コンポーザーなどは選択できず、「Adobe 日本語コンポーザ―」のみとなっている。
f:id:nixeneko:20171213121442p:plain
これでは、アラビア文字のような右から左に書くもの(RTL)であったり、同じ文字が語中の位置に形が変わる書字系には対応できない。また、タイ文字の様に記号の位置調整が重要なものも正しく表示されない。次の画像が入力例である。
f:id:nixeneko:20171213155615p:plain
アラビア文字のひどさは言うまでもないが、タイ文字の2行目において、文字の上方で縦方向に2段積み重なっていた記号が重なってしまっている。また、ヒンディー語は母音の再配置ができていない。これでは使い物にならない。

World-Ready Comopser

ところで、調べていたら偶然、CS4以降のAdobeソフトウェア(InDesign, Photoshop, Illustrator)にはWorld-Ready Composerが実装されているということを知った。次の記事である。

これによると、ソフトウェアの中東版向けに右から左への横書きや語の位置による字形の置き換え(contextual substitution)のような機能が存在していたが、CS4からそれが中東版以外のソフトにもWorld-Ready Composerとして実装されたとのことである。

ただし、Illustratorなどにおいては、World-Ready ComposerはAPIとしては存在しているが、先に挙げたようにUIからアクセスすることはできない。とはいえ、実装自体はされているので、中東版のソフトウェアで作ったテキストエリアを含むファイルを開きコピペすることで、CS4のIllustratorでもWorld-Ready Composerを利用できるという。

前掲のWebサイトにおいて、World-Ready Composerを利用したテンプレートファイルが配布されている(“Templates for ID, Ai & PS”でページ内検索するとよい)。
これを開いてテキストエリアを新しいドキュメントにコピペするとWorld-Ready Composerが使えるようになる。


実際にIllustrator CS6 日本語版やってみたのが次である。
f:id:nixeneko:20171213155007p:plain
すごい! 完璧! ちなみに文字の再配置を要するデーヴナーグリー(ヒンディー語)などにも対応しているようである。
任意の用字系に対応している訳ではないので、前掲のブログ記事の中のリスト等で確認するとよいと思う。何にせよ、正しく組めているかは(分かる人が)自分の目で見て確認する必要があるだろう。

バージョンCC以降

さて、World-Ready Composerが実装されたのは、全世界的に機能を提供するためであるというのは想像に難くない。実際に、Adobe Illustrator CCにおいて、中東やインド言語のサポートが追加されている。

「環境設定」の「テキスト」から「インド言語のオプションを表示」をオンにすると「中東言語および南アジア言語コンポーザー」が利用できるようになるとのことである。

素晴らしい。CC契約しようかな……。


(20171213 16時追記: アラビア語をコピペミスってたので画像を修正。ちゃんと確認してないのがバレバレですね……。)

フォントのアウトラインを法線方向に太らせたり細らせたりしてみる

フォント 画像処理

フォントのアウトラインの制御点を法線方向に沿って動かしたら文字の線をうまいこと太らせたり細らせたりできるのではないかと思ってやってみて、結果小さい移動量においてはそこそこになったように思う。

読まなくてもいい前書き

現在一般のコンピュータで使われているフォントは、文字を表す図形の輪郭をベクタフォーマットで収録したアウトラインフォントである。そのため、線の太さはアウトライン毎に固定され、線の太さを変えたければ別のアウトラインを用意するしかない*1。
そこで、一つの書体のアウトラインを変形して文字の線の太さをうまいこと変化させられれば、太さの違う書体を用意しなくてもよいということになる*2。


以下は、フォントのアウトラインの制御点を法線方向に沿って動かせばうまいこと太らせたり細らせたりできるんじゃないか!?と思いついたのでやってみたという記録である。恐らくこのような処理を実装しているソフトウェアはあるだろうし、これよりさらに良いアルゴリズムもあるだろうので、歪な車輪の再発明なのではという気はする。

ここで、アウトラインを「フォントの」と限定しているのは、アウトラインフォントに含まれるcontourがすべてclosed pathであり、open pathがないからという理由である。すなわち、contourによって表現される図形の外側と内側がはっきりとしているため、法線ベクトルを一意に定めることができる。

OpenTypeフォントではアウトラインを直線およびベジエ(Bézier)曲線の集合によって表現する。OpenTypeにはアウトラインデータの格納方式としてCFF形式とTrueType形式を選ぶことができるが、PostScript由来のCFFベースのもの(一般にこれが「OpenTypeフォント」と呼ばれる)では3次ベジエ曲線が使われ、TrueTypeベースのもの(これは一般に「TrueTypeフォント」とよばれている)は2次ベジエ曲線が曲線の表現に使われている。
この記事においてはTrueType形式のものについて扱うが、CFF形式の方でも同様に操作可能であると考えられる。

一続きの直線あるいはベジエ曲線によって表現される図形をcontourとよび、制御点列によって表現される。一つのグリフ(フォントによって描画を行う際の操作単位で、大抵は文字と一対一で対応付けられる)は0個以上のcontourからなる。

手法

一般に点に対して法線は求まらないが、ここでは、制御点の法線を、その制御点に隣接する2制御点とその制御点のなす2辺について、それぞれの単位法線ベクトルを足し合わせた方向のものとする。
つまり、 m個の制御点からなるあるcontourについて、制御点が \boldsymbol{p}_{k-1},\ \boldsymbol{p}_k,\ \boldsymbol{p}_{k+1} ( 0 \le k \le m-1)の順で並んでいたとき( \boldsymbol{p}_{-1} = \boldsymbol{p}_{m-1},\ \boldsymbol{p}_{m} = \boldsymbol{p}_{0}とする)、点 \boldsymbol{p}_{k}における法線ベクトル \boldsymbol{n}_{\boldsymbol{p}k}は、2点 \boldsymbol{p}_{k-1}, \boldsymbol{p}_{k}を通る直線の単位法線ベクトル \boldsymbol{n}_{k-1}と、2点 \boldsymbol{p}_{k}, \boldsymbol{p}_{k+1}を通る直線の単位法線ベクトル \boldsymbol{n}_{k}を用いて、
\boldsymbol{n}_{\boldsymbol{p}k} = s(\boldsymbol{n}_{k-1} + \boldsymbol{n}_{k} ),\ s > 0
と表せる。
なお、 sを \displaystyle s = \frac{1}{\|\boldsymbol{n}_{k-1} + \boldsymbol{n}_{k}\|}と定めると単位ベクトルになる( \|\cdot\|はユークリッドノルムを指す)。
f:id:nixeneko:20171211190003p:plain
TrueTypeアウトラインにおいて、contourの制御点を順番にたどっていった時の右手側が塗りつぶされることになると決まっているので、 \boldsymbol{n}_{k} = (x_k,\ y_k)^\topとしたとき、 \boldsymbol{n}_{k}は、スクリーン座標系(左上原点)において次のように計算できる。
\displaystyle \boldsymbol{n}_{k} =\frac{1}{\| n_k - n_{k-1} \|} (y_k - y_{k-1},\ x_{k-1} - x_k )^\top

ここで、フォントの座標系は左下原点だがスクリーン座標系は左上原点であり、y軸正方向が反転していることに気を付ける。

実験1

各頂点における単位法線ベクトルに沿って移動させ、色を変えて描画した図を次に示す。黒が元々のアウトラインであり、外側に移動させたものは緑～赤、内側に移動させたもの緑～青で描画している。
f:id:nixeneko:20171211230418p:plain
見ればわかる様に、頂点の前後の辺がなす角度に関わらず頂点の移動量が一定のため、全体として形が崩れていると感じられる。

実験2

次に、 sを
\displaystyle s = \frac{1}{1+\cos\theta} ( \thetaはその頂点を通る2辺の法線のなす角、上図参照)
とした場合の法線ベクトルの定数倍制御点を移動させてみる。
f:id:nixeneko:20171211231642p:plain
そうすると、移動量が大きい部分については自己交差して破綻している部分もあるが、小さい移動量においては割と全体的の形を保ったまま移動できているように思う。

ちなみに、 \displaystyle s = \frac{1}{1+\cos\theta}というのは、2辺の法線のなす角度が \theta = 0のときは \displaystyle s = \frac{1}{2}、 \displaystyle \theta = \frac{\pi}{2}のときは s = 1となるように定めた。

コード

描画に使用したPython 3コードを次に挙げる。描画に用いたフォントはM+フォントのmplus-1p-regular.ttfである。
フォントの読み込み～アウトラインの制御点列の抽出はFontToolsを利用した。
アウトラインの描画・画像の出力はPillowを利用した。
gist.github.com
制御点座標の操作はsetで表して泥臭くやったが、Google関わっているフォント系のライブラリにおいては制御点の表現に複素数型を使っていたし、あるいはNumPyのndarrayなどによって制御点を表すと座標計算が楽になるのではないかと思う。

考察

ベジエ曲線は凸包性(convex hull property)をもつ。凸包性とは、(n+1)個の制御点によって定義されるn次ベジエ曲線が(n+1)個の制御点の凸包(convex hull)の内部に含まれるという性質であり、要するに制御点がなす多角形によって曲線のだいたいの形が推測できるということで、これによって、ベジエ曲線の集まりで構成されるcontourについて、制御点のなす多角形(polygon)が均等に太るように動かすとそれによって表現されるベジエ曲線等もまあまあ均等に太るようになっている気がする。
何にせよ、ベジエ曲線(からなる図形)の操作に多角形の操作手法が適用できるというのは言えるのではないかと思われる。3DCGでオブジェクトをメッシュの法線方向に拡縮する手法があるので、それを適用してみてもいいかもしれない。

調べたら次のサイトが引っかかった。

このサイトによると、ベジエ曲線をオフセットした曲線を(同次)のベジエ曲線で表現することは不可能である、とのことであり、適当に近似するしかない。紹介されている手法では、適当にベジエ曲線を分割し、それらに対して法線方向に移動するというものである。

次のサイトでもいくつかの手法が紹介されているが、制御点を移動してみて、精度が十分でなかったら分割するという方針らしい。

結局、太らせたり細らせたりする方向にベジエ曲線を移動したものを同じ制御点数で正確に表現できないので、本手法では限界があるようではある。しかし、本手法で楽なのは、制御点の数が変化せず、また曲線を分割する必要がないため単純に前後の制御点をみて移動させるだけで済むという部分である。自己交差さえ何とかなれば何かに使えるかもしれない。

*1:2016年にリリースされたOpenType 1.8で導入されたvaribale fontではユーザーが書体の線の太さ等を動的に変えられるが、フォントデータには太さ等の違う2種類以上のアウトライン(に相当する)情報を含ませる必要がある。

*2:実際には、市販の書体ファミリー、特に極太書体では、字が潰れない様に部分的に細くしたりバランスを整えるために再配置したり要素を融合させたりといった調整を行っているため、機械的な太さの変更では一般に品質は低下すると考えられる。

OpenTypeフォントにSVGアニメーションを突っ込んでみる

フォント OpenType SVG

Twitterを眺めてたらOpenType-SVGを実装した話が流れてきた。

ちなみにその実装ではラスタ画像をSVGのベクタ形式に変換しているが、SVGの<image>タグのxlink:href属性にPNG画像などをdata URI schemeを使って埋め込むとラスタ画像も利用できる。


最近はAdobeのソフトウェア(PhotoshopやIndesignなど)がOpenType-SVGカラーフォントをサポートし始めたり、最新のWindows 10の描画エンジンでもサポートが始まり、Edgeなどでも表示できるようになっているらしく、今後が期待できる。


そういえば、OpenType-SVGではSMILによるアニメーションは問題なく突っ込めるという話があった*1。

OpenType fonts with either TrueType or CFF outlines may also contain an optional 'SVG ' table, which allows some or all glyphs in the font to be defined with color, gradients, or animation.

https://www.microsoft.com/typography/otspec/svg.htm

せっかくなので試してみる。

SVGのアニメーションといえば前になんか作ってたなあと思ったので次のページで作成したSVGをフォントに突っ込んでみることにする。

手順

編集する下地のフォントとして、M+フォントのmplus-1p-medium.ttfからASCIIコード外のグリフをごっそり削除したものを利用した(編集にはFontforgeを利用した)。
これは次のリンクからダウンロードできる。

まず用意した下地のフォント(mplus-mod.ttf)をTTXでXML形式にダンプする。

ttx mplus-mod.ttf

するとmplus-mod.ttxが出来上がるので、このファイルをテキストエディタなどで開いて編集する。

今回はアルファベットの“W”の代わりにSVG画像が表示されるようにしてみる*2。
まず、<GlyphOrder>タグで囲まれた要素を見て行って、WのglyphIDを調べる。今回は、次の記述から、58であることがわかった。

    <GlyphID id="58" name="W"/>


これをもとに、ルート要素である<ttFont>の子として次のように<SVG>タグを追加する。

  <SVG>
    <svgDoc endGlyphID="58" startGlyphID="58">
      <![CDATA[<svg xmlns="http://www.w3.org/2000/svg"
                    xmlns:xlink="http://www.w3.org/1999/xlink"
                    width="768" height="432" 
                    viewBox="0 600 764 432" id="glyph58">
        (SVGの描画される要素がここに入る)
      </svg>]]>
    </svgDoc>
  </SVG>

ここで、<svgDoc>タグにはstartGlyphIDおよびendGlyphID両属性に58(WのglyphID)を指定している。
また、<svg>タグはhttp://nixeneko.2-d.jp/hatenablog/20170330-svganim/animate.svgの中身を突っ込んだものであるが、viewBoxの2番目の値を600に変更し、さらにWのglyphIDの58に合わせてid="glyph58"の指定を追加している。<svg>タグの子孫要素は長いので記載を省略した。


最後に編集した.ttxファイルをTTXで.ttfフォントファイルに変換する。

ttx -o out.ttf mplus-base.ttx

完成したフォントは次のリンクからダウンロード可能:

サンプル

次のページで実際に試すことができる:


実際にFirefoxで見てみると次のようになった。
f:id:nixeneko:20171031204634g:plain
こいつ…動くぞ…!?


なお、Edgeで見てみたら次のような感じになり、アニメーションは動かなかった*3。
f:id:nixeneko:20171031210837p:plain
ここで、SVG画像の表示される高さや大きさが、Firefoxの場合と異なっている。SVGファイルをそのまま突っ込んだだけで幅・高さの辻褄を合わせていないから実装依存になってしまっているのだと思う。

ちょっとした解説

OpenType-SVGでは複数のグリフに対して一つのSVG文書(画像)を指定することができる。

つまり、TTXの形式では、一つの<svgDoc>を複数のglyphIDに対応付けることができる。この対応付けはstartGlyphIDとendGlyphIDで指定し、指定されたstartGlyphID～endGlyphID間に含まれるglyphIDに対応するグリフがそのSVG文書に結び付けられる。

また、<svgDoc>内に埋め込まれるSVG文書には、id="glyph58"のように、idに“glyph<glyphID>”の形で(その<svgDoc>と結びつけられた)glyphIDに対応するid属性を指定した要素が含まれていないといけない。グリフが描画されるとき、そのglyphIDに対応するidを持つ要素が画面に表示されることになる。

詳しくは仕様書を参照: The SVG Glyph Outlines Table


あと、svgのviewBoxの2番目の要素を変化させると、SVGがフォントとして表示される際の位置を上下に動かすことができる。今回使ったSVG画像は最初viewBox="0 0 764 432"と指定されていたが、その状態では丁度ベースラインからぶら下がる位置に表示された。なので、もう少し上の位置に表示させるためにviewBox="0 600 764 432"を指定した。

今回はSVG画像の幅や高さは特に気にせず突っ込んだが(それでも動く…!)、高さはフォントのEMのユニット数、幅はグリフのadvanceWidthに合わせるといいのではないかという気がする。描画時にどのように描画サイズが計算されるのかはちゃんと確認した方がよさそう。

まとめ

  • SVG画像で表示したいグリフに対応するよう指定してSVG画像を突っ込めばOpenType-SVGカラーフォントは作成できる
  • FirefoxではSVGのアニメーションまで動く
  • EdgeではOpenType-SVGは表示できるがアニメーションは動かない
  • SVGの幅や高さの指定がフォントの高さやグリフの幅と合ってない場合、表示位置や大きさは実装依存っぽい

*1:セキュリティ上の理由から、Javascriptは動かない。

*2:なぜWかというと、Windowsのフォントビューアのサンプルテキストの最初に来る文字だからである。なお、Windowsのフォントビューア自体はSVGフォントに対応してないので普通にWが表示された。

*3:そもそもEdgeってSMILアニメーションに対応してなかった…。