21:49OpenTypeフォントの一部には、数字が等幅なものとプロポーショナルなものの2つを併せ持ったフォントがあります。このフォントをDXフォントデータ化したり、CreateFontToHandleでフォントハンドルを作成する時、等幅のものを使う方法はありますか?よろしくお願いします。OpenTypeフォントの一部には、数字が等幅なものとプロポーショナルなものの2つを併せ持ったフォントがあります。11:30>>管理人さんOpenTypeは商業フォントに多い規格ですが、フリーフォントでも「Inter」や「Jost*」といったフォントが1つのフォントで等幅・プロポーショナルな数字の双方に対応します。TrueTypeフォントだと1つのフォントファイルでは1つの文字につき1つの文字情報しか入れることができず、MSゴシックでは等幅・プロポーショナルで別フォントになっていますが、OpenTypeフォントでは、1つのフォントファイルで1つの文字につき2つ以上の文字情報を入れることができるため、1つのフォントファイルで等幅・プロポーショナルな数字のフォント双方に対応できます。16:34>>管理人さん数字を1文字ずつ描画して擬似的に等幅描画する方法は以前Qiitaで記事にしたのですが、別件でDXフォントファイルを使う文字列を1文字単位で分けて描画したら異常に重くなる現象がありました。02:22>>管理人さんグリフのデータを画像データに起こしているとすれば、コマンドライン引数を追加して指定した文字の文字幅が指定した1つの文字より狭い場合はその文字の文字幅と合わせることで実現できるのではないかと考えました。フォントファイルから得たグリフの画像データの文字幅が指定した1文字の文字幅より狭い場合、その文字の画像データの左右に均等に空白を付けた画像データを格納すれば実現できそうと思いますが、これまでのDXフォントファイルと構造が変わってしまう可能性があるという問題もありそうです。/L"8"」という引数を指定すると、"8"以外の数字の文字幅が"8"より狭い場合、左右に均等に空白をつけます。格納されるグリフの画像データに均等に左右に空白を作る変更のコストが低ければ、この機能の実装を要望します。17:57>>管理人さん1文字ずつ描画する方法は、フォントハンドルを使って文字数が多い文字列を描画すると異常に重くなる現象があります。フォントハンドルを使わずに描画するとこの問題は発生しません。15:33ん、GetCharBytesの使い方あってます?第二引数どこにいったのでsubstrのコストを考えるならstd::string_viewをつかう+WithLen系関数を使って長さを渡すといいと思います。18:55>>管理人さん当該プロジェクトでは、当初DXフォントデータからフォントハンドルを作成して1文字ずつ描画したところ10FPSを切るほどの異常な重さがみられ、アンチエイリアスをなくしたり、フォントサイズを小さくして対応しても改善されませんでした。ChangeFont・ChangeFontTypeで同じフォント、アンチエイリアスありに設定したところ、10FPSを切るような異常な重さはみられなくなり、60FPSで動作しました。サイズ・アンチエイリアスの有無に関係はないものと思われ、DXフォントデータから文字データを呼び出してくる処理に何らかの原因があるものと思われます。画像データ自体を操作することもコストが高そうに思えるので、難しいところです。22:43>>管理人さん実際に10FPSを切るような重さになった文字列は500文字以上あるかなり長い文字列で、数文字程度だと1文字ずつ描画しても60FPSを出すことができます。過去に擬似的に等幅化する方法を実装した時にその様子を録画した動画がありますが、10FPSを切るような重さは認められませんでした。以前数字だけ等幅化する実装を行った際、数字以外の文字が混ざると異常な描画結果となる問題が発生したということがあり、もしDXフォントファイル側が持つグリフ画像自体に最初から空白が入っていれば特に複雑な処理をせずとも数字等幅化を実現できるのではないか......と考えました。私としてはこの問題はフォントを使う側が強引に等幅化しようとしているということになるので、この問題はやむを得ないものと考えています。13:56>>管理人さんご指摘通り、プロポーショナルな数字を強引に等幅化するということは実装コストが高い割に需要が薄いかもしれません。検証を行った後、別スレッドで問題提起させていただくこととします。携帯から投稿しているため実際の検証は後ほど行いますが、取り急ぎこの話題については解決とさせていただきます。お手数をおかけして申し訳ございませんでした。(記事メンテ時に使用)クッキ。