chaptchajp

強制的にEUC-JPにしているそうですから
$text = mb_convert_encoding ( $textarr, "EUC-JP" , "UTF-8" );
こういう風にしてみました。
ネットで検索したらあっさり出てきたので、そう言う設定しているところも少なくないのかもしれませんね。
と、思ったので、そのまま生かしておくことにしました。

一応、filesフォルダ下にimgとCSSを生成するようにしたいので、それが終わったら公開する予定です。いつになるかな～（;￣ー￣A

$arrInfo = gd_info();
if ($arrInfo['JIS-mapped Japanese Font Support']) {
$text = mb_convert_encoding($text,"SJIS","UTF-8");
}
な感じで、よいのかな？

春中に予定のサーバー増強のときには、JIS-mapped Japanese Font Supportは無効で設定しますね。つかう事はないですから。
このサーバーは、現在
FreeBSD6.1
Apache2.2.4
PHP4.4.5
APC3.0.12
GD2.0.33
Mysql4.1.22
etc...
のような構成です。念のため。

色々とありがとうございます。
文字化けの方はgd_infoで調べて、有効になっていたらEUC-JPに変換して渡すようにして、動作することを確認しました。

CSSの方は、CSSを毎回ランダムなファイル名で作ってそれをロードさせようかと考えています。もちろん、imgも合わせてその都度ランダムなファイル名で作ろうかと思っています。
そうすれば、とりあえずは干渉がないかな？いや、絶対ないわけではないでしょうから時間情報とかも組み合わせた方がいいかな？
Drupalでなんか、セッション毎のユニークなIDでも持っていると、それを使いたいなーとは思うんですけどね(^_^;)
今、気にしているのはCSSからimgがロードされるタイミングです。
ファイル名をランダムにすると言うことは削除という作業が必要になると言うことなので、それをどのタイミングですれば大丈夫なのかです。
正直申しまして、モジュールの全体構造が判るほど理解していない(全くというレベルかもしれません(^_^;)ので、どのタイミングで削除処理したモンかな・・・というのが悩みですね。
出来ることなら、オリジナルのアップデートを考えて改造で手を加える範囲を限定したいので、その辺とのかねあいが気になるところです。

なんか、壮大になってきましたが(笑)フォントを複数入れたらランダムでフォントを選ぶなんてことも出来たらいいかなとか考えていますが・・・果たして(^_^;)

飲み込みが悪くてすみません。(^^;;

公開・非公開は、
variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC)
で判りますが、file_create_url関数を使えば公開・非公開に合わせたURLができますので、そちらの方がいいと思います。

ところで、CSSの記述を変えて画像を切り替えようということでしょうか？
それですと、複数から同時アクセスされると、ちょっと不味いことになりませんか？
また、5.xからCSSの圧縮機能が入ってますので、この機能と干渉するような気もします。

filesの場所はfile_directory_path()で取得できるみたいですね。
アドレスの公開/非公開設定の状況を知る方法が判ればCSSに書き込むのは組み込めそうですが・・・うーん。
あとは、imagettftextでテキストを渡すときの文字コードの問題ですね・・・。
gd_infoではJIS-mapped Japanese Font Supportの情報は取得できないみたいですし・・・うーん。
追記:取得できるっぽいのでチャレンジしてみます。2007/03/05 15:53

うーん

が多い今日この頃(^_^;)

ということは、EUC-jpに変換して渡してあげないといけないと言うことですか?
この状態かどうかと言うのは調べる関数というのはあるんですかね?調べられれば、トラップを仕掛けることも可能に出来そうな気がしますが・・・。

書き方が悪くて、申し訳ないです<(__)>
そのfilesのことなんです。日本語翻訳当てると「ファイルシステム」って訳になるのでそう言ったのですが・・・難しいですね（;￣ー￣A
ここで、ダウンロードを非公開にしているとまんま記述しても呼び出すとエラー起こしますよね?
変換されるアドレスは規則性があるんでしょうけど、その状態を知る方法もあるんですよね?
他のモジュールも当たってみますか・・・って、判るのかどうかは別問題なんですけど（;￣ー￣A

ちょっと違います。JIS-mapped Japanese Font Supportが有効になっていると、強制的に内部でEUCJPに変換されます。入力に想定されているのはUTF-8以外の日本語エンコードですね。
元々、Unicode以前の日本語環境を対象にした機能なので、UnicodeマッピングのフォントをUTF-8で使う場合はかえって邪魔になります。[追記]imagettftextは文字列をそのままGDに渡しているだけなので、使い物にならなくなる訳ではありません。

realpath('.')で絶対パスが返ります。
PHPで絶対パスへの書込みは可能ですが、セキュリティを考えると止めた方がいいですね。(^^
Drupalの場合は、filesフォルダ(adminメニューから変更可能)の中にサブフォルダを作って書くのが基本でしょうか。

ちなみに、さくら鯖の方はJIS-mappedはついていませんでした。それ以外はバージョンほか、同一の設定でした。
なるほど。サーバーのことはまるで知りませんが、強制的にSJISしか受け入れなくなると言うモノなのですか?
だとしたら、UTF-8で渡すことが推奨されているimagettftext周りは使い物にならなくなるという解釈でいいんですか？？
どちらにしても、UTF-8で動作するDrupalで、SJISで文字列を扱うというのもどうかと思うので・・・うーん。
こういう設定って、多いんでしょうか?多いのなら、なんかトラップを考えないと駄目ですよね・・・（;￣ー￣A

話違うんですが、Drupalのファイルシステムの場所を取得する変数？もしくは関数って、なんでしょうか?
ファイルシステムのフォルダ内なら、モジュールから自由（といっても限度はあるでしょうけど）に書き込めるんですよね?
あー、でも、アドレスを隠蔽する設定にしているとそれを取得するのもやっかいか・・・(T.T)

あぁ、なるほど。でしたら、
mb_convert_encoding($text, "JIS", "UTF-8");
とJISコードに変換する方が確実ですね。SJISですとEUCJPと区別できないかもしれませんので。

JIS-mapped Japanese Font Support を有効にすると、実質的にUTF-8を使えませんので、SJISマッピングのフォントを使う必要がなければ、無効にした方がいいと思います。

mb_convert_encoding($text, "SJIS", "UTF-8");
な感じで、ひらがな変換に関しては解決します。たとえば、
$textt = mb_convert_encoding($text, "SJIS", "UTF-8");
なんかで、$textを$textｔなんかに変換後、以下の変数に当てはめる感じかな？
未検証ですが・・・。
SJISからのコンバートに関しては、GDコンパイル時にJIS-mapped Japanese Font Support を有効にしてコンパイルしたせいでしょうか？
正常に動いているサーバーのphpinfoのGDと設定を比較してみてください。・・・というくらいしか思いつかない（汗