安達です。 返信をありがとうございました。

On 2025/12/09 0:07, Jun Nogata via debian-users wrote:

自分が報告してたこれですかね?

#1098401 - fontconfig: Japanese font names are garbled. The font cannot be used - Debian Bug report logs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098401

フォントは違いますが、症状は同じ様子です。 私もLibreofficeでフォント選択をしてみました。こちらも同様 (ヱョポビドタ語は出てきませんが)

fontconfigの2.15.0からバグってました。

フォントの名前の書き込み方を疑っていたのですが、 fontconfigなのかもしれませんね。 fontconfigのようなソフトウェアが介在すると気がついていませんでした。 fc-list を使ってみましたら、

....yozvox-yozfont/YOzBSP90.ttf: 奏穓倹ぢ,YOzSP90b:style=䉯汤,Bold

などと出てきます。日本語表記の部分をミスっているだけで 併存している英語表記は読めているという状態な気がします。 おなじグループのフォントでも

....yozvox-yozfont/YOzRSP90.ttf: YOzSP90:style=Regular

のように文字化けしないものもありますが、こちらは日本語表記が 入っていないのかもしれません。

file コマンドでフォントファイルを調べると最後に name offset 0x98c26c などと出てくるので、hd して内部を見るとそれらしいものを 見つけられますが、ttfのフォーマットを勉強する必要があるので ちょっと止まっていました。文字コード指定もするようです。 でも、fontconfigの間違いなら、もっと手出しできないかな。

異なるフォントで同様な症状がみられるわけですが、 フォントを構成(名前をつけてパッケージするなど)する 時に同じソフトウェアを使っている可能性もあるので それと、fontconfigの依拠する文字コードの使用の解釈や許容度の変更が 合わなくなったという可能性もあるという気がします。

吉田です。 横からすみません。 LibreOffice Askからここに来ました。

Ubuntu24.04, Debian 13, OpenSUSE (fontconfig 2.16)で確認しました。

fontconfigで検索したら https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/479 パッチがあてられているようなんですが https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/429/di...

これをDebianへ適用するにはどうしたらよいのでしょうか？ -- 吉田　三郎(Saburo Yoshida) - mail:yosi3260+deb@gmail.com

fontconfigで検索したら https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/479 パッチがあてられているようなんですが https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/429/di...

よく見つけていただきました。ありがとうございます。

よく読むと 報告した Dominik Röttsches さんが ローカルの SJIS デコーダーを用意するか、(変換に失敗した)文字列をスキップ してデバッグ警告を出力するかを提案したのですが、 対応した Akira TAGOH さんは 基本的にはフォントの問題です。 名前テーブルに正しいエンコーディングIDを設定する必要があります。 と答えて(つまりはフォントの記述に問題があるとして) 後者の提案(つまりスキップして警告を出す)を採用し、 フォールバックは削除するといいます。 Dominik Röttsches さんはもう一度 今回のケースでは、Cosimoと私がフォントを確認したところ、 エンコーディングとバイトシーケンスはOpenType仕様に従って正しいようです。 といいますが、そのままクローズされています。 パッチは、「フォールバックを削除」されているようです。

問題は2つ。 (1)UTF-16BEへのフォールバックを削除するとfontconfigはどのような 結果をかえすのか不明だけれど、OpenType仕様に従ったフォントが正しく 扱われないという問題が残る。 (2)フォント側が正しく作られているのに不具合が生ずるのであれば、 backports を待って解決する問題なのかということ。

私の報告も、 エンコーディングとバイトシーケンスはOpenType仕様に従って正しい のに、UTF-16BEとして扱われて文字化けしているのではないか ということでした。 確認の様子を書きました。 https://dabiyone.com/system/a13bantrix05.html

安達です。 LibreOficeでは"IPA P明朝"や"IPA Pゴシック"も "䥐䅐䵩湣桯"や"䥐䅐䝯瑨楣"に替わってしまって使えません。 YOzフォントの日本語名の文字化けからスタートしましたが 結構広範囲に影響が及んでいます。 原因はfontconfigだと思いますが、あまり問題にされて いないようなので、修正されることは、あきらめて、 フォントの「nameオフセットテーブル」を書き換えました。 なんとか使えるようになりましたので報告いたします。 フォントの「nameオフセットテーブル」の書き方にもよりますが、 たった1バイトを変更するだけで多分大丈夫。 将来fontconfigが修正されてもそのまま使い続けられるのでは ないかと思います。 調べた環境は、Debian13で、fontconfig の version は 2.15.0-2.3 です。

ttfファイルのNameRecordに、「nameオフセットテーブル」が あります。 platformID, encodingID, languageID, nameID, length, stringOffset が並んで「nameオフセットテーブル」が作られています。 いろいろな OS、文字コード、言語 に合わせたフォント名を提供する ための仕組みですが、各メーカーの考え方、歴史もあり、複雑です。 MacintoshならplatformID=01のところを読み(今のmacが どうしているかは知らない)、WindowsならplatformID=03のところを 読めばいいのですが、Linuxのソフトであるfontconfigは両方を 読むらしいのです。 どちらか一方しか書いていないかもしれないのでこれは当然の仕様です。 問題は、macとwinで異なる名前になっていたらどちらを採用するかです。 フォント作成者は多分合わせますから問題にならないのでしょうが 今回は間違えて読めてしまった化けた名前を判別できないという困難に 陥っています。もちろん主因は「間違えた」ことです。 普通、mac用の日本語名を指定するときには、 platformID, encodingID, languageID, として 0001 (mac), 0001 (ja), 000b (ja) とします。 ここで 0001 は shift_jis でエンコードされていることを意味します。 windowの場合の普通は(最近は かな?) platformID, encodingID, languageID, として 0003 (win), 0001 (uni), 0411 (ja) とします。 ここでの0001は utf-16 でエンコードされていることを意味します。 encodingIDとlanguageIDはplatformIDにより意味が代わりますが、 同じ0001だから utf-16 にしてしまったと疑いたくなります。 フォントの中には 0001, 0000, 0411 という指定をしてあるものもありました。 macには0411はありませんので、windows用のものを間違って使ったのでしょう

nameID は01:Font Family name, 03:Unique font identifier, 04:Full font name, 06:PostScript name などたくさん有りますが 化けて問題になるのは経験的に01です。つまり platformID, encodingID, languageID, nameID 0001 (mac), 0001 (ja), 000b (ja) 01 (family) これを間違ってutf-16でデコードすることで問題がおきます。 これがなくても、大抵はwin用のものがあってそれが使われますし、 なくても、macの英語名かwinの英語名は必ずあるのでこれが使われます。 そしてこれを無きものにするには、nameID 01(family)を あまり使われていない無害なIDに代えてしまうのが簡単です。 必要なら設定するというものは、いくつかありますが 0a (Description), 13(Sample text) のどちらかがいいでしょう nameIDも2バイトなので正確には 000a, 0013 ですが、 現状は10進で25までしか使われていないので、解説の多くが 0-9までを注釈無しで使い、10から25は10進2桁で説明しています。 000a, 0013 は、10, 19 です。 19 Sample text; This can be the font name, or any other text that the designer thinks is the best sample to display the font in. とあったので、私は 0013 にしました。 調べた環境は、Debian13で、fontconfig の version は 2.15.0-2.3 です。

詳しくは https://dabiyone.com/system/a13bantrix10.html に書きました。 また、 0001 (mac), 0001 (ja), 000b (ja) 01 (family)の nameIDでなく、offsetの方を変更する方法も試しました。 うまく行きます。それはこちら。 https://dabiyone.com/system/a13bantrix09.html

私はワープロなどの作業はほとんどしません。 文字のデザインを気にするようなことはウェブページまで なので、副作用などについて気が付かないかもしれません。 なにかありましたらお教えいただけると幸いです。

安達です。

orang Aumori Jepun さん、ありがとうございます。

フォントファイルを直接いじるのは気が引けたプログラム自体を修正などの技量も無いので、ほかに方法はないかしらべたところ、詳細・経緯は省きますが、設定ファイル

/etc/fonts/local.conf を追加することでも修正できましたので報告します。

ちょうど、YOzBAF90.ttf をまだいじっていなかったので、 試してみました。うまく行くことを確認しました。 参考に書いていただいた資料を確認しても、なぜ こう書くとうまく行くのか疑問もあったので わざと色々変えて試したのですが、 多少間違えても安定しており、やり直しができるので 優れた方法だと感じました。

xmlの記述について疑問だったところと、 いろいろやってわかったところを書いておきます。 (1)YOzAF90b を一つ書いて、2箇所をYOzAF90bに書き換えているように見える これは、元々name="family"には、YOzAF90b,奏穁䘹ぢ の2つの値が格納され そのうちの"any"(どれか一つ)がYOzAF90bだったときに YOzAF90b,YOzAF90b に書き換えるという意味のようですね。 順番は、en,jaの順です。 edit内のstringをYOzAF90c,YOzAF90dの順にしてみるとわかります また、edit内のstringをYOzAF90bの一つだけにすると fc-catはYOzAF90bを一つだけ返します。familylangはen,jpのままです (2)family部分でマッチしなければ、その後のstyleもfullnameも そのままにしてtestしないで終わります。(多分次のmatchへ進むのでは?) fullnameでマッチしない場合はfullnameの部分だけeditしません。 (3)enの値は必ずあると思うので必要になる場面はないと思いますが、 化けている文字を探してそれを置換したいと発想するはず。 そこで、 <?xml version="1.0"?> を <?xml version="1.0" encoding="UTF-8"?> にしておいて、 testのstringにYOzAF90bの代わりに 奏穁䘹ぢ を入れても うまく行くことを確認しました。ただし、 editに一つだけYOzAF90bを書くと、YOzAF90bが一つだけになります。 (4)qual="any"をqual="all"にしてstringに 奏穁䘹ぢ をいれると マッチしなくなります。YOzAF90b,奏穁䘹ぢ の2つの値が格納されて いて、両方 奏穁䘹ぢ でなければマッチしないということでしょう。 (5)確認コマンド fc-cat -v | grep YOzBAF90.ttf は、ファイルのパスを省けるので良いのですが、出力が長い fc-scan -b /usr/share/fonts/truetype/yozvox-yozfont/YOzBAF90.ttf は、ファイルのフルパスを書かなければならないのが面倒かもしれません。 fc-list -vb YOzAF90b 私はこれを使っていましたが、ja,enの順で出力されます。 "奏穁䘹ぢ"(s) "YOzAF90b"(s)のうちはいいのですが、 "YOzAF90b"(s) "YOzAF90b"(s)となるとまあ、どっちでもいいとはいえ... fc-query /usr/share/fonts/truetype/yozvox-yozfont/YOzBAF90.ttf は、"YOzAF90b"(s) "奏穁䘹ぢ"(s)のままです。 cache を見に行かないのかもしれません。 (もちろんlibreofficeのCalcなどアプリでは化けなくなっています) (6)testタグ内のtarget="default"の意味は、 matchタグ内の target="scan" を引き継ぐということなのか わからないでいる。 これは、参考:に挙げられているfontconfigのユーザーマニュアルにも manコマンドでも、 https://manpages.debian.org/trixie/fontconfig-config/fonts-conf.5.en.html にもほとんど同じものがありますが、説明が不足ではっきりしません。

ちなみに、yozフォントのファイル名の意味は http://yozvox.web.fc2.com/Readme.txt をみるとなんとなくわかるような気がします。

どうやらこの後追加されているようで P,X,M の説明がなかったのです。

以上、なにかの参考・手助けになれば幸いです。

本当にありがとうございました。 たぶんfontconfigの正当な対処法だと思うのですが、 私は検索でこれにたどり着くことができませんでした。 /etc/fonts/fonts.conf には、 LOCAL CHANGES BELONG IN 'local.conf'. とありますが、このファイルはサンプルも存在してなくて <!-- Load local system customization file --> <include ignore_missing="yes">conf.d</include> の下に <include ignore_missing="yes">local.conf</include> の記述がなくなっていています。

man fonts.conf では <!-- Load local customization files, but don't complain if there aren't any --> <include ignore_missing="yes">conf.d</include> <include ignore_missing="yes">local.conf</include> となっていて、短いですが、末尾にsampleもありました。