WindowsのフォントスレッドVer.16

最近、フォント系のスレッドのクオリティが軒並み低下してるのはどうしたものか。

ttp://up2.viploader.net/pic/src/viploader294038.png
gdi32.dllのTextOutA/TextOutWをフックして、３倍にオーバーサンプリングして
から描画するようにしてみた。とりあえずそれをJaneに引っ掛けてみたけど、
どうしてもMacのソレよりはボヤけてしまうね。つまり、ヒンティングを無効にした状態と等しいからかも。
こんなんでブラウジングしたら目が疲れる。それでもWindowsの標準のレンダリングよりは全然マシだけどさ。

>>220
TextOutのフックかぁ。面白いね。
３倍オーバーサンプリングするくらいなら、
レンダラをFreeType2にしちゃうのはどうかな？

>>221
FreeType2をレンダラとして使った場合、FontLink周りがメンドクサそうだし、
パフォーマンスが出るかどうかがちょっと不安。でもそれ以前に漏れのスキルが足らなくて。

3倍で描画するときに、縦横1ピクセルずつずらして計4回の描画にしたら、
幾分マシな結果が得られた。
（濃いフォント/小さいポイントで複雑な漢字を表示させると真っ黒になるが）
どうやらOperaは全ての文字をTextOutで出力しているらしく、
Oprera.dllに引っ掛けると、ブラウザ部からUIまで見事に全てアンチエイリア
シングがかかってしまった。で、角ゴW3を使うAppleのページのスクリーンショット。
ttp://up2.viploader.net/pic/src/viploader294263.jpg
Windows標準の角ゴW3に比べたら雲泥の差。なんてったって、ふつうに「読める」。
Pentium [email protected]で動かしてるけど、とりあえずOperaならパフォーマンスは
なんとか常用に耐えるレベルで動いてる。

これをsystem32のgdi32.dllと置き換えたら･･･まるで旧MacのSmoothTypeだな。
ま、引き続き他の文字列描画関連のAPIを実装しないと実用にならないので、もう
ちょっと頑張ってみる。

pngで頼む

把握した。ページ全体のスクリーンショットを撮ってみた。
PNGで一枚1MB超えてしまうサイズので、注意して開いてください。
ttp://up2.viploader.net/pic/src/viploader294269.png
これがOS XのSafariのレンダリング結果。（iCaptureで撮影してもらってきた
ttp://up2.viploader.net/pic/src/viploader294268.png
これが今回のOperaでのレンダリング結果。（ペイントで適当に重ね合わせた

下の方が目に優しいと思うw

ttp://kasamatusan.sakura.ne.jp/cgi-bin2/src/ichi51605.zip.html
とりあえずビルドしたものを上げてみる。ソース付き。
（昨日VC++6.0を触り始めたばかりだからかなり怪しいが）
詳しい説明はreadme.txtに書いておいたけど、かなりぁゃιぃ代物なので人柱さん専用。

早速、Operaに使ってみた。
小さなフォントも見易くなった…ように感じる。

Javaとクッキー切ってたら赤ん坊に怒られた。

いけねぇ、肝心のお礼が・・・。

>>226
有難く頂戴しました。

このスレを思い出した
http://pc8.2ch.net/test/read.cgi/win/1038101090/

>226
すっげえ…… GJ！

ヱロゲのAVG3216M.EXEに仕掛けてみた。感動した。

>>226
SMP_AAみたいな普通に濃いフォントだと、↓こうなりますw
ttp://kunekune.breeze.jp/up/uploader/src/up1972.png

>>232
ﾜﾛﾀｗ

元に戻すと明らかに体感速度向上しますた。
システム全体に適用する勇気はありませんです…。

いろいろ試してみました
表示位置がズレてしまってうまくいかないことが多かったです

>>232
現在はずらして4回描画してるので、いちばん濃い状態です。
2回描画ならもうちょっと薄くなるし、濃い目のフォントなら1回でもいいかもしれない。
レジストリもしくはINIファイルで変更できるようにしておいたほうがいいかもね。
>>234
適用して動くかどうかも分からないから･･･試すときは仮想マシン上で。
速度的に最もキモになる縮小部分のコードが現状ではかなり生ぬるいかもしれません。
コンパイラもVC++6.0だし、グローバル変数に格納されたLUTにアクセスしてるから。
もっと最適化できればいいんだけど･･･。

ずらして四回じゃなくて
重ねて四回のほうがいいんじゃないか

>>235
単純にフォントサイズを3倍したとき、表示領域も元の三倍になるわけではないからね。
おそらくGetTextExtentPoint32あたりをもっとマトモな数字を返すようにしないと
いけなくて、ソースには書きかけで残ってるんだけど、Janeで試したら思ったような
結果にはならなかったんだよなぁ。何故だろう。

MSGOTHICがMeiryoより奇麗に出たら教えてくれ。

今、一度3倍で書いてるってことは、横方向の縮小を行わずに、液晶のサブピクセルに
そのまま当てはめればClearTypeもどきが実装できる予感。ただし、そうなると今度こそ
アルファブレンドをしなきゃいけないのが面倒だ。

PDFのレンダリングはきれいだと聞くが、これも別DLLか何かでラスタライズしてるのかな

>>241
CoolType

ttp://ja.wikipedia.org/wiki/ClearType
これを参考にして、ClearTypeモドキを簡単に実験してみた。
（赤チャネルを左に、青チャネルを右に1ピクセルずらしてから縮小）
･･･>>224と比較しても、あまり変わった気がしないぜ？
ttp://up2.viploader.net/pic/src/viploader295440.png

RGBが逆。

>>243
>>224の下のと並べて比較すると、
「あれ、目が悪くなったのかな？」って感じがします。

>>244
うわぁ･･･ホントだ('A`)�dｸｽ
ttp://up2.viploader.net/pic/src/viploader295469.png
一転して、だいぶ良くなった希ガス。

だが、それなら標準AAの方がマシ

>>246
RGBの並びをどっちにするかはClearTypeでも選択できるので
設定項目を付けておいた方がいい。

WinのClearTypeを使うより>>246の方がきれい、ってこと？
MeiryoみたいなClearType用のフォントでも>>224下できれいに出るの？

いや
なかなかいいんじゃない？
CoolTypeに近づいた感じ

これで本家ClearTypeより軽くなったらすげーですね。

ttp://kasamatusan.sakura.ne.jp/cgi-bin2/src/ichi51831.zip.html
ええと、今回から設定ファイルで文字の濃さを調節できるようになってます。
デフォルトではオフになっていますが、ClearTypeモドキもオンにできます。
ただしちょっと表示がバグるので注意。詳しくはreadme.txt参照。
文字表示のトロさは相変わらずです。

うげ、gdi++.iniを添付し忘れた。別に無くても動くけど、
↓の内容で保存して使ってください。パラメタの説明はreadmeに。
[General]
Weight=0
UseSubPixel=0
SubPixelDirection=0

>>252-253　乙！　今、試せないけど頂いた。　

>>252
Thanks!!!!!!
マジちょーーーーーーーーーーーーーキレイ！！！！

Firefoxじゃ使えないみたいだけど・・・orz

Janeでテストちう。
ClearType切って、UseSubPixelをやるとClearTypeと同様の効果が得られますた。
スレビュー部だけだから、他の部分はだめだこりゃだけど…。

いい感じなのでIEでテスツしてみたいけど、
どこを弄ればいいのか解らんです…。orz

A,B,CのTTFフォントを用意します。（合成にはMAKETTC.EXE使用）

1　A,B,Cのそれぞれのフォント名をttfneme3で先に書き換え、合成したTTCフォント=D

2　A,B,Cを先に合成し、ttfname3でフォント名を書き換えたTTCフォント=D'


こうしてできたDとD'のMD5が相違し、またDの方はなぜか10バイト小さいです。
これは一体どちらが正しいのでしょうか？


私を悩ませるのは、
DとD'をBreakTTC.exeで分解してできた6個のTTFフォントをそれぞれ比較すると
MD5が一致してしまうことです。

また、DとD'をttfname3にD&Dして出来るXMLファイルも、一字違わず同一の物です。

>>252
綺麗だ。
http://www.imgup.org/iup258591.png

>>257
Dは makettcで合体したTTC
D'は ttfname3で合体したTTC
と考える。
（ttfname3は 内部でTTFに分解、合体してる）

生成するTTCヘッダー部分が少し違うから ファイルサイズが変わる。
TTCヘッダーが違うだけだから、breakttcすると全く同じTTFが出来る。

まぁ、あまり細かい事を悩まないほうが良いぞｗ

中途半端な知識で持って無くて，頓珍漢な質問だったら申し訳ないんだけど，
TextOutじゃなくてExtTextOutを使っているプログラムには意味ない？

>>256
一応ClearType切らなくても、たぶんレンダリング結果は変わらないと思う。
IEのメインはIEFRAME.DLLかな。最悪、Dependency WalkerでIEが使うDLLを調べて、
それらを全部同じディレクトリにコピーして書き換えれば動くかな･･･わからない。
ちなみに、いちいちファイルを直接書き換えずに、一気に全プロセスをフックできる方法が
あるらしく、ちょっと調査中です。（APIHijackってヤツですが）
>>260
今実装してあるのは、とりあえずTextOutだけですね･･･ExtTextOutを呼ぶと
残念ながらそのままオリジナルのGDI32.DLLにスルーされてしまいます。
（ちなみにExtTextOutはTextOutよりも描画が速いらしい）
で、残り、実装すべき関数は
　GDI32: ExtTextOut, TabbedTextOut, PolyTextOut
　USER32: DrawText, DrawTextEx
あたり。どうやらGrayStringはMSDNにTextOutを呼ぶって書いてあるし、
無視できそうな予感。どの関数でも、最初にどのくらいのサイズで描かれ
るかが計算できれば、後はだいたい同じ処理になるでしょう。

>>259
なるほど！
ヘッダが違うだけで中身一緒なんですね。
確かにバイナリエディタで見たら少しだけ違ってました。
D'の方が自分的に作業が楽だったので
これからは気にせずやろうと思います。
どうもありがとうございました。

>>258
このフォントなんだっけ。

IEFRAME.DLLがうちのシステムにはありませんでしたw

>>263
多分Noel

>>263
Noel

>>264-265
なるほど、�d

>>261
素早いレスありがとう．
テキスト描画の方法って結構あるんですね．
大変かもしれないけど頑張ってください．
積極的に人柱やりますので．

>>261
> ExtTextOutを呼ぶと
> 残念ながらそのままオリジナルのGDI32.DLLにスルーされてしまいます。
Firefoxで効果がないのはそのせいだな
>>262
蛇足だが、A,B,CがBreakTTCで分解された元は1つのフォントとかでない限り、
合成する意味は全くない。

http://download.microsoft.com/download/0/c/2/0c26cfda-1385-4344-b608-d98a3deed6a4/IE7BETA3-WindowsXP-x86-jpn.exe

>>268
MeiryoKEをMeiryoKe_ゴシック、MeiryoKe_Pゴシック、MeriyoKe_UIゴシックに分解して
MeiryoPゴシックだけMeiryoModAAに入れ替え、
ttfname3でフォント名をMS標準に書き換えてから合成しました。

MSGothic.ttcを入れ替えるための方法だったのですが
フォントリンクとか使った方がスマートだったかもしれませんね。

gdi++をoperaで使おうとしたけどうまくいかなかった
まったく表示が変わらない
gdi++.dllを削除すると起動時にエラーが出るから、一応組み込まれてるっぽいんだがわけわからん

そもそも、うちの環境ではoperaは普通にインスコしても日本語フォントの表示が異常
一部分だけビットマップになったり、日本語じゃない漢字・かなで表示されたりとめちゃくちゃ
結局operaはアンインスコしました
>>258みたいな表示をWindowsで見たかったんだけどな〜

あと、gdi32.dllを置き換えるってのをやってみました
見事に起動しなくなりました
ありがとうございました

>>271
> 普通にインスコしても日本語フォントの表示が異常
それはgdi++適用時？
もしそうなら，gdi32のバージョン合ってる？

ところで，
> gdi++をoperaで使おうとしたけどうまくいかなかった
> まったく表示が変わらない
だけど，たまたま自分が使用していたバイナリエディタは，
文字列検索だと強制的に大文字と小文字の区別がされる仕様
で，"gdi32.dll"を書き換えただけじゃダメだった．
"GDI32.DLL"も書き換えたら動いたよ．

まったく検討違いだったら申し訳．

安定性とパフォーマンスの両立は大変だろうけど、期待してます＞作者さん

http://www.imgup.org/iup258691.png.html
ところでコレって環境依存なのかしら
この現象が出た人居ますか？

>>274
うちもでるよ

だが、それならFreeTypeの方がマシ

>>272
うまくいったみたい。ありがとね
ttp://www.imgup.org/iup258711.png

>>274
うちもなる

>>277
そのひらがなとカタカナのフォントなんて奴？

>>126
Arial Narrow と MS　Pゴシック が良いかな。

フォントリンクだとエクセルで使えないけど。
自分だけ奇麗で良ければメイリオに置き換える。

>>274
Opera上ではないので違う現象なのかもしれないが、再現できた。

・UseSubPixel=1 のときに出る。
・SubPixelDirection の値で出かたが違う。
・SubPixelDirection=0 のとき、左に青・右に黄色。=1だと逆。
・フォントの色を変えたときに出る。何度も同じところで繰り返すと、どんどん濃くなる。

>>278
DFぽぽる（のビットマップ抜き）だな

>>281
> （のビットマップ抜き）
gdi++使ってると3倍に拡大してから縮小描画してるから
3倍サイズのビットマップを持ってない限りビットマップはもともと表示されないはず

じゃMSゴシックでもビットマップ無しって事か。
手元に無いので試せないけど。

おーなるほど

XPのCDからMSGOTHIC.TTCを引っ張り出してきて、テストしますた。
ttp://kunekune.breeze.jp/up/uploader/src/up2160.png

普通に綺麗なんですけどw
そもそもWinのデフォのフォントが汚いってのが、
フォント界隈が盛り上がる出発点なだけに、
ちょっと感慨深いもんが。

>>285
どうみてもMSゴシックに見えないｗ
レンダリングエンジンが一番の問題で、
フォントをどうこうしても対処療法でしかないってのがよくわかったわｗ

>>285
マジだ。すげぇ。

MS ゴシックは印刷したりすればちゃんとしたフォントだからな

>>288
腐っても字体は、本明朝だしな。

ちと太過ぎな気が。

>>289
( ﾟдﾟ )

バイナリエディタでexe開いてもやり方分からなすorz

>>291
本明朝が字体なのは、MS明朝ですたorz
MSゴシは、何だったけ？

>>292
gdi32.dllって文字を探して
gdi++.dllって書き換えるだけ

MSゴシに回帰する人が増えるかもw
当たり前だけどAA対応だし。ただ、ちょっとｽﾞﾚﾙ(あまり気にならない程度)

16進数が2文字ずつ並んでるだけなんだけど。
stirlingてエディタ。

>>293
普通に「RFゴシック」。

>>297
ども

>>290
ビットマップに比べてアウトラインは元々太い。
http://khdd.net/kanou/kangae/2004/Dec.html#1.2.2
だからMS ゴシックからビットマップ抜きフォントを作成する場合は
通常細線化フィルタを掛ける。

>>296
それ、なぜか時々落ちるんだよな…。
自分はフォントをいじっているわけではないのでスレ違いだけど。

>>290,298,299
MSゴシックの元になったリョービのゴシックEが
見出し用の太さだから。

>>299
かなり関係ないけど、gdi++使用のOperaでそのページを見たら、すごく綺麗なので驚いた。

ttp://pc.gban.jp/?p=5712.png

x86のアセンブラをゼロから勉強して、付け焼刃の最適化に挑戦中。
それにしてもFlashのラスタライザって、軽量すぎるぜ？
>>274
うちもなるなる（ぉ
>>280
�dｸｽ。本来のサイズよりも、左右1ピクセルずつ余計にDCからコピーしてくれば
改善するかも･･･しれない。あくまで「簡易」なので横着な実装ですが。
>>282
Windowsではコモンダイアログの中で最小で7ptまで選べるようになってるけど
（ただし直接指定すればそれ以下のポイントでも表示できる）、その場合でも
7 x 3 = 21pt なんて特大ビットマップを持ってるフォントなんてまずないから、
3倍で描画すれば、全てのフォントでアンチエイリアシングが掛かる計算です。
本当は2倍の方が都合はいいんだけど、そこらへんの問題があるので、3倍なのです。
>>299
そのページのAAの考察、なかなか鋭いね。