「人の心に残るというのが大事」と言う話。
何か連絡がある場合はメールでどうぞ(過去の日記へのツッコミは基本的にみていません)
ここ最近のツッコミ/トラックバックリスト。
$ apt-file search fontconfig.properties ia32-sun-java6-bin: /etc/ia32-java-6-sun/fontconfig.properties ia32-sun-java6-bin: /usr/lib/jvm/ia32-java-6-sun-1.6.0.16/jre/lib/fontconfig.properties ia32-sun-java6-bin: /usr/lib/jvm/ia32-java-6-sun-1.6.0.16/jre/lib/fontconfig.properties.src openjdk-6-jre-headless: /etc/java-6-openjdk/fontconfig.properties openjdk-6-jre-headless: /usr/lib/jvm/java-6-openjdk/jre/lib/fontconfig.properties sun-java6-bin: /etc/java-6-sun/fontconfig.properties sun-java6-bin: /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/fontconfig.properties sun-java6-bin: /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/fontconfig.properties.src
/etc/java-6-openjdk/fontconfig.properties がある。/usr/lib/jvm/java-6-openjdk/jre/lib/fontconfig.properties はこれへの symlink になっている。
お、vlgothicが定義されていてそれが使われるようになっている。patches/icedtea-fonts.patchというのがあって、それが適用されている模様。ということは前に調べたのはもう解消しているんだな。良かった良かった。
sequence.allfonts.x-euc-jp-linux=latin-1,japanese-vlgothic,japanese-kochi,japanese-sazanami sequence.fallback=uminghk,shanheisun,wqy-zenhei,japanese-vlgothic,japanese-kochi,japanese-sazanami,korean-un,korean-baekmuk,bengali,gujarati,hindi,oriya,punjabi,tamil,telugu
順番に定義したセットでfallbackしていくようになっているようだ。根本的な問題としては、ここで定義されたフォントがあったらそれを使うという、ということは例えばwqy-zenhei(中国語のフォント)が入っていたらそれを日本語のフォントより優先的に使うということ。うーん。でもこれを思い通りにするのはかなり大変そうなので、それはそれで放置しておく。
…まぁそれでも、順番若干おかしくない?VLゴシックはいいとして、東風の方がさざなみより優先されてるな。
serif,sans-serif,monospaced,dialog…とセットで定義しているので、VL ゴシックに合わせるserifに東風明朝が…ってなんでやねん。さざなみじゃないのか。
serif.plain.japanese-vlgothic=Kochi Mincho serif.bold.japanese-vlgothic=Kochi Mincho serif.italic.japanese-vlgothic=Kochi Mincho serif.bolditalic.japanese-vlgothic=Kochi Mincho
東風・さざなみのどちらにするかは、東風とさざなみのデフォルトインストール具合によって変わってくるかな。
tasksel の tasks/japanese-desktop ファイルを参照すると
ttf-sazanami-gothic ttf-sazanami-mincho ttf-vlgothic otf-ipafont
少なくとも Debian ではさざなみだと思う。
はて、東風が優先される背景はどこらへんにあるのかな。一応、Fedoraでの設定が優先されているのだろうとは思うのだが。
雑文でも書いてみるもんですね。なるほど、triggerという仕組みがあるんですな。debパッケージには無いような、はて。何か副作用があったりするかな?パッと思いつかないけど…
現役パッケージャからも反応が。「フォント・LXDE・その他GTKアプリケーション等」って自分には無理ですね…License、Summaryのあたりはなるほど了解というところですが、ライセンスは DEP5 の方は細かすぎなのかも。まぁ整備するのが大変か。パッケージで持っているのはおおらかというか大まかというか、という印象。
ディストリ毎に独自のmacroが幾つかあり、パッケージの移植の際に悩まされることがあります
ここは大変興味があります。どんな苦労が待っているのか?(笑
また教えてもらえた嬉しいですねぇ :)
ということで trigger あるよ、と。でも使ってるの見た記憶がない…もちっと調べよ、ということですね。
iceweasel 話が色々聞けるのを楽しみにしています :-)
東京Qチャンネル(T.Q.C.)『ゴールデン☆ベスト 〜Sweet Works〜』 |
|
|
>triggerという仕組み<br>debにもありますよ<br>http://www.dpkg.org/dpkg/Triggers
> でも使ってるの見た記憶がない<br>xulrunnerのパッケージがtriggerを使ってますよ ;-)<br>xulrunner-1.9.1-gnome-supportをアップグレードする時にdpkgがtriggerを処理するというメッセージが現れるはず…でした。(xulrunner-1.9.1-gnome-supportはもう存在してませんので)
取り上げていただきありがとうございます。<br>元々Vineのパッケージ量はそれほど多くないですから、<br>自分が使いたい&オススメというパッケージを作成・追加していったら…<br>と結構な量になり今に至っています(汗<br><br>マクロの件は、Vineの場合Fedoraと通底するものが多いため<br>Fedoraのパッケージを移植する場合はすんなりいくことが多いですが、<br>Mandriva/openSUSEは独自マクロが散見しますので、<br>独自マクロの内容把握と書き換えに時間を費やしています。<br>マクロの把握が思うようにいかず、投げ出したものもあります。