🕒 この記事を読むのに必要な時間 🕒
全文：おおよそ30分
要約のみ：3 〜 5分 😃お薦め！
📜 必要な知識 📜
Linuxコマンドライン操作: 初級以上
Windows レジストリ知識： 初級以上
💻 実行環境 💻
OS: Arch Linux x86_64
Kernel: 6.12.10-arch1-1
Shell: bash 5.2.37
DE: Xfce 4.20
WM: Xfwm4
Terminal: xfce4-terminal
Package: wine 10.0-1, サクラエディタ ver.2.3.0.1改
■ 問題の概要
2024 に Arch Linux システム全体をアップグレードしてから、 Wine 上で動作する俺ちゃん改造版の サクラエディタ がフォントが滲むという症状が出ていた。
Qiita 上では画像を加工してから保存・表示しているらしく、実際とは少しぼやけ具合が異なっています。画像をタップして単体表示させると多少本当の状態に近くなるようです。
このように パネルの常駐アイコンを右クリックした時, メニュー, 本文 すべてが汚くにじんでしまっている。ぼやけたような表示だ。
見づらいことこの上ないが、いちおう動作には支障はない。
あと、あまり サクラエディタ を使わなかったので Fix する気にならなかった。アップグレードによってなんらかの不具合が生じた可能性が高く、しばらくしたら更にアップグレードされて解決するだろう、と思って放置していた。
...が、半年ほど経ってもまったく同じ状況で、一向に改善されたりしなかったので重い腰を上げて見てみることにした。
■ TL;DR 結論の要約から先に述べる
原因は wine ver.9.17 での DPI 設定周りの仕様変更だった。
winecfg で設定できる「画面の解像度」を 96 dpi 以外にしているときのみ、それも特定のアプリケーションでのみ起きる現象らしい。「特定の」とは、具体的には 高DPIを認識しないアプリケーションのこと。
※ サクラエディタは v2.4.0-alpha1 (2019-03-27) で 高DPI対応しているので、それ以降のバージョンであれば下記を行わなくとも正常に表示されると思われる。ただし、正しいマニュフェストファイルの記載、配置などは必要かもしれない。
これを強制的に認識するように設定することができる。例えば、単純に全体で一括して認識させるには以下のようにコマンドを実行する。
$ wine REG.exe ADD "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F
一応解説してみると、これはレジストリと呼ばれる Windows の 詳細設定/隠し設定 等を設定するコマンドである。wine でも Windows との互換性のため、この仕組みと全く同じような仕様のものがあり、それを追加しているのが上記のコマンド。
レジストリーキーを、
"HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"
でパス追加して文字列型（REG_SZ）のデータを用意し、その値を "~ HIGHDPIAWARE" に設定している。1
Windows を使いこなしていたユーザーならレジストリをいじった経験のある人は多いだろう。それと基本的に変わらない。
$ wine REG.exe ADD /?
でヘルプを見ることができる。また、
$ wine regedit
で Windows 風のレジストリエディタを起動できるので、わかっている人なら上記したコマンドの代わりに手動操作で追加しても良い。
特定のアプリケーションだけを設定したい場合は、上記コマンドの代わりに以下のようにすればいいと思う。（注意：俺ちゃん未検証）
$ wine REG.exe ADD "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F /V "C:\FreeWares\sakura\sakura.exe"
※ サクラエディタを C:¥FreeWares¥sakura¥sakura.exe にインストールしている場合。適宜各々の環境に応じて変更すること。
違いは最後に /V ＜サクラエディタの実行ファイルのパス＞ 部分が加わっているところ。
以下は経緯を含めた詳細ログ。長い。読まなくていい。
■ 設定の問題なんじゃない？
Wine は winecfg というコマンドを使って基本的な設定が変更できる。
これらは ~/.wine 以下に保存され、 Wine がアップグレードされた際には設定内容に新旧で齟齬が起きないように設定ファイル群もアップグレードが行われる。
しかし、これが失敗したりすることがあるようだ。
確か 2024春頃にアップグレードした際にも不具合が起きた。
このときは wine 自体が起動しなくなってしまったのだが、俺ちゃんの環境に依るところも大きかったので wine の不具合ともいえないところがあるが...。
まあ、こういった形でなんらかの設定内容が壊れてしまった可能性は捨てきれない。そこで winecfg の設定をあれこれ変えて、直らないか試してみたところ...
[画面] ＞ [画面の解像度] を 144 dpi --> 96 dpi にしてみたら、解決した。
よく覚えていないが、「Wine の画面は小さくて見難いな〜」と思って、なんとかならないかなと winecfg をいじっていたら、解像度を上げれば wincfg も含めてスケールがすべて大きくなったので「やったー♡」となった気がする。...確か。
...これがよろしくなかったのか。
しかし、上記設定を変更した直後はちゃんときれいに表示できていた気もする。じゃないと使い続けるわけない。
あと 96 dpi にすれば確かにフォントはスッキリ綺麗になるが、画面が小さすぎて見難い問題が再浮上してくる。
■ いろいろ試してみる→ダメだ〜
日本語でネットを検索してみると、 winetrick cjkfonts を使ってみろとか、 wine regedit でフォントを修正してみろとかいう記事が目に入ったので片っ端から試してみるが、どれも効果はなかった。残念ながら、解像度を 144 dpi にしたままでフォントが綺麗になることはなかった。
■ 同じ状況の人はいないの？
いた。
日本では居なかったが、公式サイトのフォーラムで見つけた。
以下で報告されているのと全く同じ状況。
どうやら ver. 9.17 で仕込まれた仕様変更？ らしい。
"Window surface scaling on High DPI displays." ってやつ。
現在の俺ちゃんの只今の Wine のバージョンは wine-9.22 である。
発症時期は正確には忘れてしまったのだが、ver.9.17 なら時期的にも一致する気がする。
この改修で行われたことを要約すると、
ver.9.16 以前は先述の DPI 値を変更しても、フォントのサイズを調整するだけで実際にディスプレイやウィンドウ、あるいはその描画領域（いわゆる Windowsで言うところの DC, デバイス・コンテキストのようなもの）にある DPI を変更するわけではない、いわば "なんちゃってスケーリング" 実装だった。これを ver.9.17 でちゃんとウィンドウ内の描画領域のスケールが上がるように改善した、ということみたい。
だが、スケールアップの際に用いる補間方法がいまいちであるため、上記の人が使っている Tone Stack Calculator とかいうソフトや、俺ちゃん改造版のサクラエディタではそれが裏目に出てしまっている… ということのようだ。
…が、この記事でも解決はしていなかったので結局参考にはならなかった。
■ 最新版の wine にアップグレードしてみる→変わらない。。
そうこうしているうちに wine-10.0-1 が出ていたので、アップグレードしてみた。が、やはり何も変わらず。
しかし設定を更新するダイアログが出てきて、その後以下のような警告画面が出た。
wine-mono が見つからなかったという。は？
しかし、本当は以下のように入っている。
$ pacman -Ss wine
extra/twine 6.0.1-2
Collection of utilities for interacting with PyPI
extra/vkd3d 1.14-1
Direct3D 12 to Vulkan translation library By WineHQ
extra/wine-gecko 2.47.4-2 [インストール済み]
Wine's built-in replacement for Microsoft's Internet Explorer
multilib/lib32-vkd3d 1.14-1
Direct3D 12 to Vulkan translation library By WineHQ
multilib/wine 10.0-1 [インストール済み]
A compatibility layer for running Windows programs
multilib/wine-mono 9.3.0-1 [インストール済み]
Wine's built-in replacement for Microsoft's .NET Framework
multilib/wine-nine 0.10-1
Gallium Nine Standalone
multilib/wine-staging 10.0-1
A compatibility layer for running Windows programs - Staging branch
multilib/winetricks 20250102-1 [インストール済み]
Script to install various redistributable runtime libraries in Wine.
$
どうゆうこと？？
ディストリビューション提供のパッケージだ。互換性の問題なのだろうか？破損している可能性もなくはないので、
$ sudo pacman -S wine-mono
して再インストールしてみたら普通に動いた。
が、
ちょっと調べてみたところ この wine-mono ってパッケージは .NET Framework 実装のオープンソースによる代替実装であるそうだ。もともとは .NET Framework を Windows 以外の OS でも流行らそうと考えた Microsoft が制作していたもので、現在は Wine の公式開発者たちに寄贈され、真のオープンソースとなっているということらしい。
余談だが、MONO 自体は Microsoft に買収される前の Xamarin が先導していたものでマルチデバイス動作する共通コードを掲げた Xamarin 等の内部技術であったらしい。
なお、後でわかったが、上記のエラーメッセージはやはりバージョンの互換性の問題ということらしく、「Wine のこのバージョンにはこのバージョンの wine-mono が要る」というようにかなりガチガチに紐づけられてしまっているみたい。oops!
ダイアログに表示されている下記 URL に対応表が書いてあった。
wine 10.0rc1 に対応するのは wine-mono 9.4.0 だが、 9.3.0 だったので怒られたということだ。 ver.9.4.0 は後日めでたく Arch Linux リポジトリにも出たのでアップグレードしておいた。
ちなみに、
サクラエディタは .NET Framework は必要としないのでなくても動くのだが。
■ アプローチを変えてみる
どうも DPI を大きくしたままで、解決するのは無理っぽい...。
dpi=120 などでもフォントが滲む。 dpi=96 以外ではちゃんと表示されない。
ただし、 notepad, winecfg などは DPI を大きくしてもちゃんとフォント表示が崩れずに表示されているので、何らかの条件があるっぽい。
デフォルトで入っている機能の中でもフォントが滲むものもある。 wine control で表示されるコントロールパネルの 「プログラムの追加と削除」 ダイアログだ。 dpi=144 にしたときはフォントがぼやけたように滲む症状が出てしまう。
いったい何がトリガーなのか、よくわからないが…。
先に述べた ver.9.17 以前にダウングレードしてみる、という手もあるがなるべくならそれはやりたくはない。バージョンを固定してしまうと、今後アップグレードできなくなってしまうからだ。
ってことで、
解像度ではなく、メニューなどのフォント全般を大きくするという逃げに走ることに。
wincfg を起動して、
[デスクトップ統合] ＞ [項目(E)]
の選択を変更してみて、右の [フォント(F)...] が押せるようになる項目を出す。そしてそれらのフォントサイズを片っ端から変える。
8 のものは 10 に。10 のものは 12 に変えてみた。
これで、
$ wine start "C:\FreeWares\sakura\sakura.exe"
で起動させてみると、まあ大体うまくいった。
【余談】
なお、winecfg でチクチク手動編集するのが面倒なら ~/.wine/user.reg を編集することでも変更できる。…ただし、DWORD 型なので 16進数値を編集する必要があるが。 "MenuFonts" などの値がそれに当たる。このやり方は 16進数値がわかるバイナリアンだけが挑戦できるだろう。おすすめはしない。
肝心のテキスト本文の方は サクラエディタ 自体の設定画面でフォントサイズを変更する必要がある。メニューから、 [設定(O)] ＞ [フォント設定(F)] で起動したダイアログで設定できる。
ここでは、ちゃんと使いたいフォント名に変更しておくこと。
これで以下のような画面になった。
Qiita 上では画像を加工してから保存・表示しているらしく、少しぼやけ具合が残っていますが本来はスッキリ綺麗に見えています。
画面下のステータスバーと画面上の方のタブバーの表示が小さいままなのがちょっと残念ではあるが…。あとアイコンが小さくて押しにくいが…。
まあ許容範囲内としておく。
■ DPI を変更してもにじまない方法があった！
一応の解決はした。…しかし、なんとなく腑に落ちない。
ステータスバーなど一部が見づらいのは変わらないからだ。特によく使うアウトライン解析機能のフォントが小さくて見づらいのは、いかんとも納得しがたい…。
そこで更にネットを探してみると、以下のバグ起票が見つかった。
ちなみにサイト名に WineHQ と謎の "HQ" がついているのが気になっていたが、これは Wine の公式サイトで使われるもので "Head Quarters" の略らしい。つまり「本部」。
昔、1990年代後半〜2000年代初頭頃にはやった IRC（Internet Relay Chat) などで使われていた名残なのだとか。…そんな頃からあんのね。。
公式 Webサイトやサポートで使われる呼称であって、ソフトウェアとしての Wine の名前ではないらしい。よく間違えて "WineHQ" がアプリケーションの正式名称みたいに扱っている日本語のサイトがあるようだけども。おいおいJAP...!! 、と思う。
…というのは置いといて。
話が脱線したので元に戻すと。
上述のサイトでは、これがバグか否か、スケーリングの補間アルゴリズムや改善案について熱く討論が交わされており、実に興味深かった。
重要と思われる部分のみ、抜粋して解説してみよう。（Google日本語翻訳で変換）
` レミ・ベルノン氏 2024-09-10 19:12:01 UTC
DPI 認識はアプリケーションに依存するようになり、システム DPI またはモニタ
ーごとの DPI を認識する一部のアプリケーションは、元のスケーリング動作を維
持するようになります。DPI を認識しないアプリケーションは、バイリニアアップ
スケールによって構成されたシステム DPI にスケーリングされます。
これは Windows の動作と似ていますが、まだ実装されていないより高度なスケー
リング オプションがある可能性があります。また、レジストリ設定を追加して、
すべてのアプリケーションで古い動作を強制するオプションを提供することもでき
ますが、これは Windows の動作ではなく、他のアプリケーションに支障をきたす
可能性があります。
`
つまり、俺ちゃんのサクラエディタは DPI を認識しないのだろう。2
そのためバイリニア法によって補間されてしまい、滲んだような不自然なフォントの描画となってしまっているようだ。
これは Windows で [Windowsの設定] > [システム] > [ディスプレイ] にある設定項目「拡大縮小とレイアウト」のスケール設定の動作と似ているが、スケーリングに関しては（別の補間技法を用いるなど）改善の余地もあるということのようだ。
そしてレジストリを設定することで、全アプリケーションで昔の動作と同じように強制するオプションはできなくはないらしい。
次の発言も気になる。
` レミ・ベルノン氏 2024-09-16 08:55:25 UTC
https://gitlab.winehq.org/wine/wine/-/merge_requests/6499 はおそ
らく近似しており役立つはずです。
ちなみに、Windows で Audacity をチェックしましたが、スケーリングを使用する
と Wine とまったく同じ動作で、同じようにぼやけます。これはアプリケーション
が実装する必要があるもので、システム DPI 認識をアドバタイズする実行可能マ
ニフェストを追加するだけで済む可能性があり Wine で修正できるものではありま
せん。
確かに、理論的にはよりスマートなアップスケール フィルターを実装することは
可能ですが、それには特定のコードが必要であり、それが価値があるかどうかはま
だわかりません。また、別の方法で実行できる可能性もあります。
`
これを読んで思い出したのだが、俺ちゃんの改造版サクラエディタは 32ビット版だ。自分の都合で勝手に改造したバージョンなんで長らくアップデートしておらず、64ビット版ではないのだった…。
このため、64ビット版 Windows に移行した際に、今回と同じようにフォントなどがぼやけるという症状が出て、対応させるためにマニュフェストファイルをでっち上げたりレジストリをいじったりゴニョゴニョとしような…。
確か sakura.exe.manifest を %AppData% だか %LocalAppData% に置いたような…。そういえば Wine ではそれを行ってないような…。
そんな記憶がうっすらと思い出された。（細い目）
…ということはですよ！
マニュフェストファイルやレジストリをちゃんとすればイケるのかな？？
…っていうか、
64ビット版バイナリならこんな苦労しなくても綺麗に表示されるのかも。。
【後日追記】
しかし正しいと思われる場所 %LocalAppData%\sakura\ へ マニュフェスト・ファイルを追加してみたものの、改善されなかった…。64ビット版に関しては試していない。
さらに、次の発言も気になった。
` MarcinZw氏 2024-09-25 16:32:12 UTC
残念ながら、この変更にも問題があります。高 DPI 設定のアプリケーションは、
https://windjview.sourceforge.io/en を使用すると、スクロールのパフォーマン
スがひどくなりますが、標準の 96 DPI で提案されたパッチを適用すると、かなり
高速になります。整数アップスケーリングも、バイリニア アップスケーリングの
ように速度が低下しない限り、優れた追加機能です...
`
ぼやけるだけではなくて、遅いらしい。
おいおい…。
` レミ・ベルノン氏 2024-10-04 09:00:25 UTC
6f44677c5fbc6b9677a72e27b8cb0a6e494dfad6 以降、
<https://ss64.com/nt/syntax-compatibility.html> に記載されているように、
AppCompatFlags レジストリ設定がサポートされるようになりました。
この設定は、ユーザーごと (HKEY_CURRENT_USER\Software\Microsoft\Windows NT
\CurrentVersion\AppCompatFlags\Layers) またはグローバル(HKEY_LOCAL_MACHINE
\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers) に設
定できます。
その後、個々のアプリケーションに対して設定したり (レジストリ エントリの値
としてアプリケーション パスを使用)、グローバルに設定したり (キーに既定の
レジストリ値 '@' を使用) できます。
データを DPIUNAWARE または HIGHDPIAWARE に設定して、アプリケーションの DPI
認識をそれぞれ強制的にオフまたはオンにすることができます。
`
おお！
それだ！！
なんか AppCompatFlags って聞き覚えがある！
たぶん、俺ちゃんがその昔 64ビット版 Windows に移行した際にもそれを設定したような記憶があるぞ。たぶんだけど。
これは Windows の GUI 項目で言えば「互換モードでこのプログラムを実行する」って奴らしい。 HIGHDPIAWARE にすれば ON にできるようだ。
このあとの会話でこれを追加するコマンドラインが示唆されるが、レミ・ベルノン氏の提示したものより後の MarcinZw氏の提示したもののほうが動作するようだ。以下を実行してから wine control を使ってみると、ぼやけが解消され、見事表示されるようになった！
$ wine REG.exe ADD "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F
サクラエディタもちゃんと表示される。
アウトライン解析も問題なし。
注意点としては、このままだと、全体設定となってしまうので もしも 他にもアプリケーションを使っており、そちらはちゃんと動いていた という場合には注意が必要だ。このレジストリエントリを加えたことによって 逆に不具合を起こす可能性がある からだ。
アプリケーションごとに設定するにはレジストリの値としてアプリケーション・パスを設定すれば良いらしい。
しかし、俺ちゃんはサクラエディタと LINE くらいしか、ほぼほぼ 使っていないからどうでもいい。
最後に、以下の発言も非常に参考になった。
` MarcinZw 2024-10-08 10:07:56 UTC
ありがとうございます。私の場合はうまくいきました。その間、Windows が高 DPI
設定をどのように処理するかを調べました。Windows はインターフェイスをアップ
スケールするだけでウィンドウ全体をアップスケールするわけではないようです。
ツールバーとメニューのみがアップスケールされ、プログラムによってレンダリン
グされるコンテンツは影響を受けません。たとえば、WinDjView では、インターフ
ェイスはアップスケールされますが、表示される本はアップスケールされません。
これが、Windows 仮想マシンでも 96 DPI または DPI 対応オプションが有効にな
っている Linux と同じ速度でスクロールできる理由です。
`
これは Windows ではフォームやボタン、メニューといったコントロールの描画のみがアップスケールする挙動だということなのだろう。なるほろ。
以上。
-
一段上の男を目指す人、ちゃんとわかりたい人向けのもう少し詳しい説明: ここでの肝は "AppCompatFlags" という部分である。
簡潔に言えば このフラグは特定のアプリケーションについて、 Windows の過去のバージョンと互換性を制御するために存在する。例えば最新の Windows 11 で実行しているマシンで Vista, 7, 8, 10 などの昔の Windows 向けに作られたプログラムを実行したい時、それらが想定している昔の Windows と Windows 11 ではいささか実装や動作が異なる部分があるため、それが問題となり不具合を起こしてしまうことがある。そんなとき、この AppCompatFlags を調整してやることによってそれらを軽減できる。
代表的なものが指定のバージョンの Windows と互換性のあるモードで実行するように指定するデータ値である。VISTASP2, WIN7RTM, WIN8RTM などがある。 GUI 項目で言えばプロパティの「互換モードでこのプログラムを実行する」だ。さて、
今回追加するデータ値 "HIGHDPIAWARE" についてだが、これは GUI で言えば「高 DPI設定では画面のスケーリングを無効にする」に該当する。
現代の高性能なディスプレイでは解像度が大きいため、より詳細で綺麗な画面を表示することができる。これは言い換えると、DPI が増加しているとも言え、 1 インチに含まれるドット数が増しているということだ。しかし、それは同時に従来の基準では普通であった大きさの画面内容（例えば写真など）でも、高 DPI なディスプレイ上では小さく映ってしまうという欠点がある。これを解消するため Windows は「見た目上の画面内容の大きさを何倍かに上げる（画面スケーリングまたはアップスケールなどと呼ばれる）」という方法で対処している。が、今回のようなケースではこの実装が災いしてしまってピンボケたような文字になってしまっているということだった。 ↩ -
DPI認識: これは 高DPIディスプレイ対応、または 高DPI対応 などと省略して呼ばれる事が多い。Microsoft 公式情報、サクラエディタの 高DPI対応時の Issue ログについては以下のページを参照のこと。
【参考】Windows での高 DPI デスクトップ アプリケーションの開発 - Win32 apps _ Microsoft Learn
【参考】HighDPI対応 · Issue #471 · sakura-editor_sakura
サクラエディタは v2.4.0-alpha1 (2019-03-27) で対応されているようだ。 ↩