WSN追加案: フォントの強化

[req]

メッセージ・セリフコンテントのフォントの強化をご提案したいと思います。

メッセージの画像は、シナリオ：暑苦しい冬の道 の font_1.bmp ですので、砂雲堂さんに著作権があります。

スキンはBloodWirthを使用しましたので、著作権は スキン：BloodWirthの、ReadMe_BloodWirth.txt の記載のとおりです。

---

フォント色の強化は

&+アルファベット１文字で書けると良いというアイディアをまた貰ったので、

&+RGBYWOPLD以外のアルファベット１文字の色を募集して、エディタの設定で、カラーパレットを9個まで選べるように追加し、メッセージダイアログの色アイコンとそのツールチップと挿入記号を変更するという案にします。色リストは暇が出来たら作って、お示し致します。

あとこれは問題ないと思うのですが、プチ改革案として１つのフォント名で役割別フォント３７個を全置換えする案を実装したら pull request 予定です。

拡張コマンドはWsn書式確立まで後回しです。

詳しくは下のコメントで書きます。

いろんなアイディア・感想お待ちしております。

私は issue #453 でここ(Py フォーラム)はいろんなアイディアを出し合う場だと聞きました。ですので、どんどん言ってください。自分もどんどん言いますし、開発者の思い付き もどんどん言います。改善されると思えばそれを反映させたものにしていきます。

[Iraka.T]

書式などの仕様に関して、よりシナリオ作者が使いやすいように改善する必要があると思います。少なくとも私という一人のシナリオ作者は、この仕様では不満があります。

私の不満の内容は、読みにくい、書きにくい、です。仕様としての問題点を数あげるには私の見識が狭いですが、これに関しては間違いなく問題だと思います。

特に、テキストの末尾に対応する色を指定しなければいけないというのは、これまでの色指定の仕様と比較して、あまりに不親切でいびつです。

---

正直面倒くさかったので

指摘しますが、であれば@namereqさんが着手する必要はないと思います。意欲を感じる部分に取り組んでいただきたいです。

[req]

書式などの仕様についてシナリオ作者のご意見をここで上げていただければと思います。ならばどうであってほしいですか？

今のところ途中に&S{font:"colorName or RRGGBB"}などと入れてしまうと、

余計な改行が入ってしまうため後ろに持ってきたというだけです。

#453 で途中まで作っていて取り下げたので、最低限のたたき台としてのコードしか書いていません。blueなどのカラー名にも対応させてないですし、””や{}を付けていても大丈夫なようにもしていませんし、intに変換しているところでとかのチェックも入れてないですしね。

意欲はあるのですが、面倒くさかったと言うのは、ここで処理が落ちないかとか考えたりするのが面倒だっただけで、Wsn.2がより良いものになってほしいという気持ちはあります。

最終的には、長月さんが復帰してから仕様を固めて、レビューも受けて、実際に実装するかどうかという判断もなされてということになりますのでご心配には及びません。

この書き方のいい点としては何かしら拡張があったときに、後ろにコマンドを追加出来るという点にあります。必要なければ使わなくていい隠しコマンドのようなものと考えてもらえばいいと思います。

[Iraka.T]

シナリオ作者の意見ですが、文字色は該当箇所の直前で指摘するか、&R &G &Bのような&＋1文字の色定義をシナリオ内で行えるようにするべきだと思います。

個人的には、後者を推します。従来のメッセージテキストの書式を損なわずに、文字色のバリエーションを増やせるためです。

---

@namereq さんに意欲があるのは、私の目にもよくわかります。ただ少し、やる気が空回り、他のユーザーや開発者との意思疎通、相互理解ができないままに先へ進もうと暴走しているようにも見えます。

特にWSNシナリオの仕様に関しては、作業に入る前にissueを立て、仕様についての確認をし、仕様に問題がないと見込んでから作業に入るというのが開発の流れだと、私は認識しています。（間違いでしたらご指摘ください）

プレイアビリティ向上のためのUI変更などは、シナリオデータを左右しない変更であり、他のカードワースエンジンと仕様衝突を起こすことがないので、issueでの議論をスキップしてPull Requestされていることがあるのだと思います。（こちらも間違いでしたら指摘願います）

私はプログラミングが専門ではありませんし、意欲はソースコードを読むよりも自分のシナリオ制作に向いているので、実作業での貢献はなかなかしづらいです。そのため、技術と意欲を持っておられる @namereq さんを尊敬したいです。

[req]

&+1文字の色定義をシナリオ内で行なえるようにするべきとの案は、とてもいいと思います。 ちなみにですが、どこで出来るといいと思いますか？自分は今アイディアが浮かばないでいます。

自分は長月さんではないですし、まだd言語もpythonも初心者ですので、最低限の実現可能性を追求してみて、最低限のソースコードという形で実装してみて少しでも仕様に問題ないことを確認してからでないと、ご提案できません。

この書き方でいいとも全く思っていません。

プレイアビリティ向上のためのUI変更などは、シナリオデータを左右しない変更になるように 長月さんがWsnとそれ以外でうまく処理を分岐させたりして追加しています。 それもあり、#448 がまだうまくいっていないというのもあります。

[Iraka.T]

ありがとうございます。@namereq さんの意図やスタイルを説明していただけたおかげで、私は不安を除くことができました。

どこで出来るといいと思いますか？

色定義を行うのは、状態変数と同じSummary.xml内が適切だと思います。エディタ上での位置は、貼り紙情報の編集ダイアログ内がいい気がします。

[暗黒 騎士]

WSNシナリオの仕様に関しては、作業に入る前にissueを立て、仕様についての確認をし、仕様に問題がないと見込んでから作業に入るというのが開発の流れ

長月さんは作業が無駄になることを気にされているだけで、実装できる人は先に実装してこれどう？というのも説得の手段みたいなことも言っていた気がしますね。 実際たたき台があるとイメージしやすいですし、実装者（今回はname.reqさん）に無駄になる覚悟があるのであればそこは問題ないかと思います。

色定義は貼り紙情報だと静的な設定になるのでカラーステップみたいな枠を作って（あるいはステップ名でカラー展開に対応し既存の$$を流用）シナリオ内で動的に変えられた方が応用が利く気がしますが、仕様衝突が面倒ですね。

[req]

無駄になるのはもうこりごりなので、この位で出来そうだったらご提案していくことにします。

どういった感じがいいんでしょうね？

そこまで色々と色を使うとも思えない（シナリオ作者のご意見は伺いたいところ）ですし、 エディタのUIを変更するのに掛かる労力が大きいのも自分は痛感しているところなので、

いい妥協点が見つかるといいと思っています。

ちなみに$$とはどういったものなのですか？

[暗黒 騎士]

メッセージ内に$ステップ名$とするとステップ名が表示される、というCWに元からある機能ですね。

NEXTだと#Mや別のステップ名を表示する「特殊文字を展開」するオプションがあるようなのでそれの亜種・拡張的考えになるでしょうか。ご参考までの無軌道な意見ですのでピンとこなければスルーで。

[req]

静的に &W&R&B&G&Y&O&P&L&D 以外の & にシナリオの最初で設定して しまえるというのもいいのかもなあとも感じますし、

ステップで切り替えできるというのも良さそうですし、悩ましい限りですなあ。

---

適当にですが、妥協案として思いついたのは、

何らかの使っていなさそうな記号の１文字＋WRBGYOPLD以外のアルファベット の２文字の名前で付けられた ステップ があり、シナリオが Wsn.2 以降であった場合かつ、

選択中のSTEP- に付けられた 銀座線オレンジ のようなカラーネームやRRGGBB形式として読み取れた場合に限り、メッセージ・セリフ コンテントで & + アルファベット が使われたときにその色を使うというのはどうでしょうか？

それなら今までのステップがそのまま使えますし、&+ 一文字で書けますし、 変更がCWPy側だけで済み？ますし、現在のソースコートや仕様との衝突もないのではないかと思われます。

ただ、何らかの使っていなさそうな記号　というのを何にしたらよいかという点なのですが 何にしたらいいと思いますか？

---

あと、大抵の色は、HTMLリファレンス カラーコード表、色の大辞典

あたりから、カラーネームとRRGGBBの対応xml？を持つようにすればいいので、 RRGGBBを直打ちしなくて良くなるのではないかと思います。

---

既存のシナリオも、酔狂に&Zなどという名前のステップをそうそう付けているとも 思えませんし、今エディタを動かしてみたら&Zなステップが作れた （Summary.xml上の<Name>は&Z）ので、 &+ WRBGYOPLD以外のアルファベットの２文字の名前で付けられた ステップ でいいかなと思うのですがどうでしょうか？ あと、Wsn.2以降は １、Data/Skin/スキン名/Name/ColorName.xml ２、Data/Skin/SkinBase/Name/ColorName.xml(場所やxml名は要議論） を持たせて、順にヒットするか確認するようにすればいいかと思います。 例えば、 <Color><Name>漆黒の闇</Name><Code>FEFEFE</Code></Color> とか付けられるようにするのも 気分的にはいいかもしれません。

[Iraka.T]

CWPy開発における仕様衝突というのは、現存するしないにかかわらずすべてのカードワースエンジン間での仕様衝突のことだと認識しています。

WSNシナリオへの機能追加は、CWPy以外のエンジンにも影響を及ぼす（可能性がある）ので、慎重に行わなければならない、ということであるようです。

カラーステップみたいな枠を作って（あるいはステップ名でカラー展開に対応し既存の$$を流用）シナリオ内で動的に変えられた方が

NEXTだと#Mや別のステップ名を表示する「特殊文字を展開」するオプションがあるよう

色定義自体は静的に行い、NEXTの特殊文字展開オプションを実装すれば、カラーステップという新たな概念を作る必要はないように思います。

ステップのみで色を定義するのは、使用前に適宜ステップを変更しなければならないという不便があります。

既存のシナリオも、酔狂に&Zなどという名前のステップをそうそう付けているとも 思えません

そのようなシナリオが存在しない保証はできませんし、状態変数の名称によって扱いを変えるというのは、危険だと思います。

[req]

&って&に置き換わっているということは、禁則文字だったんですよね？多分。 そうであれば、禁則文字対応が入るまでそのような記号は使用できなかったと 考えていいのではないかと思っています。

最初に色定義するために&Zなりの名前のステップを作って、最初はSTEP-0が選択されているので、STEP-0にカラー名を入れておくだけで、それからステップの値を変化させなくてもいいですし、もう一度同じメッセージ・セリフコンテントに来た時に、色を変えたいのであれば、ステップの値を変えればいいですし、シナリオ作者にとっての負担は少ないのではないかと思いますし、シナリオをWsn.2形式で一度セーブしたあと、それ以外に戻すときに、&Zなりのステップを使っていて、メッセージ・セリフ コンテントで&Zなりの記号を使っていて、さらに選択しているステップ名がカラー名と一致するかRRGGBBに変換できる場合だけ気を付ければいいので、そう問題ではないのではないかと思うのですが、いかがでしょうか？

あと、この機能実装がCWPy側で済むようであれば、暗黒騎士さんに機能実装をむちゃぶりしてもいいかなと思っていますがどうでしょうか？構造メモ重宝してます。

それでよければ、Pull Request する際にぜひ name.req もレビューアにお加えください。 より良いものにできると思います。自分も #448 の実装の方にも本格着手出来ますしね。 さらにレビューというのもやってみたい気がするのですよ！

[Iraka.T]

&はXMLにおいて、文字参照の開始を示します。終了は;です。カードワースの仕様によらず、WSNシナリオのデータがXML形式であるために変換されているに過ぎません。

https://ja.wikipedia.org/wiki/%E6%96%87%E5%AD%97%E5%8F%82%E7%85%A7

[req]

&がクラシックシナリオでも入れれました。失礼しました。

もし仮に、&Zなりのステップを使っていたシナリオがあったとしても、メッセージ・セリフコンテントの本文に&Zを書いているシナリオ作者がいるとは思えません。今まで使えませんでしたからね？

Wsn.2 以降対応処理も入れるのであれば問題ないかなと思うのですが、どうでしょうか？

[Iraka.T]

私はやはり問題があると思います。

もし仮に、&Zなりのステップを使っていたシナリオがあったとしても、メッセージ・セリフコンテントの本文に&Zを書いているシナリオ作者がいるとは思えません。

というのは、@namereq さんがそうであってほしいと願うから、そう思えるだけです。また、メッセージ内に使用されていなければいいということもありません。同一構造のデータであるのに、データバージョンによって扱い方を変えなければならないというのは、いびつです。

エディタのUIがステップ同様に扱われるだけで、内部データがステップと別物であり、$ステップ名$では展開できないというのなら、かろうじて賛同できます。内部データをステップで扱うことには強硬に反対します。

また、少しやり取りのペースが早すぎ、結論を求める姿勢が強すぎるように見えます。共同作業ですから、待つことは大事です。CWPyの開発に関心のあるユーザーが、議論を常に見ているとは限りません。そして特に今は、全体をまとめている方が過負荷で休まれています。

[req]

ちょっと冷静に考えてください。 自分からすれば Iraka.T さんが難癖つけているようにも聞こえます。

同一構造のデータというのがどうとらえればいいか分かりませんが、メッセージ・セリフコンテントの本文に&Zなりが付いている場合、Wsn.1までなら&Zなりをそのまま表示、Wsn.2以降は、選択中のステップ名がカラー名やRRGGBBでない場合はそのまま表示、RRGGBBに変換可能な場合は、上記の対応とかにすれば、問題ないですか？

$&Z$を試したらstep-0が表示されましたけどね？

あと長月さん待ちであることには変わりはないのですが、 Iraka.Tさんのような方がいろいろ疑問をぶつけてくれて、 仕様を固めておくというか仕様案を出しておくのはいいことだと思っています。

基本、エディタなんかは今まで長月さんだよりにさせすぎで、 実際のコード見てこんなことやってたのかと思うと、 大変だったろうなあという印象しかありません。

$ステップ名$で色名を表示したい欲求も出てくるのではないかと思うのですが、どうですか？

[Iraka.T]

難癖のつもりはありません。ただ、私には @namereq さんの通したい案が、開発者に都合の良い推測に基づいて、既存の仕様を強引に変更しようとしているように見えて、抵抗を覚えているだけです。

また、再三申し上げますが、私は議論のペースが早すぎると思います。この場には、この機能を利用したいというユーザーの声もありません。開発者の思いつきや、作業を無駄にしたくない気持ちから、機能追加をすべきではないはずです。

$ステップ名$で色名を表示したい欲求も出てくるのではないかと思うのですが、どうですか？

色名とは、カラーコード等でしょうか。機械が処理するための、人間にとって直感的でない文字列を、プレイヤーに見せたいと考える理由は何でしょうか。

カラーコード等でなく色変更命令を表示するということであれば、前述のとおり、NEXTに存在する特殊文字展開オプションで対応できます。

自分が冷静でないかもしれないというのは自覚しましたし、私の言葉は求められていないようなので、当面意見や考えを出すことは控えます。

[req]

意見は控えないで言っていただきたいです。

既存の仕様を強引に変更しようとしているところはどこですか？ 自分にはよくわからないのです。

静的な新たな状態変数をもつということは、 cwxeditor にＵＩの変更（使いやすさを考えるとかなりの負荷）、 CArgの追加など内部処理の追加、それに伴うシナリオXML関連処理の追加、CWXスクリプト関連の処理の追加、CWPy側も新たな状態変数に対応する処理を入れなければなりませんし、上記で書いたように、ステップを変更しなければ、静的に設定していることと何ら変わりませんし、動的に色を変えることも出来ますし、 ColorName.xml など付けておいた、銀座線オレンジ とか 漆黒の闇 とかも出せるということですし、出したくなければ$&Z$なんて本文に書かなければいいことだと思うのですが。

あと NEXTに存在する特殊文字展開オプション の説明もしてもらえると助かります。

[tachi gigas]

不躾な具申にて恐れ入ります。

既にご存知かとは思いますが、 Issue #277 に、Wsn追加案の一覧があります。その中にフォントの色の強化もありますが、 同項にfont_?.bmpの強化もあり、この二つをk4nagatsuki様は類似した書式で考えられているようです。 フォントの色の仕様だけを先行して決めてしまうと後で身動きが取れなくなるのではないか(特に、k4nagatsuki様が)と危惧しますが、果たして如何なものでしょう。

僕の意見を言うと、シナリオ作者的に考えると、k4nagatsuki様の提案が尤もかなぁという気がします。この発言の根拠は直感です。自分の出自ではフラグやステップを使って特殊記号をメッセージに出す手法を使っているため、個人的に嫌な思いがするだけでしょう。

些末ですが、メッセージコンテントでフォントの書体を変更できると面白いかも知れません。ただし、仕様の実現については妙案が一切思い浮かびません。

[req]

font_?.bmpありますね。自分は font_1.bmp , font_1.png などが何者かすら知らないのですが、良かったらお教えください。外部で持ってる特殊文字のようなものなんですかね？

あと k4nagatsuki様の提案 の内容もお聞かせください！

基本 k4nagatsuki さん待ちしたほうが良さそうですね。

自分は #448 から先に手を付けて、この提案は minor にしておこうかなと思いました。

ユーザーの声というのは大事だと思っているのですが、開発するコストが機能実装に 割に合いそうにないことである声であると感じるとちょっと引いてしまいます。

[tachi gigas]

お疲れ様です。言葉足らずな箇所があり失礼しました。

font_?.bmpありますね。自分は font_1.bmp , font_1.png などが何者かすら知らないのですが、良かったらお教えください。外部で持ってる特殊文字のようなものなんですかね？

メッセージ・セリフ内に特定の画像を表示する機能です。例えば、オサールでござ～る様の「暑苦しい冬の道」で使われています。

あと k4nagatsuki様の提案 の内容もお聞かせください！

Issue #277 に書いてある通りですが、羅列なので分かりにくく、失礼しました。以下の記述があります。

font_?.bmpの強化。#{file:???.bmp}などの書式？

フォント色の強化。#{color:#RRGGBB}といった書式？

これらは煮詰めれば簡素になるかも知れませんが、これからの事を考えると簡素にするのは難しいような気がします。

僕もCWPyに色々手を加えたのですが、機能実装は色々と気苦労をします。機能を提案しようとするも、ああでもないこうでもないと躓く事が9.9割ですね。name.req様におかれましても、無理をなさらないようお願いします。

[暗黒 騎士]

暗黒騎士さんに機能実装をむちゃぶりしてもいいかなと思っていますが

多分この件は長月さんが大なたを振るう(決断する)必要がある案件だと思いますし、 自分はバグ報告や検証には関与しますが、PyRebootの方針に口出しすることはありませんので この手の実装についてはお力になれません。すいません。 (というかもうname.reqさんの方が書けるようになっている感じが…)

自分は #448 から先に手を付けて、この提案は minor にしておこうかなと思いました。

それがよさそうですね。あとモチベーションがあって、長月さん裁定を待たずに進めてみたい場合は、仕様衝突の心配のないNEXTの機能から手を付けて頂くのが無駄になりにくいのかなぁと思います。

NEXTの特殊記号展開オプション

#Mや別の$ステップ名$などをステップに埋め込むオプションです。 Iraka.Tさんが把握されているかは不明ですが、NEXTでは&カラーには対応していないので、自分は仕様衝突的なあれこれが億劫だということで引き合いに出しました。

長月さん案

#{file:???.bmp} 　 #{color:#RRGGBB}

自由挿入型でしょうかね？ であればステップ展開とも組み合わせが期待できますね。

[req]

お二方ありがとうございます！

#{file:???.bmp}、#{color:#RRGGBB} のようなコマンドは試してみて思うのは、 エディタの改行位置が甚だしくずれるのがあって、入れにくそうですよね？

それこそ何かで外部にコマンドを持っておいて、記号+アルファベット１文字位で呼び出すかなにかしないといけないかもしれませんね？

NEXTの機能、仕様追加案 見たら、他の互換エンジンの機能の欄ありますね！ 暇なときにぼちぼち調査して同じようにご提案したいと思います。

NEXTの特殊記号展開オプションですかあ、ステップの文字列が動的に変化してしまうわけですね？また訳のわからない機能を。実装上はステップの文字列を解析してさらに現在の状態を反映するのでしょうから問題はないのでしょうが、ユーザーからすると使いどころどうなんでしょうね？

tachi gigas様

BitBucket でフォローさせていただきました！ 機能実装はお互い苦労をしますね！無理しないようにします。ありがとうございます。

[req]

言い忘れていましたが、ただ何となく、ソース読んでいて、font_?.bmp とかとフォントカラーはかぶらない気はしているんですけどね？

[tachi gigas]

お疲れ様です。

#{file:???.bmp}、#{color:#RRGGBB} のようなコマンドは試してみて思うのは、 エディタの改行位置が甚だしくずれるのがあって、入れにくそうですよね？

色変更は一つのメッセージ内でそう何度も多用する事はない気がします。凝ったテキストを打つときは、どうやっても見辛い内容になってしまいますがそれは仕方ないですし、現在もそうだと思います。CWXEditorにはプレビュー表示がありますし、いくら複雑怪奇なメッセージを打っても確認ができます。ただ、人が読むのに適さないシナリオ作ってる僕の意見なので、一切参考にならないでしょう。

言い忘れていましたが、ただ何となく、ソース読んでいて、font_?.bmp とかとフォントカラーはかぶらない気はしているんですけどね？

多分僕が問題にしているのは、コマンド文の記入の仕様です。今、ユーザビリティを考えて決めないと、シナリオ作者とk4nagatsuki様の面倒になると思います。

[req]

多分僕が問題にしているのは、コマンド文の記入の仕様です。今、ユーザビリティを考えて決めないと、シナリオ作者とk4nagatsuki様の面倒になると思います。

ユーザビリティ、曲者ですよね。そうですね。コマンド文の記入の仕様とか決まってからで遅くないですね。ありがとうございます。

tachi gigas 様

メッセージコンテントでフォントの書体の変更ですが 今試してみたのですが、Grepしまくってソース追ってみたところ、これでメッセージダイアログのフォント変わりました！　@tachi_gigas 様も試してみてください！ cw.cwpy.rsrc.fonts["message"] している前で

        fontname = フォント名（unicode文字列）
        t = ("", fontname, 22, True, True, False)
        cw.cwpy.setting.fonttypes["message"] = t
        cw.cwpy.rsrc.fonts.set("message", cw.imageretouch.Font, fontname, -cw.s(22),False
　　,False)

[req]

今自分が提案している方式のメリットを今頃になってまとめておきたいと思います。問題点は、貼り紙でスキン設定していることに今頃気づいたのでなくなりました。

メリット

こんなところだと思います。

7でステップ名の入力をコンボボックスに変更しておくと、メッセージ・セリフコンテントの本文で、#Yなどと入力しておいて、ステップ名で#Yを選択し、ステップ値に{font:RRGGBB},{file:???.bmp}などの拡張コマンドが書けるようになるのではないかという利点もあります。

[req]

今自分がフォントの色について提案している方式は、開発者の思いつきが散乱しているので整理して、

詳細設計レベルに落とし込んで書いておきます。追加：スキンのColorName.xmlの分も反映しておきます。

これを見てくだされば自分が何を考えていてユーザビリディとソース安全性をそれなりに追求していることが分かってくれると思います。仕様について問題があったりユーザビリティに更なる改良が必要ということであればご指摘ください。

フォントの色 詳細設計案

自分の場合 長月さんと違って dもpythonも初心者ならば、CardWirthPyも詳しくないしCardWirthのことも忘れていること多いので、ここまでしないと受け入れられないと思っています。

---

@tachi_gigas さんがフォントの書体も変更できると面白いと仰っていたのである程度調べたら、

フォントの書体（フォント名）の方も出来そうなので、叩き台としての仕様案をご提示しておこうと思います。本当はBoldとItalicも変えたかったのですが、メッセージダイアログでは現状ずれてしまうので、フォント名の対応にしています。こちらは

1. エディタのダイアログのコンボボックスとボタンの配置位置をどうするか
2. 選択できるフォント名の候補をどうするか
3. シナリオのXMLの fontname の指定位置は適切か
4. ＣＷＸスクリプトのどこにフォント名を追加するか
5. 一度cw.cwpy.rsrc.fonts.set で設定されてしまうと、そのままだと後のメッセージ・セリフコンテント に引き継がれるのだが、デフォルトのフォント名は保持しておいて、fontname の設定がない場合は デフォルトのフォント名 を出すほうがいいのか、引き継がれるのがいいのかという問題

とかの議論の余地があるかもしれませんが、後はWsn.2以降で、メッセージ・セリフコンテントに fontname:フォント名 が追加されるという内部処理の対応が主で、こちらの方が問題点が少ないかもしれません。

今回はパラメータ１つの追加 (それも省略可)です。それに仕様的にもCardWirthPyのソース的にも、フォントは衝突の可能性が少ないと思います。フォントはエディタの修正も少なめですし、CardWirthPyのソースは自分が見た範囲ではかなり柔軟に作られています。d言語(エディタ)の方は Templete とかいろいろまだよく分からす試行錯誤しています。

詳細設計レベルに分解しておきますので、ご議論の対象に加えていただければと思います。

フォント名 詳細設計案

ああやっと書きたいこと書けた。 #448 に戻ります。

---

よく考えるとカラーステップを設けたほうがユーザビリティが向上するし、データバージョンによって挙動が変わるということが全くなくなる（ステップの亜種の追加だから）かなとも思った（エディタのUIやエンジン・エディタの内部処理はかなり増えそうではあるのですが）ので、今度叩き台としてカラーステップの場合の詳細設計（ステップからの変更点）を挙げてみたいと思います。

[k4nagatsuki]

冒頭のスクリーンショットに使用している素材のライセンスを明記しておいてください。

---

まず、仕様において本質的な決定権を持つのは私ではないという事を認識していただければと思います。私が出した案が通らず、他の人の案で問題が解決されるという事はこれまでにもありました(例えば#405)。

結論は議論から出ます。例外は誰も意見を出さなかった時くらいです。

ですから、以下の意見は他の方の意見と同程度の重みを持つものと思ってください。

---

後からやってきてちゃぶ台返しをしてしまうようで申し訳ないのですが、色定義をメッセージコンテントの外に出すのは、私は反対です。

1. 使用時イベントで使うと、カードがシナリオ外に出た時にちゃんと動かなくなります。
2. イベントツリーを他のシナリオへコピー&ペーストするとちゃんと動かなくなります。
3. ファイル名や状態変数名のように色情報を管理する仕組が必要にあり、それはどうしても大掛かりになります。
4. 実際のメッセージがどのような表示になるか、その場で結果を確認できないケースが発生します。例えばメッセージだけ書いて色定義を後回しにした場合など。
5. 大量の色を定義しようとすると文字数が足りなくなります。

非常に努力すれば1.～3.の問題を解決する事もできますが、解決して得られた結果が色の変更や書体の変更だけでは引き合わないように思います。それらは頻繁に使うものではない上、別のもっと簡単な方法でも実現できるからです。

簡単な方法とは、メッセージの中に特別な書式で直接情報を書き込む事です。@namereqさんは「エディタの改行位置が甚だしくずれる」という理由で否定的ですが、私はそれが定義を外で行う仕組を用意しなければならないほど重大な問題とは思いません。

• 書いた結果はその場でプレビューで確認できます。ミスがあれば一目で確認できます。
  • 外部化すると、例えば上記4.のケースなどでプレビューが機能しない事もあります。
  • 慣れてくると文章を見ただけで結果が分かります。
• 入力はエディタでサポートできます。
• 色などの一括した変更はテキスト置換で行えます。
• CWのユーザは、プレビューも無い時代から、ステップ参照やフラグ参照を使いこなして想像以上に複雑怪奇なメッセージを書きこなしています。

そして上の方で挙げたデメリットはなくなります。

---

ところでクラシックなシナリオやWsn.1以前のシナリオに対する互換性や仕様衝突の問題については、私はあまり心配していません。

新しい仕様は「Wsn.2書式(もっといい名前があるはず)」のように名付けて、メッセージコンテントごとにどの書式を選択するかが選べるようにすればよいのです。この方法なら、他の仕様で全然違う書式が出てきても対応する事が容易です。例えば従来型の「CW書式」と「Wsn.2書式」と「X書式」と「Y書式」と……など、選択肢が増えるだけです。

もちろん書式が各仕様で同じである事に越した事はありませんが、たぶんそれは不可能事なので、開き直ってしまった方がよいです。

[req]

仕様において本質的な決定権を持つのは長月さんではない...結論は議論から出ます。...以下の意見は他の方の意見と同程度の重みを持つものと思ってください

了解しました。Iraka.T さんも拙速だと言っていましたし、自分も冷静に、ここで出てくる意見を全て十分に尊重したいと思います。

長月さんの意見が出る前までは、

1. 静的と動的ならば動的の方が色変えられていいよね！
2. RRGGBBと入れるならカラー名入れたほうが親切かな？
3. 動的ならばステップの設定にUIの改良が必要かな？
4. これらでかなりの開発コストがかかりそうだな！

と思っていましたが、

1. Iraka.T さんのシナリオ作者として、フォントの色は静的で十分、指定位置で記入してもよい
2. 長月さんの、上記問題がある、「Wsn.2書式」として拡張コマンドを導入しても問題ない
3. カードワースのフォント色は元々静的。
4. それならエディタは基本、メッセージダイアログ（当然プレビュー含む）の変更だけで済み、エンジンも基本として拡張コマンドに対する処理分岐を入れればいい。

という点を踏まえて、本文の途中に拡張コマンドを書く案に賛成に乗り換えます。

後は、拡張コマンド種別を入れるコンボボックス（リストには [”フォント色”,"フォント名"]）、拡張コマンド文字列を入れるコンボボックス（フォント名は選択出来たほうがいいから）、それを入力するボタンをメッセージダイアログのどこに持つかというのと、

#{拡張コマンドtype:"拡張コマンド文字列"}とし、

フォントの色は #{color:"RRGGBB"}

フォント名も、本文の途中で cw.cwpy.rsrc.fonts.set すればいいだけですから、 #{fontname:"フォント名"}

とするのはどうかなというのが今現在の自分の案です。

[k4nagatsuki]

書式ですが、「#」はいらないかなぁと今は思います。{...}だけで充分一般の文章には出てこない表記な気がします(このカッコの本来の役割は数式用ですかね)。.NETみたいだなぁと思いましたが、あのMicrosoftが検討の上この記法採用したのですから、模倣するのもありでしょう。

もちろんエスケープ文字も必要です。プログラミングで一般的で、ExcelのCSV表記でも使われているバックスラッシュ(円記号)でいい気がします。

fontnameは、たぶんfontfaceの方がいいでしょう。CSSなど他の規格の名前が参考になる気がします。

さっきから「気がします」ばかりですが、じっくり考えた方がいいところなので、時間をかけて検討していきたいという気持ちが出ている気がします。

#{拡張コマンドtype:"拡張コマンド文字列"}

コマンド文字列は"で囲わないで済む方がいいと思います。コマンド名をアルファベット表記に限定すれば、区切りの:の位置は確実に検出する事ができます。

少し前から迷っているのが略記法を用意するかです。つまりcolorをCのように省略できた方がいいか。こうしたものが増えると暗号にしか見えなくなってくるので、当面は見合わせた方がいいのではないかと今は思っています。

---

UIですが、色は、ボタンを押すといわゆる色選択ダイアログが出てきて、OKで挿入される形がよさそうです。

フォントフェイスの変更は、性急に実装しない方がいいのでは、と思っています。すでにJPTXやテキストセルで、作者が指定したフォントが普通の環境には入っていないせいでちゃんと表示されないという事故を見た事がありますし、そもそもメッセージのフォントは自由に変えられるので、デフォルトフォントとシナリオ作者で指定したフォントの兼ね合いで意図したように表示されない可能性が大きいです。

需要が大量にあるならできた方がいいかもしれませんが、それはまだ不明です。

需要について言い始めると、自由色指定についてもどれくらいあるのかが分からなくなってきます。実際のところどうなんでしょうか。

[k4nagatsuki]

個人的にWsn.2までにあった方がいいと思っているのは{file:nnn.png}です。任意のファイルを表示できるようになれば、キャラクターのイメージに無理なファイル名をつけずに済みますし、置き場所も自由になりますし、Bitmap以外のイメージの指定もできるようになります。

[req]

{file:nnn.png} ですが、自分は特殊フォントがどういう原理で表示されているのか、特殊フォントとして使える画像がどんなものかとか知らないのでお聞きしますが、どんなサイズで、どんな形式のものが使えるとか決まりはあるのでしょうか？

前どこかの議論で font_1.jpg の導入が見送りになったとかいうのがあった気がするのですが？

[k4nagatsuki]

CWのイメージ特殊文字は、font_N.bmpというファイル名で、Nの部分に任意の文字(ただしShift JISで1バイトのもの)をシナリオフォルダ直下に置く事で使用できるようになります。

例えばfont_1.bmpを置くと、#1でそのイメージが表示されます。

今のところ、ビットマップイメージしか使えなかったと思います。他の拡張子のイメージが同時にあった場合、どれを表示していいか分からなくなるためでしょう。

サブフォルダに置いたイメージも使えません。これは元々CWのシナリオがシングルフォルダ前提だったためもありますが、サブフォルダに置けるようにしても、やはりどれを表示していいか分からないので対応は難しいと思います。

同じ理由で、CWPyもシナリオフォルダ直下に置かれたビットマップイメージだけに対応しています。

ちなみに標準の特殊文字(#Aとか)とバッティングした場合は、シナリオ側のイメージが優先されます。

[req]

ということは、Scenario直下の画像は自由に対応させて良さそうですね？　背景画像をbmpに変換して font_4.bmp に名前を変えて、#4で実行したら何か変な感じに表示されたので気になって。

このコメント の内容はもっともだと思っているので、

フォントの色に関しては、ユーザーのニーズがあったら

ボタン一個を &D の色アイコンの隣にボタンを置いて、押されたら色選択ダイアログを出し、OKされたらコマンド挿入。

フォントフェイスについては JPTXやテキストセル でも出来るのだからやってくれというユーザーのニーズがあったら、

コンボボックスとボタンを置いて、コマンド挿入。ってところかなと思っています。

[k4nagatsuki]

何か変な感じに表示されたので気になって。

たぶんこれはマスク表示されたせいじゃないでしょうか。CWではカードイメージなどを表示する時、左上のピクセルをマスク色として、その色の箇所を透明化します。font_N.bmpは必ずマスク表示となるので、不透明を前提とした背景画像はおかしな事になります。

{file:???}は、???の部分にファイルパスを直接書く事で、どんな名前・場所のイメージファイルも表示できるようにする事を意図しています。

[req]

font_N.bmp の コンボボックスと画像参照ボタンが既にあるので、それにシナリオ中の全画像のファイル名をリストに載せるようにして、

ボタンを押されたら、Scenario直下のfont_?.bmp は #? のままにしておいて、

その他は {file:画像ファイルのScenarioからの相対パス} のコマンド挿入って感じにすればいいのですかね？

[k4nagatsuki]

ボタンを押されたら、Scenario直下のfont_?.bmp は #? のままにしておいて、

この辺もちょっとした悩みどころだったりします。というのは、新しい書式の方には、font_?.bmpの参照を残さなくてもいいように思えるのです。既存のやり方に慣れた人のために残すべきか、処理の一貫性を保つために(特にエスケープの処理がこんがらがりそう)機能しないようにするべきか？

1文字で色を指定する書法は残した方がいい気がしています。font_?.bmpなどと違って制約が少なく、簡潔に表記できるからです。それを残すのであれば、イメージ文字も残した方がいいのかもしれません。

そして、それを残すのであれば、エディタ側の実装は仰られたような形でいいかと思います。

[req]

それでは特に異論が出ないようなら、先に{file:画像ファイル} をやってコマンド慣れしてもらうほうがいいと思います。 コマンド用のメソッドをエンジン、エディタ両方とも作ってしまえば、後でフォントの自由色定義やフォントフェイスのニーズがあると分かった時に追加実装しやすくなるので。

[k4nagatsuki]

もし実装するおつもりでしたら、他の意見が出るかもしれないので、しばらく待ってからにしてください。私は最短一週間程度を目安に待ってから取り組む事にしています。

作業を始める前に一言書いておけば、よりスムーズになると思います。私は最近は結構それをサボってしまっていたのですが(すいません)、これからはきちんと書くようにします。

[req]

一週間程度ですか。分かりました。

今 #448 のダイアログのGUIにやっと目途が付いた（まだ適用ボタンを押したら処理が落ちたりしている）ところなので、まだまだ内部処理とか残ってますし、{file:画像ファイル} は、エディタのGUIやXML、CWXスクリプト、パラメータとかの変更がないので、作業量もそこまでではないので、Wsn.2 がいつ公開なのか知りませんが、十分余裕あると思います。

[req]

&+RGBYWOPLD以外のアルファベット１文字 に色を割り当てるというアイディアを出してもらったので、それはいいね！と思ったので、フォント色を両論併記にしました。

&+RGBYWOPLD以外のアルファベット１文字 に割り当てる色の案を募集したらどうかと思います。CardWirthPyのWsn.2が定義してしまっても問題ないと思います。

フォント色の例として　ダークレッド(139,0,0) があります。

---

フォントフェイスは、遊び方の提案として、シナリオで、このフォント入れてプレイしてね！とかReadmeに書いたりしないんですかねえ。Linuxとかならともかく、Windowsだったらフォントを入っているか確認したり、入れたり出来ると思うのですが。

自分、前はフリーの TrueType などのなんか可愛らしかったり、ロボット文字のようなのだったり入れたりしてましたよ？　あと、元ＭＳＸ使いなので、BASICのBLOADコマンドで フォントを変更して遊んだりしていました。

---

フォント色の　&+RGBYWOPLD以外のアルファベット１文字 に色を割り当てるという案　の利点は、

1. シナリオ作者に、エディタのメッセージダイアログにカラーパレットカスタマイザ機能（色アイコンとその順番と個数を変更する）を提供できる。初期値は今の順番と個数にしておけばいいので、シナリオ作者には負担がない。
2. CardWirthPy が新しい色を定義するという、カードワースの新しいデファクトスタンダードを決めていける？
3. シナリオ作者が、&+アルファベット１文字という使い慣れた記号を、使い慣れた色アイコンで挿入できる。
4. CardWirthPy 側の実装が簡単すぎる

というメリットがあります。ただ確認しないといけない点は、

1. 設定画面に #448 の得点のないクーポンビューの劣化版（TableColumnに色も載せる点ではメンバ選択分岐などの得点のあるクーポンビューの方を参照）のようなカラーパレット設定画面を置けるのか確認していないというのと、その開発コスト。
2. もし、Lyna さんが気が変わって、バイナリから起こしたソースなので他人が読んで分かるものかどうか到底分からないが、CardWirth 1.50 の delphi? のソースを公開し、かつそれを理解して、追加実装し始めた開発者が現れて、カードワースの正当後継者を名乗りだし、&+RGBYWOPLD以外のアルファベット１文字 に色を別に割り当てだしたらバッティングする

位なものです。

---

あと議論中の自分のコメントは、あとで反省したり確認して分かったりして修正していることも多いので、さかのぼって確認していただけたらと思います。

[k4nagatsuki]

&+RGBYWOPLD以外のアルファベット１文字 に色を別に割り当てだしたらバッティングする

私もこれを心配しているのですが、従来型の色指定は簡潔で、色々なシナリオで統一感を出せるというメリットもあるので、それで相殺できるか判断が分かれそうな感じですね。

技術的にはバッティングはしません。理由は、上の方に書いたとおり、WSN形式は自らの書式を従来のものとは別に発展させていく事ができるからです。

しかしシナリオ間でテキストをコピー&ペーストしただけで色が変わってしまう、というような形でのバッティングは起こってしまいます。

私個人の立場としては、積極的に推進したい人がいるなら特に反対はしないかな、という感じです。

---

フォントについて。シナリオの側でプレイヤーにフォントを入れてくれというのは、手間がかかりすぎで筋がよくないです。

それより、フリーなライセンスのフォントをシナリオに同梱して、それを使えるような仕組の方が有望だと思います(フォント同梱のアイデアは一覧に入れたはず)。

[req]

tachi gigas さんがフォントの書体を変えられると面白いといったことについて、自分は完全に同意しています。前述したとおりフォント大好き人間です。カードワースのシナリオの作りやすさから、大袈裟な話、Wsn.4 あたりではノベルゲームが作れないかと思っているぐらいです。

フォント同梱のアイデアは一覧に入っていること確認しました。これはエンジン・エディタはWindowsやLinuxその他で実現可能なのでしょうか？自分はまだファイル関連とかその辺りにエンジン・エディタで触れていないのでお聞きいたします。

---

あと twitter で、暗黒騎士さん相手に少し呟いたこともありますが、ここで言っておくと自分はソフトウェア開発者としても、CardWirthPy の 開発の姿勢についても、長月さんを尊敬しています。基本的に、長月さんのイエスマンだと思ってもらって結構です。

ですが、需要（ニーズ）の判断については自分の判断を改めて、ちょっと追求してみたいと思います。

需要（ニーズ）は世に出してみないと分からないところがあると思います。 正直個人的には、今でもそれなりのバランスブレイカーで、実装するにはシナリオ側からの制限や、プレイヤーも出す・出さないを選べるぐらいしないとと思っている、NEXTのバックパックは、Lynaさんの独断で出されたものなのに、一定数の支持を受けています。個別荷物袋が欲しいからNEXTを使うという人もいるそうです。

フォントの自由色定義とフォントの書体（フォントフェイス）については、コマンドで Wsn.2 で実現しておいて、使えるようにしておいていいと思います。それもあって自分が入れた趣味も混じったアイディアとは違い、実現してより良くなると思って、長月さんはコマンド案を一覧に入れたのではないかと思っています。

そこで私のこの２つの修正案としては、エディタのCWXEditorの設定のその他のイベントビューの設定の最後に "フォント色・フォントフェイスのコマンドを使用する"か何かの文言でチェックを用意し、それにチェックが入っている場合、

&Wなどのアイコン類と#Pなどのアイコン類の間に１段設けて、フォント色の自由色定義のためのボタン、フォントフェイスのためのコンボボックスとボタン、必要があればそれらを分ける仕切り線　を追加し、既出のコマンドを挿入するようにしたらどうかという案に変更してご提案します。

フォントフェイスはフォントの色が最初 白始まりで、次の挿入位置から色が変わって、後続のメッセージ・セリフコンテントに引き継がれないのと同様に、"mincho" か、プレイヤーが設定した、メッセージ・セリフ用のフォントがデフォルトになっているので、 それは保持しておき、コマンド挿入位置でフォントが変わり、本文終了時にデフォルトに戻しておくという案にしておきます。

それなら使わない場合は今までと変わりませんし、#448 で少しはUI周りに慣れてきたので、追加も出来ると思いますし、コマンドについては、異論がなければ先に実装する {file:画像ファイル} のメソッドを使えますので、実装が少しは楽だと思います。

異論がなければ、これらも {file:画像ファイル} の後で実装したらどうかと思うのですがどうでしょうか？

[tachi gigas]

恐れ入ります。

僕の考えの補足ですが、フォントの指定はゴシック・明朝から選べれば面白いかもというつもりで申し上げた所です。 それ以上の事をするならば、k4nagatsuki様の仰る通りフォントの同梱が必須だと思います。 現行Py(というか1.50)のテキストセルは、個人的にかなり筋が悪い仕様だと思ってます。

フォントの同梱も、シナリオ作者側に再配布可能フォントかどうかの判断を迫る点を考えると、中々面倒ですが。

[k4nagatsuki]

出す事でニーズを探れるというのは逆説ですが、なるほどその通りだと思います。

フォントフェイスの変更を可能にするという機能自体には、私は条件つきで賛成です。その条件とは、事前にある課題を解決する事なのですが、これがどうも厄介そうです。

---

JPDCやテキストセルですでに可能であるにもかかわらず、メッセージでフォントを変更するという事を考えると、頭の中で警報が鳴り響くような感じがしていました。それはなぜかと考えていたのですが、ようやく今日になって、問題の正体に気づきました。

フォント変更機能の前に解決するべき課題があります。それは技術面での問題ではなく、需要の問題でもなく、CWのメッセージの仕様です。

CWのメッセージの文字は、実は単純なテキスト描画処理で配置されているのではありません。例えばメッセージのフォントサイズを変更したり、可変幅フォントを使用したりすると、一部の文字が重なり合ったり離れ過ぎたりする状況が起きます。なぜこんな事が起こるかというと、メッセージでは、フォントによらず、各文字が描画される位置が決まっているからです。

1.50以前のCWでは、全角1文字22ピクセル幅のMS明朝が使用されていますが、これらの文字は実は21ピクセル間隔で配置されており、普通にTextOutしたときよりも若干1行の幅が狭くなっています。この幅は変更する事ができません。変更すると、既存のシナリオで折り返しの位置がずれるので、ずらさないためにメッセージの幅を変えざるを得なくなるが、それによって特殊文字の描画位置がおかしくなり……といった問題が起きて解決不能に陥るからです。まして可変幅フォントを使って文字ごとに幅を変えるなどできるはずがありません。世の中には右から左へ書く言語がありますが、そうした言語の文章の描画に対応する事もまずできないと思われます。

フォントフェイスの変更に対応するという事は、フォントサイズや装飾の変更にもいずれ対応しなければならなくなるという事です。この「書体にかかわらず文字がそれぞれ特定の位置に描画される」問題を解決しておかないと、それらに対応する時に困難極まりない事態が発生します。

これは、メッセージの描画を拡張するのであればいずれ解決しなければならない課題であって、メッセージの書式をむやみに増やすべきでない事を考えると、解決のタイミングはWSN書式(仮)を新しく作る時に他なりません。

そこで別の問題が起きます。Wsn.2のリリースは、たぶんそんなに遠い事ではないと思います。この課題を解決して新書式の実装を入れようとすると、急ぐ必要が出てくるのですが、そこそこ繊細な問題なので、急ぐ事には恐怖を覚えます。それより、もっと時間をかけて検討を行い、実装にはWsn.2リリースの直後のような、時間に余裕のあるタイミングで取り組んだ方がよさそうな気がします。もちろん{file}も後回しになります。

---

私の考えている解決方法の一つは、「WSN書式(仮)を選んだ時には従来型の配置方式を捨てて普通のテキスト描画(幅が文字ごとに決まる)を行う」という単純なものです。しかしこれは、プレイヤーの環境によって各文字の位置が変わる事を意味するので、特にイメージ型の特殊文字の配置で厄介な問題を引き起こします。それは座標で表示位置を指定するような形にした方がいいのかもしれません。また、環境によって行数が若干変化してしまうかもしれず、文章の末尾が表示されないような事故が起きるかもしれません。

他にどんな問題があるかは未知数です。

[req]

tachi gigas さん、ご意見ありがとうございます。フォントの同梱がシナリオ作者側に再配布可能フォントかどうかの判断を迫るという点については、CardWirth は素材の著作権表記とかをシナリオ作者は Readme できちんとやっていたりするので、それの手間がちょっと増えるだけかなと思っています。

長月さん、なるほど、メッセージのフォントがサイズ変えたらずれたり、BoldやItalicにチェック入れてても、メソッドでBoldやItalicにならないようになってたのはそういうことですか。

コマンドは全て WSN書式の実装まで後回しということで。

残った、フォントの色の&+RGBYWOPLD以外のアルファベット１文字 に色を別に割り当てる案ですが・・・、

シナリオ作者がこんな色使えるといいというのが今のところないですし、１つ２つの色追加だと、カラーパレットカスタマイザ機能を実装する開発の手間を考えると、割に合わない感じがしています。

そこでやはり１週間程度おいて異論がないようだったらですが、

色の募集をして一定数集まるのを気長に待つか、

それとも出してニーズを探るという意味では Wsn.2 でよく使いそうな色（標準色）をここで割り当ててしまって、ここなどに標準色リストを掲載しておき、αで試してもらって、色を変えてほしいとかの要望がここなどであったら調整とかでもいいかなと思えてきました。

色の募集をして一定数集まるのを気長に待つ場合、自分は NEXTの機能のうち、バックパック（エンジン側のＵＩのかなりの変更やオプション追加など色々あり、今の自分には手に負えない）を除いたもので出来るものの模索か、フォントの同梱の模索でもしておこうかなと思います。

まあ、また長月さんがより良くなると思い WSN追加案として major で課題を立てたものに対し、少しでも出来そうならそれから着手するほうが安全かなとも思っています。

また言っておきますと、詳しくはディープな話になるので言いませんが、cardwirthpy の 意見を出してくれるシナリオ作者、バグチェック・修正、追加・修正案の提示・調査、開発 などに携わっている全ての方々の中で、多分 自分が一番暇していると思われます。ですので、cardwirthpy のために多少の無茶は効きます。

---

tachi gigas さんのご意見から、フォントフェイスを、基本フォントのみ、サイズ22サイズ固定、Bold、Italicなしとか考えなくもないですが、やはりメッセージのフォントフェイスに関しては、WSN書式の実装まで後回しが適切かなと思っています。それよりJPTXやテキストセルの為にもフォント同梱かなと。

あと、テキストセルでの仕様の問題点ってどこにあると思いますか？一覧に上がっているように折り返しが出来ないことですか？フォント同梱されていなくてシナリオ作者が思った通りの表示が出来ないことですか？

---

ネットサーフィンしてて、tachi gigas さんのご意見の中にあるように、フォントの再配布って思ったより大変なのかなと思えてきました。フリーフォントと銘打っていても、再配布可能かとなると、判断は難しそうだなと感じています。 自分の Windows10 に以前使っていたフォント：YukarryAA.ttf をダウンロードしてそのファイル右クリックで出てきたメニューでインストールを選んで、cardwirthpy を起動したら設定で YukarryAA が出てきて表示出来たことを考えると、フリーフォントで再配布可能か分からないものは、インストールしてね で済ます方がいいような気もしてきたのですが。というのも、シナリオ作者が演出強化にこだわってフォントフェイスを指定したい場合、マイナーなフォントの場合も考えられ、ライセンスや再配布可能かがはっきりしない（YukarryAA もどこに書いてあるのか分からない）からです。 もしくは、フォント同梱のアイディアが実装されたときには、CWPyに、分かっているだけのシナリオで使えるフリーで再配布可能なフォントの一覧.txt 付けてあげると親切かもと思いました。 またプチ改革案として、CardWirthPyの設定（詳細モード）のフォントの役割別フォントの フォント名の選択アイテムに、総称ファミリ名：CSSのfont-familyで指定出来て、直接のフォント名ではない、sans-serif,～,monospace(ゴシック系や明朝系などのフォント指定) を追加で入れたらどうか　(この指定をした場合、実際使われるフォントがどのように決まるのか自分は今のところ知らないので、表示例に表示し、実際使われるフォントをどうしたらいいかが分からないし、何となく言ってみただけなところもあります) と、 右クリックしてメニューが出るようにし、”全てのフォント名を統一”か何かのメニューアイテムを出し、その選択状態のフォント名で役割別フォント全てを埋め尽くすとかしたらどうかと思うのですが。

---

カラーパレットカスタマイザ機能は、壮大にしすぎましたので修正します。 色の個数は現在と同じく９個固定にし、CWXEditorの設定画面に、コンボボックス９個かステップの設定のステップ値のようなテーブルを置き、入力（補助）のコンボボックスはリードオンリーにし、選択アイテムは、色は表示せず(簡単に出来るようなら表示してもいい)、白:&W のように文字だけ(簡単に出来るようなら白アイコン+&W)で済ますことにします。それなら開発のコストも少なめで済みますし、色も選べます。９個同じ色にしても知りません。

---

フォント同梱のアイディアって、OSに関係なくフォントのバイナリをCWPyで読み込んで、フォントフェイスとして使えるってアイディアですよね？まさか、インストールされてないフォントだったら無理やりインストールする案じゃないですよね？ フォント同梱はスキンの方もスキンの雰囲気に合ったフォントを提供したいとかいうニーズがあったりするのでしょうか？自分は雰囲気的にこういうフォントにしてほしいというニーズがあったりしないのかなとふと思ったもので。それはあまりないのでしょうか？

[k4nagatsuki]

フォント同梱のアイディアって、OSに関係なくフォントのバイナリをCWPyで読み込んで、フォントフェイスとして使えるってアイディアですよね？

そういう事です。

シナリオ作者が演出強化にこだわってフォントフェイスを指定したい場合、

これは、インストールを求めるよりは、当該フォントで画像を作って特殊文字として表示する方が遥かに確実です。任意フォントでの表示や特殊な文字の表示は1.20以前のCWでも可能ですし、やっている人もいます。

演出にこだわるのであれば、たぶんその作者は「このフォントをインストールしてください」と書いてプレイヤーの行為というあやふやなものに期待するのではなく、そちらの方法を選ぶような気がします。当該フォントがいつまでも手に入るという保証もありませんし。

[req]

特殊文字として表示するということですね。それでコマンドで一番に対応したいのが {file:???} だったんですね？　なるほど、納得しました。

[tachi gigas]

亀レス申し訳ございません。

あと、テキストセルでの仕様の問題点ってどこにあると思いますか？一覧に上がっているように折り返しが出来ないことですか？フォント同梱されていなくてシナリオ作者が思った通りの表示が出来ないことですか？

ほぼ仰る通りですが、付記すると、CWPyはLinuxでも動くアピールをしている点でこの仕様はちょっとしんどいと思います。

[req]

CWPyはLinuxでも動くアピールをしている点でこの仕様はちょっとしんどい

なるほど。LinuxにはTakao明朝とかWindowsには入ってなさそうなフォントもある反面、Windowsで入れてそうなフォントなどはとことんないですしね。

---

ここで私の案を整理しておくと、

1. &+RGBYWOPLD以外のアルファベット１文字 に色を割り当てるという案は、Wsn.2で設定してしまおうというのを推します。そのために必要なカラーパレットカスタマイザは、イベントコンテント初期値カスタマイズと一緒にやれないかという案に変更します。
2. プチ改革案で、役割別フォントで、右クリックしてメニューが出るようにし、”全てのフォント名を統一”　のメニューアイテムを出し、その選択状態のフォント名で役割別フォント全てを埋め尽くす案を提示します。技術的には python のソース上も無理がなく、CWPyのシナリオや宿などのプレイに影響が出るわけでもなく、自分が役割別フォントを YukarryAA に染めるために、現在39個ある役割別フォントを一個一個指定する手間が省けるという、自分が欲しいだけのプチ機能です。気分的に何か他のいいフォントが有って、それに役割別フォントを染めたくなっても一個設定した後、全てのフォントに統一をすれば、39個置き換わるので、いい感じだと思います。これは無理が無さそうなので、自分のCWPyの調査用リポジトリの方で、機能を作ってみて pull request してみようかなと思っています。

---

1 の　&+RGBYWOPLD以外のアルファベット１文字 に色を割り当てるというアイディア　の色リストですが・・・、出来るといいと思っているので推しているのですが・・・、提案しておいていうのもなんですが、自分はセンスがいいとはお世辞にも言えません。そこで、良ければ誰か使えると良さそうな色リストをここで並べて叩き台を挙げてみてくれませんか？一応、色一覧とか、ブログとか見たりして、自分が出してみてもいいことはいいのですが。

---

今思ったので書いておきますが、フォント同梱のアイディアが実現したら、そのファイル参照先はシナリオだけじゃなく、エンジンにも出来るはずです。ということは、自分のようなフォントマニアのために再配布可能フォントをフルに詰め込んだCWPyフルフォントパッケージを作ることが出来ます。そうなれば、PyLiteのようなミニマムパッケージからフルフォントパッケージまでいろいろ提供できます。

[req]

全部解決とします。