解決したバグ
/
修正パッチ＆モジュール
/
Vine 2.5,2.6 の危険性に関して
/
各ディストリ対応状況
[現在、移転作業中です]
日本でもオープンソースを積極的に導入する動きがある中，
あいかわらず XFree86-4 + xtt は不安定な状態でしたが，
Vine ユーザのいくつかの貴重な報告をもとにバグ修正をおこなった結果，
X-TT(on XFree86-4) は大変安定して動作するようになりました．
4.3.0 以前の XFree86-4 で xtt モジュールを使う場合，
このサイトのパッチ適用は必須です．
XFree86-4.2.x + xtt モジュール利用時の
以下の 6 つの問題についてバグ fix を
行ないました．このページで，修正パッチと修正モジュールを公開しています．
このページで公開している xtt へのバグ修正パッチが XFree86 の tree に
マージされました
(このページのすべての修正パッチが XFree86-4.3.0 に反映されています)．
なお，X-TT が原因と思われる X のクラッシュを発見された場合，
ただちに
私までご連絡ください．
全力でバグ修正を行います．
XTT / X-TT / X-TrueType / XFree86 /
落ちる / クラッシュ / 不安定 / SEGV /
ゴミ / Xサーバ / 大きなフォント / でかいフォント / Vine2.6
■最新情報�■
AutoItalic 使用時にも、Embedded Bitmap が使えるようになりました。
アウトライン(従来)
Embedded Bitmap
■改良工事■
-
【A】TTCap 拡張(2003年3月5日〜)
jisx0208 や iso10646(unicode)
なプロポーショナルフォントの展開速度を改善したり，
bold 体生成を拡張する
TTCap の追加作業をおこなっています．
バグレポート等，歓迎いたします(連絡先)．
-
◆開発版パッチ
XFree86-4.3.0-xtt-add-newttcap_15_2003-03-23.patch
(開発中につき安定して動作するとは限りません
(そろそろコードコンバータまわりやらないとなぁ)．
また，頻繁に仕様を変更する可能性があります)
このパッチを適用した場合，X サーバも rebuild する必要があります．
◆上記パッチによる効果
新しい TTCap の
fc
,
fm
が追加され，
ds
による bold 体生成の機能を拡張します．
また、AutoItalic (TTcap の ai) 使用時も、Embedded Bitmap
を使うようになります。
以下でそれぞれを説明します．
◇ fc=範囲
フォントのコードの範囲を指定します．
「数」「数-数」「-数」「数-」
という書式で指定できます．
それぞれの数には八進数，十進数，十六進数を指定することができ，
八進数は 0 を前置することにより，
また，十六進数は 0x を前置することにより十進数と区別します．
文字コードは xfd で表示される 16 進の値で指定します．
ここで指定した区間の文字の spacing は -c- として取り扱われ，
metrics の計算を省略し，高速表示を可能にします．
この機能は X-TT 1.3 の TODO に上がっている partial proportional
なのでしょう…
(fc : Force Constant spacing code range)
◇ fm=文字コード あるいは fm=実数,実数,実数
fc で指定した区間の文字の metrics は
通常 maxbounds が適用されますが，それではマズい場合があります．
その場合に，fm で特定の文字コードを指定すれば，
その文字の metrics を maxbounds のかわりに利用できます．
fm も fcと同様に，
八進数，十進数，十六進数を指定することができます．
指定できる適当な文字がない場合には、
metrics の boundary box width の倍率, left side bearing の倍率, right side bearin
の倍率 を
直接指定できます。
必ずカンマ「,」で区切り、
３つの実数値を指定します。
数値は省略可能ですが、カンマは省略できません。
maxbounds をめいっぱい使う設定は
fm=1.0,0.0,1.0，
maxbounds の半分の幅を使う設定は
fm=0.5,0.0,0.5 になります．
それぞれの倍率 は maxbounds の幅に対する割合を指定します
．
(fm : Force constant spacing Metrics)
◇ ds=[ymn][b];整数
ds=y では，従来のダブルストライク効果と同じ動作ですが，
ds=m とすると，
mkbold
と同様の手法で擬似 bold 体を生成し，小さいフォントでの可読性を改善します．
セミコロンのあとの整数は ds=mでの mkbold 的手法を適用する
フォントサイズの上限(ピクセル)を指定します．この整数が
省略された場合はすべてのサイズでmkbold 的手法を適用します．
以下は ds=y, ds=m それぞれの場合の
xfontsel での表示例です．
また，ds=yb あるいは
ds=mb のようにすると
bounding box のサイズが自動的に調整され，
横に 1 ドット大きくなるようになっています．
したがって，ds TTCap の 2 文字目に「b」を入れておけば，
従来の bw=1.1 のような設定は不要になります(bw=1.1 のように指定すると，
フォントサイズが大きくなると文字間隔が広がりすぎる)．
◆fonts.dir の設定例
fc=0x0100-0xfeff:hi=y:kochi-mincho.ttf -kochi-kochi mincho-medium-r-normal--0-0-0-0-p-0-iso10646-1
fn=1:fc=0x3400-0xefff:hi=y:msmincho.ttc -microsoft-ms pmincho-medium-r-normal--0-0-0-0-p-0-iso10646-1
fn=1:fc=0x2841-:hi=y:msmincho.ttc -microsoft-ms pmincho-medium-r-normal--0-0-0-0-p-0-jisx0208.1983-0
hi=y:fc=0x3400-0xe7ff:fm=0x5a00:vl=y:arialuni.ttf -microsoft-arial unicode ms-medium-r-normal--0-0-0-0-p-0-iso10646-1
fonts.dir の例,
fonts.alias の例
◆xfontsel での表示速度(vl=n の場合と比較)
上記 kochi mincho(iso10646),ms pmincho(jisx0208) の場合は，計測不能なほど，高速になります．
上記 ms pmincho(iso10646) の場合は 10 倍程度高速になります．
vl=y と併用すれば，もう少し高速化できます．
もちろん，表示速度は
fc
で指定した区間が長ければ長いほど速くなりますし，
短いとあまり高速化できません．
jisx0208 の実際の設定では，すべて漢字部分(0x3021[亜]〜)の spacing は -c- と
扱って良いと思いますが，この場合 vl=y がなくても
十分に高速表示が可能です．これによって始めて jisx0208 でも
厳密な metrics 計算による実用的なプロポーショナル表示が可能になるわけです．
unicode に関しては微妙なところで，ギガクラスのマシンの場合は
fc で metrics を計算する範囲を制限すれば
vl=y がなくても十分実用に耐えうると思いますが，
一般的な設定では
vl=y と併用した方が無難かもしれません．
◆xfd を使った TTCap fc の指定方法
xfd -box -fn "-microsoft-ms pmincho-medium-r-normal--24-0-0-0-p-0-iso10646-1"
のようにすると，bounding box 付きでフォントが表示されます．
bounding box を見ながら，どこの区間を -c- として取り扱うかを決めます．
fc
には xfd で表示される 16 進の character コードを指定します．
なお，fc で指定できるのは，
一つの区間のみです．
◆Plamo-3.0 用 XFree86-4.3.0 バイナリパッケージ
x430devel_bin.tgz
(2003年3月21日更新)
x430bin.tgz のかわりに入れてみてください．
新 TTCap の使える libxtt.a と X サーバを入れてあります．
■調査中のバグ■
現在調査中のバグはありません．
■解決したバグ(すべて X のクラッシュを引き起こすバグです)■
-
【P1】Linux / PPC では i386 と比較にならないほど
X が頻繁にクラッシュする【New!】．
-
Vine-MLへの報告
Masatsuna 様の全面的なご協力で，
手元に Linux/PPC が用意できないにもかかわらず，
bug が修正できました．Masatsuna 様に感謝!!
[原因] codeconv モジュールをロードする時の，モジュール名を決定するための
文字列比較にバグがあり，特定の OS では不正なモジュールが読み込まれて
X がクラッシュします．
[Linux/i386での挙動]
Linux/i386 の場合，幸運にもクラッシュは発生しない場合がほとんどですが，
このバグによって Linux/i386 でも iso8859-2〜15 なフォントを表示する場合に
不要な codeconv モジュールが
読み込まれてしまうためパフォーマンスが低下しています．
-
【０】
フォントキャッシュが満タンに近い時に，
頻繁に巨大なフォントを表示させると稀に X
がクラッシュする．
-
VineML:http://search.luky.org/vine-users.5/msg08322.html
デバッグにあたって，
H N 様，嶋田様には様々な協力をいただきました．感謝いたします．
[原因] フォントキャッシュからビットマップ用領域が確保できない時の
エラーチェックが抜けているためです．
-
【１】
-c- のフォントのグリフが未定義の場合にゴミが表示される．
-
フォントサイズが大きくなると，
X ごとクラッシュする可能性大
VineML:
http://search.luky.org/vine-users.5/msg04993.html
中井＠Redhat 様より情報をいただきました．感謝いたします．
[原因] XFree86-4 の仕様に xtt が追従できていないためです．
-
【２】dpi = 100 で X サーバを使用し，
Netscape Communicator 4.7x,4.8 で特定のフォントを表示させると，
X ごとクラッシュする．また，東風フォントを使用した場合，
Netscape Communicator でゴミが表示される．Vine2.6 で
mozilla をしばらく使っていると確実に X がクラッシュする．
Vine2.5 では問題なかったが，
Vine2.6 をクリーンインストールすると，頻繁に X がクラッシュする．
-
Vine-MLへの報告(1)[解決],
Vine-MLへの報告(2)[解決],
ここで報告されている嶋田様，伊達様に本ページの libxtt.a を
試していただいたところ，問題が解決したとの事です．
参考画像:"xaa"を有効にした場合，
"xaa"を無効にした場合(嶋田正則様提供)
[原因]
-m- や -p- のフォントの場合，
metric の計算の誤差(と思われる)によって
個々のグリフの ascent/descent が maxbound.ascent/maxbound.descent
を越える事があり，xtt がこの不正な ascent/descent を XFree86 に返すために，
XFree86 側でバッファオーバーフローが発生します．
-
【３】特定のフォント(MSのverdana.ttfで確認されている)を
Netscape Communicator 4.7x,4.8 で表示させると，
X ごとクラッシュする．
-
MSのverdana.ttfを使っていると確実にクラッシュするURL:http://www.macromedia.com/，
http://www.edpsciences.fr/uk/
gdb での back trace
Program received signal SIGSEGV, Segmentation fault.
0x0831b181 in ?? ()
(gdb) bt
#0 0x0831b181 in ?? ()
#1 0x0831b746 in ?? ()
#2 0x0831ac85 in ?? ()
#3 0x08166d6d in miSpritePolyText8 (pDrawable=0x88ef038, pGC=0x8922f90,
x=565, y=447, count=37,
chars=0x40df1282 "Macromedia Flash MX looks back on the")
at misprite.c:1820
#4 0x080cd01f in doPolyText (client=0x86a10b8, c=0xbffff4c4)
at dixfonts.c:1392
#5 0x080cd1c3 in PolyText (client=0x86a10b8, pDraw=0x88ef038,
pGC=0x8922f90,
pElt=0x40df1280 "%", endReq=0x40df12a8 "JD\t", xorg=565, yorg=447,
reqType=74, did=41944246) at dixfonts.c:1473
#6 0x080b2afd in ProcPolyText (client=0x86a10b8) at dispatch.c:2368
#7 0x080af246 in Dispatch () at dispatch.c:462
#8 0x080bf3bb in main (argc=3, argv=0xbffffa14, envp=0xbffffa24) at
main.c:454
#9 0x4005616f in __libc_start_main () from /lib/libc.so.6
[原因] xtt が bitmap データを用意できていない(NULLポインタ)にもかかわらず，metric の
ascent/descent が 0 以外の値を XFree86 に対して返すため，
XFree86 が NULL を参照してクラッシュします．
-
【４】サイズの大きいフォント(700ピクセル程度以上)を表示させると，
フォントにかかわらず X ごとクラッシュする．
-
gdb での back trace．
Program received signal SIGSEGV, Segmentation fault.
0x0836ddc1 in ?? ()
(gdb) bt
#0 0x0836ddc1 in ?? ()
#1 0x08385b3a in ?? ()
#2 0x08385c10 in ?? ()
#3 0x0837f71e in ?? ()
#4 0x08156278 in miPolyText16 (pDraw=0x40d8d008, pGC=0x88ccc90,
x=-4100,
y=633, count=9, chars=0x8833e22) at mipolytext.c:132
#5 0x083082cd in ?? ()
#6 0x080cd01f in doPolyText (client=0x885ee90, c=0xbffff4c4)
at dixfonts.c:1392
#7 0x080cd1c3 in PolyText (client=0x885ee90, pDraw=0x40d8d008,
pGC=0x88ccc90,
pElt=0x8833e20 "\t", endReq=0x8833e34 "87\004", xorg=-4100,
yorg=633,
reqType=75, did=44040196) at dixfonts.c:1473
#8 0x080b2afd in ProcPolyText (client=0x885ee90) at dispatch.c:2368
#9 0x080af246 in Dispatch () at dispatch.c:462
#10 0x080bf3bb in main (argc=3, argv=0xbffffa14, envp=0xbffffa24) at
main.c:454
#11 0x4005616f in __libc_start_main () from /lib/libc.so.6
[原因] 【３】の原因と同じです．
■問題解決のためのパッチ，修正モジュール(2003年2月28日)
これらの問題に対するパッチと修正モジュールができました．
手元では以下のモジュールで安定動作しています．
万一，以下のパッチ，モジュールを使用しても改善がみられない場合は，
できるだけご連絡ください．
・
libxtt.a.gz[Linux/i386]
(XFree86-4.2.1,4.2.0 Plamo-2.x,Plamo-3.x,Vine-2.6 i386で動作を確認)【Updated!】
・
libxtt.a.gz[Linux/PPC]
(XFree86-4.2.1,4.2.0 Vine-2.6 で動作を確認)【New!】
・
libxtt.a.gz[FreeBSD5.0/i386]
(XFree86-4.2.1,4.2.0)【New!】
これらのモジュールは
このページ上のすべての xtt への修正パッチを適用したものです．
FreeBSD5.0 用のモジュールは 渡辺様に，
PPC 用のモジュールは Masatsuna 様に
ビルドしていただきました．感謝!!
・
XFree86-4.2.1-fix-xttcconv-server-crash_2.patch【New!】
このパッチは
【P1】
のクラッシュ問題を修正するものです．
・
XFree86-4.2.1-fix-xtt-server-crash2.patch
このパッチは
【０】
のクラッシュ問題を修正するものです．
・
XFree86-4.2.1-fix-xtt-garbage.patch(ほとんどが山内 英敏 様
によるものです．感謝!!)
このパッチは
【１】
のゴミ問題を修正するものです．
XFree86-4.2.1-fix-xtt-server-crash.patch
を適用してからあててください．
・
XFree86-4.2.1-fix-xtt-server-crash.patch
このパッチは
【２】【３】【４】
のクラッシュ問題を修正するものです．
ただし，巨大なフォント(700ドット以上)の場合に
何も表示されなくなるという不具合つきですが…．
普通はそんなに大きなフォントは使わないので，これで良しとします．
・
XFree86-4.2.1-fix-xaa-server-crash.patch
・
libxaa.a.gz
(XFree86-4.2.1,4.2.0 Plamo-2.x,Plamo-3.x,Vine-2.6 i386で動作を確認)
このパッチ，修正モジュールは
【２】のような問題をより起こりにくくするための
補助的なパッチです．必須ではありません．
この xaa のパッチは，修正前の
xtt のように多少行儀の悪いフォント展開モジュールでも
簡単にはクラッシュしないように，
より安全なコードに修正するものです．
なお，これらのバグ修正を行うにあたって，
山内 英敏 様，嶋田様，H N 様, Masatsuna 様には多大なる協力をいただきました．
ありがとうございました．
今後も，xtt をより安定化させるためにメンテナンスを
行なっていく予定です．
■Vine 2.5,2.6 の危険性に関して(2003年2月22日)
Vine Linux が Errata を発行しています．
XFree86-4.2.1-0vl14 で xttcconv のパッチ以外すべて
の修正が含まれています．
Vine ユーザの方はそちらをご利用ください．
ただし、PPC の場合は 【P1】の問題に対するアップデートが含まれていないので、
このページの libxtt.a をご利用ください。
なお，ttfconf ファイル(TrueTypeのrpm)についても，Vine の
update にある rpm をそのままご利用ください．
このページの ttfconf を使う必要はありません．
Plamo-3.0 では Vine ほど積極的に xtt を使う設定をデフォルトでは
いれていませんが，以前から xtt の危険性は
ERRATAで警告しています．
一方，
XFree86-4 で xtt を積極的に使っている Vine 2.5,2.6 は
さらに大変危険な状態にあります．
このページを読まれた Vine 2.5,2.6 のユーザの方は，ただちに
このページにあるlibxtt.a.gz
をインストールしてください．
そのまま使いつづけると，いつ X がクラッシュするかわかりません．
さらに，私の見解だと，Vine 2.5 よりも2.6の方が危険性が高い
です．
ML にもある通り，
Vine 2.5 では xtt の spacing に -c-
を主に使用していたのですが，
未定義グリフにゴミが出るという問題がわかったため，Vine 2.6 では
-m-
を積極的に使用する設定になっています．
ところが，【２】のクラッシュは -m- や -p- の
時にしか起こりません．
未定義ブリフはそれほど頻繁に表示しない事を考慮すると，
通常のグリフを表示する時に起こる【２】のクラッシュは
【１】よりも深刻だと私は思います．
おそらく，ある数のユーザさんは
Vine 2.6 の「なぜかいきなり X がクラッシュする」
といった状況をよく経験されていると思います．
しかも -m- や -p- の場合には，
ブラウザ等の起動時間がとんでもなくかかるようになってしまい，
多くのユーザがその重さに苛立ちを感じているに違いありません．
対策方法は簡単です．
libxtt.a.gz
をダウンロードし，gunzip で解凍して
/usr/X11R6/lib/modules/fonts/
に入れてください．
以下に，「-m-をやめて
(正確には，libxtt 内部で -c- として処理する)
フォントの展開を高速化する
ttfconf ファイル」を置いておきますので，これを TrueType ディレクトリに
おいてください．
・kochi.ttfconf
・microsoft.ttfconf
・dyna.ttfconf
これらの ttfconf ファイルは Vine 2.6r1 のものをベースとしています．
TTCap について詳しい方ならすぐにわかると思うのですが，
ミソは jisx0208.1983 の mono の部分にある
fs=c
です．これで libxtt.a 内部で -c- として処理するわけです．
なお，prop には fs=c を入れていません．
漢字にプロポーショナルなど不要という方は，
prop の jisx0208.1983 にも
fs=c を入れると良いでしょう．
この場合は，漢字がプロポーショナルでなくなりますが，
フォントの展開が高速化されます．
もし、Vineのアップデートを適用して、Gecko系のブラウザのフォントが変になったら、
このパッチを
適用してブラウザを rebuild するといいかもしれません。
■各ディストリビューション対応状況
・Plamo Linux : アップデートパッケージで対応済
・Vine Linux : XFree86-4.2.1-0vl14 で対応済
・Debian GNU/Linux : XF86-4.2.1-7 で対応予定
・Suse Linux : Current βでテスト中．8.2 で対応予定
・Red Hat Linux : ?
|
|
