モトヤLシーダ3等幅JavaにおけるフォントレンダリングDPIとスケーリングDPI未来このテキストについてこのテキストは次の授業で使用されている標準化された教材です。Yokohamaの授業のすべてではないことを予めご理解ください。Systemによって提供されています。フォントの基礎フォントとは文字が何を意味するかはデータ的に確定できます。0x82は「あ」を意味します。Aとして定義されています。言われればおおよそどのような形をしているかは想像できるでしょう。具体的な形は確定できません。Aがどのような形をしているかという情報は含まれていません。ハンバーガーであることはわかりますが、どのような形をしたハンバーガーなのかは不明です。フォントは文字ごとの具体的な字形(グリフ)を定義します。フォントを使うことで文字を視覚的な情報として表示することができるようになります。フォントソフトウェアの開発と配布フォントは自動生成技術も存在はするものの、多くの場合一文字ずつ制作していかなければならない作業です。美的感覚も関わることであることから様々なフォントソフトウェアが存在し、配布・販売されています。欧文書体と比べ和文書体は非常に多くの文字を必要とすることから比較にならない労力がかかります。アートワークは一般に比較的曖昧なライセンスによって配布されることの多いものですが、フォントソフトウェアの場合作業量が非常に多いこともあってそれほどの数があるわけではありません。場合によっては「十分にフリー」なフォントソフトウェアが存在しないためにフリーソフトウェアシステムの世界全体に影響を与える場合もあります。無料で使用できるフォントは数自体はそれなりにあります。アートワークという性質上ソフトウェアやライセンスに詳しくない人が作成する場合が多く、「利用条件が不明瞭」「不完全なライセンス」という問題がある場合が多く、あまり安心して使用することができません。Licenseですが、これに従ったライセンスは源ノ角ゴシック/源ノ明朝/源ノ角CodeJPなどのフォントがあります。このほか、フリーソフトウェアとして取り扱えるライセンスを持つものとしてM+フォントやIPAフォントがあります。フォントは商用ソフトウェアとして有力なものでもあります。ものから、1書体4万円程度のものまで様々。和文商用書体においては年間3万円から6万円程度のサブスクリプション制度が主流となっています。Linuxにおいて高額な商用フォントが使われることはあまり多くありません。これは、高額な商用フォントを個人で使うこと自体少ない上に、これらのフォントはアートワーク向け、あるいは印刷向けでを想定しているため、Linuxの用途としてあまり一般的なものではないためです。TeXによる論文のために高額な商用フォントが使われることもありましたが、現在はそのようなこともなくなりました。ひとつ、商用フォントソフトウェアのライセンスが慣例的にOSを含めるものになっており、Linux上で利用すること自体が微妙な問題を含む場合が多いという理由もあります。他環境におけるフォントソフトウェアとメトリック互換フォントLinuxという環境は決して主流ではありません。世の中はWindowsあるいはMacシステムが圧倒的に多く、それを前提として世の中は回っています。数としてLinuxがそこまで少ないわけではないのですが、知識に乏しい人がLinuxを知っている割合が少なく、世の中においてはあまり想定されません。Linuxの環境には幅があり、特定の環境を想定できないというのもあるでしょう。Windows及びMacのシステムに採用されている欧文フォントとして次のようなものがあります。ArialHerveticaCourierこれらはフリーなフォントではなく、なにかしら保護されたフォントソフトウェアです。これらのフォントは存在することが想定されており、UI部品などは部品上にこれらのフォントで文字を描画することを想定されていたりもします。これらのフォントがないことによる最大の問題は、大きさが変わってしまうためにはみ出したり、折り返されてしまったりすることです。そのため、各グリフのサイズが同一のフォントがあれば表面的な問題は軽減されます。このようなフォントをメトリック互換フォントと言います。これらの欧文フォントに対するメトリック互換フォントは次のようなものがあります。Schoolbook欧文のメトリック互換フォントを代替フォントとして使用することを明示的に指定する必要はほとんどありません。これらは30-metric-aliases.confとして定義されているからです。日本語フォントとしてはWindowsにはMSフォントファミリーと呼ばれる5書体が伝統的に採用されてきました。現在はWindowsの和文フォントとしてメイリオと游フォントファミリーが追加されています。Xになって以降は字游工房制作のヒラギノフォントファミリーが収録され、こちらが有名となっています。Macの場合フォントの変遷もあったこともあり、指定されることがあっても置き換えにより支障が出るケースは稀でした。これは非Macユーザーにとっては非常に高価なフォントであるということもあり、文書作成でヒラギノフォントファミリーが利用されることは稀です。Pゴシックが指定されることは非常に多く、Linux環境では支障が出る場合があります。MSフォントファミリーに対するメトリック互換フォントとしては梅フォントファミリーがあります。Pゴシック互換フォントもあります。Pゴシックメトリック互換であることは必須であることに由来します。Windows及びMac両方で利用可能なことから今後は游フォントファミリーが指定されてくることも想定されます。論理名のフォント伝統的にフォント名として次のものが認識されます。SerifSans-serifMonospaceこれらはそれぞれの形状に対するデフォルトのフォントとして使用されるフォントであり、他のフォントに対するエイリアスになっています。実際にどのようなフォントが使用されるかは非常に多くの要素に左右されます。場合によっては適切なグリフを持たないフォント(空グリフの多いフォントやシンボルフォントなど)が使用され、文字が正しく表示されなくなる場合もあります。明示的にこれらのフォントで何を使用するかを指定したい場合はFontconfigのユーザー設定で(エイリアスではなく)フォントの置き換えによって指定するか、(できるのであれば)デスクトップ環境によって指定すると良いでしょう。これらのフォントの置き換えは非常に幅広く影響を及ぼします。メトリックサイズや判読性などを考慮して選択しましょう。伝統的理由により次のフォントが広く指定されています。ほとんどの場合意味がありません。完全に無視しても問題は発生しないはずです。Arial/Hervetica(両者はメトリック互換)に関してはUI部品に使われることがあり、特徴的なメトリックであることから表示が崩れる場合があります。これらは望ましいこととは言えません。意味のないフォントの固定はユーザーの設定の自由を剥奪することになるためです。現実にはほとんどのサイトでこのような指定がなされています。Windows及びMacにおいてはSans-serifやSerifを設定する正規の方法がないため、あまり望ましくないフォントがデフォルトフォントとして使用される傾向があります。そのために、一般的なウェブブラウザではSans-serifやSerifをアプリケーションにおいて設定できるようになっており、これはLinuxにおいても同様です。ウェブブラウザは例えLinuxであってもデフォルトのSans-serifをsans-serifに設定するといったことをしていません。monospaceが指定された場合でもデフォルトではシステム(Fontconfig)の設定を尊重しません。フォントリストには存在することから、設定することでシステム由来とすることはできます。この場合でもChromium系ウェブブラウザはフォントリストにSans-serifではなくSansというエントリを追加しており、実際にFontconfigに対してSansを要求します。FontConfigはSansを暗黙にSans-serifと解釈することはしません。端末におけるフォント端末は仮想のマス目を持っています。このマス目の大きさは完全に固定されている(ピクセル単位で決まっていて、同ピクセルサイズのフォントを要求する)か、フォントのサイズに基づいて決まります。このために端末のフォントは等幅フォントであることが完全な要求となっています。フォントのメトリックが一定でない場合、フォントの位置はマス目からずれてしまいます。このようなケースにおいて起きる問題は2つに分かれます。ひとつはフォントを常にボックス上に配置するケースです。これは幅が足りなければ間があき、すぎれば重なります。ひとつは表示はフォントに任せるもののカーソルはボックスを維持するケースです。この場合、文字とカーソルの位置関係はどんどんずれていきます。難しい問題は文字の幅の定義です。ASCII文字の場合、文字の幅は常に一定です。日本語の場合は「半角」と「全角」の2種類の幅があります。基本的に「2倍幅の文字」を持つのは東アジア言語のみとされています。ところが、フォントとしては東アジア言語でなくても通用する文字、というのがあります。典型的には「☆」や「♠」などの記号です。このような記号はヨーロッパでも通用しますが、その場合通常の文字の倍の幅を取る意味がありません。そのため、ヨーロッパ言語のフォントでは一般的にこれらの記号は文字と同一幅です。このような「プロポーショナルでないフォントでもフォントによって幅の定義が異なる」文字は「ambiguousな文字幅」として定義されています。これをどのように扱うかは現代的な端末では設定できるようになっています。一般的にはフォントメトリックに従うように設定されていることでしょう。これは正しく判定されないこともありますが、おおよそ期待したように動作します。半角/全角に固定することもできます。このようなambiguousな文字の扱いで難しいのは削除です。バックスペースによる文字削除は内部的には^H(0x08)という文字を送信しています。この文字は幅が-1であり、カーソルを1文字分戻します。ところが、この「1文字分」が問題です。ambiguousな文字幅の文字をバックスペースで消したとき、バックスペースの大きさが半角なのか全角なのかが適切に処理されないことがあるのです。結果、「値としては文字は削除されているけれど、グリフの幅は全角なので半分だけ消えてカーソル位置がずれる」という状況が発生する場合があります。DualspaceSerifと明朝体Serif体(セリフたい)とは文字のストロークの端にある飾りであるserifを持つフォントです。ローマン体ともいいます。日本語においては類似の明朝体というものがあります。明朝体は横線のストロークの右端(左から右にストロークし、右端が留めである場合)に鱗と呼ばれる三角を持つのが特徴であり、この特徴はSerifとよく似ています。このことから、和文フォントにおけるSerif体を求められると明朝体を意味するものとして扱うようになっています。どちらも印刷文書の本文書体としては親しまれてきました。現在も印刷物の本文書体としてはSerif体/明朝体が一般的です。線幅に差があり、細めに見え、また形が把握しやすいことから識別コストが低く、長文を読むのには適しています。現代では明朝体、あるいはSerif体であるだけで「古臭い」と感じて嫌厭される傾向があり、印刷物でもゴシック体を採用する傾向が強まっています。Sans-serifとゴシック体Sans-serif体(サンセリフ体)とはセリフをもたないフォントです。serifとはラテン語で「セリフがない」という意味であり、グロテスク体とも呼ばれます。serif体と同等に扱われるものとしてゴシック体があります。ゴシック体の場合単に鱗がないということを意味しておらず、ゴシック体はフォントを構成する線の太さが一定である、という特徴があります。serif体でも線の太さは一定である傾向があり、ゴシック体といいつつも線幅が変化するものもあります。太さが一定で太く見えることからインパクトがあり、印刷物の見出し用に使われてきました。現代においてはウェブではほとんどの場合ゴシック体、Sans-serif体が使われることからこちらのほうが馴染み深く、本文書体としてもゴシック体を使用する傾向が強まっています。欧文書体でゴシック体というと全く異なる装飾的なものを指すため注意が必要です。DualspaceMonospaceは単一幅のフォントで日本語では「等幅フォント」(とうはばふぉんと)と言います。このフォントは固定幅でなければならない端末での表示や、文字の厳密な識別が重要になるコーディング用のフォントとして使用されます。|(バーチカルバー)が明確に識別できる)ものになっているフォントが多くあります。実際に等幅フォントというときは一般的には和文フォントです。和文フォントには「全角」「半角」という区別があり、日本語の多くのグリフは2倍幅になっています。そのため、実際には2種類の幅があります。このようなフォントをDualspaceフォントと言います。フォントがどのようなメトリックを持っているかはspacingという値によって示されます。0がプロポーショナル、100がmonospace、90がdualspaceです。Qtは端末フォントなどmonospaceフォントを必須とするとき、リストするフォントは>=100であるという条件を持っています。そのためにQtでは等幅フォントの指定にdualspaceフォントを指定できないという問題が発生する場合があります。Linuxにおけるフォントの仕組み古のUnixかつてUnixでは主に点描であるビットマップフォントを扱っていました。「フォントサイズごとにビットマップフォントを指定する」という仕組みを採用していました。Serverの実装であるX11によってサポートされているビットマップフォントです。これは次のような論理名を持っていました。文字集合となっています。「14ピクセルで表示するときは14ピクセルのフォント、16ピクセルなら16ピクセルのフォント」が必要でした。Cell”に由来すると言われています。Windowsで採用されていたpfbフォントと同様のものです。アウトラインフォントを使用する場合でも、ピクセル数ごとに指定する必要がありました。'-*-fixed-*--16-*'のようにして指定していました。フォントを要求するプログラムはそれぞれデフォルトで、あるいは設定ファイルによって要求すべきフォントが定められており、プログラムの起動時に常に指定する必要はありません。この機能は“XCore”というフォントシステムです。昔のLinuxフォント周りに関しては乱立していた時代があります。優勢だったのはクライアント/サーバーシステムをとるXftというフォント管理システムを利用することです。XftのフォントサーバーはXfsといい、各プログラムはXfsにフォントを要求し、そうするとXfsがXftを利用してフォントを得る仕組みです。得てきたフォントはFreeTypeフォントレンダリングエンジンによって描画されます。実際はこんなに単純な話ではありません。Linuxのフォント設定はXfsの設定アウトラインフォントのためのFreetypeの設定ビットマップフォントのためのXCoreの設定の3つがあり、高機能な分、非常に専門的な情報を扱う必要がありました。このような仕組みは無駄だと考えられ、X向けのグラフィックスライブラリであるcairoはXftを使用せず、直接FreeTypeでのレンダリングを行うようになりました。このことから、「Xfsを使うものと使わないものがあり、Xfsを使うものはXfsのフォント設定が反映されるが使わないものには反映されない」という状況がありました。現在のLinuxXfsは廃止に向かっています。FreeTypeはFreeType2となりました。今や、GtkあるいはQtで書かれたソフトウェアを扱う限りはFreeType2のことだけを考えていれば良いでしょう。systemが使われなくなる日がきたとしても問題ありません。systemに依存しない、FreeType直接の取り扱い」というのはWaylandにつながる道だとも言えます。その内容を見ていきましょう。Cairoとはクロスプラットフォームでデバイスに依存しないベクトルベースの2D描画ライブラリです。Cairoを使うことでプログラムは様々な事情を気にせずベクトルベースのグラフィックスを描画できます。PangoはGtk用のテキスト組版ライブラリです。ここでいう組版は画面上の話であり、行列を持って文字を並べる、という機能があります。Pangoには縦書き機能もあります。1QtはPangoを利用しておらず、独自にテキストレイアウトを行っています。Qtの共通ライブラリとして使用されています。systemの存在を気にする必要はありません。これらのライブラリが変更されることがあれば劇的な違いとなって現れるでしょう。PangoやCairoをユーザーが意識することはありません。FreeTypeですらあまり気にする必要はなく、FreeTypeのフォント設定ライブラリであるFontConfigだけを気にすることになるでしょう。ここまで言葉のおさらいです。テキストレイアウトエンジン。Pangoでは縦書きができますが、HarfBuzzではできません。QtともにHarfBuzzを使っていますが、縦書きが可能なのはPangoを使用するGtkだけです。FreeTypeとフォントレンダリング他環境とLinuxのフォントの美しさについてここではフォントレンダリングエンジンの話をしますが、フォントレンダリングエンジンと、フォントレンダラ、そしてフォントラスタライザという言葉は全て同じものを指しています。レンダリングとは描画することをいいます。ラスタライズとはベクターグラフィックスをラスター(点描)に変換することをいいます。Linuxのフォント表示は美しいと言われています。これはFreeType採用によってアンチエイリアス機能が採用されたためです。アンチエイリアスとはなんでしょうか。ディスプレイの特性上、表示されているものは点描であり、ピクセルよりも小さな単位で表示することができません。そのため、アウトラインフォントを使ってもどうしてもギザギザに見えることとなり、特に小さなフォントではそれが目立ちます。そこで本来描画すべき点の周囲に淡い色で描画を行い、視覚上「にじませる」ことでギザギザを目立たなくするものです。アンチエイリアスが美しいとされ、現在においても表示の最高峰となっています。Textが搭載され、話題となりました。Textに倣ったものです。線数の多い和文においては可読性が求められる一方で、醜さも目立ちます。アンチエイリアスのにじみによってアルファベットが解読不能になるのはよほど小さな文字であるときだけなのに対し、日本語であれば簡単に読めなくなります。ところが、アンチエイリアスを有効にし、求めてきたのは日本人です。一方で実用主義者はこれに賛同しません。ビットマップフォントはそもそもが点描であり、サイズも固定です。ビットマップフォントが適切なサイズで表示される限りはそもそも変換する必要がなく、そのサイズで可読性が確保されるように制作されており、どれほど小さい文字であっても(美しさはさておき)判別可能となっています。そのため、実用主義者はディスプレイでの日常的サイズではビットマップフォントを使えば良いし、大きな文字を表示させるときにはアウトラインフォントを使えば良いのだ、と考えています。現在は高解像ディスプレイが普及し、ピクセルサイズで固定されたビットマップフォントは物理的に小さく表示されて読めないという問題がありますが、実用主義者は「物理的にピクセルが小さいのであればアンチエイリアスなどいらない」と主張しています。3GDIというフォントレンダラを使うWindowsのフォントレンダリングはかつてはひどいの一言でした。ClearTypeはWindowsの新しいフォントレンダリングエンジンです。7でDirectWriteというテキストレンダリングAPIを用意しました。これは、レンダリング自体はDirectXによって行うのですが、これがClearTypeが機能するための条件でした。GDI++というライブラリがあり、これはフォントにこだわるWindowsユーザーの間で流行したものです。GDI++はWindowsのフォントレンダリングエンジンを置き換え、割り込んでWindowsの標準レンダラーに変わって描画します。7でClearType採用にも関わらずひどいままだったものの、これについては改善の方向にあります。一部のソフトウェアはWindowsに頼らずフォントレンダリングをしていることから(例えば一時期のSafariや、現在のSlaipnirブラウザなど)システムレベルでのフォントレンダリングの変更は古いアプリケーションで支障をきたす可能性があるために変更できない、ということです。実際はMicrosoft内部にフォントの改善に否定的な勢力がいることが大きな理由であることは間違いありません。実際のところ、ウェブブラウザなど利用頻度の高いソフトウェアが独自にフォントレンダリングを行っており、新しいプログラム、特に「Windowsアプリ」として提供されているプログラムは表示が改善していることから改善の見通しに乏しい状況でもあります。そもそもWindowsのフォントが汚かったのは、記帳なコンピュータリソースをフォント表示に割いてしまわないためで、意図的なものでした。現在は比較的新しい環境で作られたプログラムはClearTypeが美しく機能するようになっている。この修正は2016年に行われ、さらに現在はアンチエイリアスの調整もできるようになっている。MacTypeはWindows向けに移植されたFreeTypeを利用するプログラムです。10があまりシステムに関わるプログラムを受け入れないため、難しいところです。アンチエイリアスの問題は、そもそも「物理的に点が小さくなれば問題自体が縮小する」というものであり、高解像ディスプレイが普及しつつある現状においては目立たなくなりつつあるのも事実です。300ppiを越える高解像度液晶においてさえ、依然としてアンチエイリアスは有効です。ビットマップフォントビットマップフォントは規定のマスの中に点描によって書かれたフォントです。ビットマップフォントは基本的に設計されたサイズでしか描画することができません。FreeTypeの機能によって本来のビットマップサイズ以外のビットマップを表示することができます。この設定は/etc/fonts/conf.avail/10-scale-bitmap-fonts.confとして用意されています。ビットマップフォントはアンチエイリアス(サブピクセルレンダリング)が有効になっている場合でもサブピクセルレンダリングは行われません。ビットマップフォントを拡大すると点描になっていることが確認できるでしょう。4倍に拡大)ビットマップフォントはフォント自体がビットマップになっているものです。この有効/無効を切り替えるには70-yes-bitmap.conf及び70-no-bitmap.confを利用します。アウトラインフォントの中には埋め込みビットマップを持つものもあります。これはビットマップを持つサイズの場合のみビットマップを使用し、そうでない場合アウトラインフォントを使用します。これは「ビットマップフォントが理想的であり、そうでない場合補助的にアウトラインフォントを使用する」という考え方に基づいていることを意味します。埋め込みビットマップを無効にするには次のように設定します。</match></fontconfig>埋め込みビットマップが表示されるサイズはUIスケーリングによって物理的ピクセルと1:1でない場合でも論理的ビットマップサイズに依存します。UIスケーリングで1.5倍になっており、12pxで描画したときに実際には18pxで描画される場合、フォントは12pxで描画したあとUIスケーリングによって18pxに伸長されます。この場合、12pxの埋め込みビットマップがあり、18pxの埋め込みビットマップは存在しない場合、12pxフォントで1.5倍UIスケーリングされている場合は12pxの埋め込みビットマップで描画し、18pxで表示されます。スケーラブルフォントとアンチエイリアススケーラブルフォントはフォント自体にサイズは設定されておらず、要求されたフォントサイズに拡大・縮小して表示します。実際は常に十分に書けるわけではありません。「書」という字は横線で8本あり、さらに上は突き抜けています。そのため、この8本の線の上側に空きが必要になりますが、そのためには16ピクセルなければ書くことができません。フォントサイズは16pxよりも小さく設定できます。その場合正しく表示できないことになります。線がくっつく場合には線を分けて書かずに濃淡で表現します。場合によってはフォントを変形させ、線を省略します。フォントを変形する機能はヒンティングといいます。ヒンティングの情報はフォントに含まれています。ヒンティングは特許保護されており、以前はFreeTypeにおいてはフォントのヒンティング情報を利用せず、グリフから推測して利用するautohinterを利用していました。autohinterはあまり品質が高くなく、ガタガタになりがちです。現在はFreeTypeにおいてもヒンティング情報を利用した描画が可能です。9pxで描画し10倍にしたもの12pxで描画し8倍にしたもの24pxで描画し4倍にしたもの48pxで描画し2倍にしたもの96pxで描画したもの実際に描画されたフォントは描画されたサイズであれば例え小さなフォントであっても文字として読めるように表示されていますが、描画されたものを拡大するとあまり文字としての形を保っていないことがわかります。アンチエイリアスが有効である場合、線の描画がスムーズになるように加工します。サブピクセルレンダリングはより解像度が高く見えるようにさらなる加工を加えます。この両方を有効にしていると濃淡を利用して表現するようになります。これはサブピクセルレンダリングが「拡大して描画して縮小する」という仕組みであるために、拡大して描画したものを縮小するときにどれくらいの点が描かれているかで濃淡となるためです。十分な大きさで描画されたものほど縮小時に縮小対象になるピクセルの中に複数の線が入ることがなくなり、くっきりと見えます。アンチエイリアスを無効にすると(付随してサブピクセルレンダリングも無効となり)線を圧縮していることがわかります。十分に描くことができない場合は線が減っています。(アンチエイリアスなし)一般的に実用的フォントサイズと呼ばれるのは9px-16px程度です。これは日本語を表示するには不十分なサイズです。このためにグリフは濃淡で表示されることが多く、これを「ぼやけてみづらい」と考える人が少なくありません。これがアンチエイリアスの是非に関する意見を分けるところになるのでしょう。十分なフォントサイズを持つ場合、アンチエイリアスが行われることが好ましいと感じる傾向が強まります。アンチエイリアスがなくても不満に感じる傾向も減り、フォントサイズが上がることはレンダリングに関する不満を大きく低減させることになります。CRTモニターにおいては画面が光によってにじむため、アンチエイリアスは過剰なにじみを発生し判読性を低下させます。アンチエイリアスはピクセルが明瞭に表示される液晶ディスプレイにおける要求だと考えても良いでしょう。画面密度が上がるとこうした問題は結果的に緩和されます。9px-16pxとが望ましいというのはあくまで従来の一般的ディスプレイ上でのことです。高密度ディスプレイにおいては16pxではあまりにも小さな文字になってしまいます。Retinaクラスのディスプレイではおよそ倍の密度があるため、通常の16pxと同等のサイズの文字を表示するために32pxを確保できることになります。UIスケーリングの機能により必ずしも単純に32pxのフォントサイズで描画できるわけではありませんが、正しく設計されていればアウトラインフォントの描画は論理サイズではなく描画サイズに対して行われます。InifnalityInfinalityはFreeTypeにおけるレンダリングを改善するためのパッチです。Xのレンダリングをエミュレーションし、美しい見た目を得ることができます。2.7においてInfinality相当の機能が取り込みとなりました。/etc/profile.d/freetype.shにおいてtruetype:interpreter-version=38とすることでInfinality相当のサブピクセルレンダリングを行います。2.7以降に対応するInfinalityパッチが作成されました。fontconfig-infinalityとして存在します。Linux向けのfreetype2-ultimate5も存在します。freetype2-ultimate5は特別な設定も必要なく、パッチを当てる範囲も小さいことから扱いやすいでしょう。FontConfigFontConfigの役割FontconfigはLinuxのフォント設定ライブラリです。Fontconfigはフォントを使用するアプリケーションに対して「何のフォントを」「どのように表示すべきか」という情報を提供します。この大きな意味としてはフォントの物理名のほかに論理名を与えることができるということです。代表的なものとして、以下の論理フォント名が使われていますsans-serifserifmonospaceこれらはフォントの形状の名前であり、フォントの名前ではありません。monospaceは等幅フォントを意味しており、monospaceという名前のフォントが存在しているわけではないのです。アプリケーションは予めどのフォントを選択すべきかという情報を与えられなくても適切に表示できるよう、このような論理フォント名によるアクセスを行います。筆者の環境でmonospaceフォントは次のように選択されています。ゴシックを表示するように指示するわけです。Japanのページを見ると、表示フォントとして次のような指定がなされています。ProN及びOsakaはMacにバンドルされているフォントです。最終的にはsans-serifが指定されていますから、ウェブブラウザは当該論理名のフォントがなければ最終的にsans-serifを使用します。この場合、ウェブブラウザはFirefoxでもChromeでもウェブブラウザが当該要素におけるデフォルトのフォントを要求します。これは通常の段落内のフォントであるため、Firefoxはserifを、Chromeはsans-serifを要求します。このフォント選択においては、ウェブブラウザは論理名があるかどうかだけを確認しており、その論理名のフォントを要求していません。実際にFontConfigに対して要求するのはsans-serifあるいはserifということになります。PGothicを要求した場合はどうなるのでしょう。その場合、FontConfigは「それっぽいフォントを適当に見繕って」返します。monospaceのいずれかのフォントを返すことがほとんどです。Newを要求したときに、当該フォントがなければCourierを返す、といった挙動を示す場合もあります。FontConfigの設定によって、特定の論理名に対して特定のフォントを返すようにすることもできます。FontConfigがどのようなフォントを選択するかについては、fc-matchコマンドで確認することができます。"Regular"また、fc-listコマンドによってFontConfigが認識しているフォントを列挙することもできます。概要FontConfigの設定は多くの場合、/etc/fonts/conf.availディレクトリにインストールされています。有効な設定は/etc/fonts/conf.dです。/etc/font/conf.d内に/etc/font/conf.availディレクトリ内のファイルへのシンボリックリンクを張ることでその設定を有効化することができます。/etc/fonts/conf.dからリンクを削除することで設定を無効化できます。日本語の場合は65-nonlatin.confを有効にするほうが良いでしょう。ビットマップフォントを嫌うのなら70-yes-bitmaps.confを無効化し、70-no-bitmaps.confを有効化します。ユーザーごとの設定ファイルは$XDG_CONFIG_HOME/fontconfig/fonts.conf、あるいは$XDG_CONFIG_HOME/fontconfig/conf.d/*にあります。--></fontconfig>という形式になっています。conf.dディレクトリに配置する場合はNN-*.confとします。NNには数値が入ります。同列に読み込まれた設定ファイルは常にこの番号が小さいものを優先します。エイリアスと置換えFontConfigを使うことで要求されたフォント名とフォントが持っている物理フォント名を1:1で結びつけたものではない名前を使うことができます。典型的には「存在しないフォントに対して代わりのフォントを提供する」です。(MSフォントファミリーをLinuxにインストールすることはEULAに違反します。同一コンピュータ上にあるMSフォントファミリーをコピーせずに使用することに関しては不明瞭です)。Pゴシックを要求された場合、梅ゴシックS5に置き換えるようにするには次のようにします。Pゴシック」という物理名を持つフォントがないことを前提としています。このようなことを実現する方法としてフォント名に対して適用されるフォントを置き換えることができます。</match>test要素によって要求されたフォントとの比較を行います。PGothicを要求されるとぐちゃぐちゃなフォントが表示される場合があるため、置き換えておいたほうが良いかもしれません。フォントの置き換えは必ずしも1:1でおこなうものではありません。要求されたフォントに対して複数のフォントをリストすることができます。このようなことをしなくてもFontConfigは序列を持ったフォントのリストを返します。これを利用して、欧文フォントに対して和文グリフのために和文フォントを追加することようなこともできます。1Cを追加しています。1Cのものが使われます。1Cのものが使われます。</match>すべてのアプリケーションが常にFontConfigのリストを利用するわけではないことに注意してください。LibreOfficeは指定したフォントと同じ物理名を持つフォントが存在する場合、それを優先します。一般的なウェブブラウザなどFontConfigのリストのうち最初ものしか利用しないアプリケーションもあります。ウェブにおいて次のように指定されていたとします。Sansを適用します。Sansは和文グリフをもたないため、和文を表示する必要がある場合これでは十分ではありません。Sansで利用できなかった」という結果を以て次のArialでの表示を試みます。Arialでも表示することはできません。その場合、ウェブブラウザのデフォルトフォントとして指定されているフォントで表示しようとします。DilloやTeXは代替フォントを探すこともしません。指定されたフォントと同じ物理名を持つフォントがなければ表示できない状態になりますし、指定したフォントに含まれないグリフがある場合は表示不能となります。FontConfigのリストを使うのであれば、「最初のフォントだけを使う」ことを利用していくつかの問題を解決できる場合があります。「UIは日本語化されているもののフォントはArialに固定されており、リストを利用しない」アプリケーションです。このようなアプリケーションに対してはArialを和文フォントで置き換えることによりUIの文字化けを解消することができます。</match>このような指定はウェブブラウザにおいても有効です。ArialもしくはHerveticaを和文フォントより前に指定しているウェブサイトは非常に多いため、Arialを置き換えることにより好ましいフォントを使用させることができます。Arialを置き換えるのはリスクが高いと言えます。ArialはUI部品として使われることが多く、そのようなケースにArialのメトリックを前提としていることが珍しくないからです。このような場合においては環境変数$FONTONFIG_FILEを利用すると良いでしょう。これを使用すると/etc/fonts/font.confの代わりに指定されたファイルを使用することができます。標準の設定ファイルはとても多岐にわたっているため、これを使わないのは問題が発生する可能性が高く、すべてを網羅したファイルを作り直すのは大変です。そこで、ここで指定するファイルから標準の設定ファイルを読み込むようにすると良いでしょう。Boldのような名前が設定されている場合があります。ウェイトを含むフォント名が正しく動作しない場合、ウェイトを含むフォント名を定義し、共通のフォントファミリーにウェイトを含んで指定することで解消することができます。</edit></match>逆にフォントファミリ名が異なるものの同一のファミリであるようにstyleにbold体を指定された場合に異なるフォントを使うようにするには条件にウェイトを含めます。Pゴシックを要求されたときに置き換えることができます)。フォントにリストに登場することはありません。Fontをフォント選択のリストに含ませることはできません。Fontを要求すればこの設定が適用されます。これは値を変更した結果も同様で、spacingが100でないフォントに対してspacing=100を設定しても選択時点でmonospaceフォントとして扱われることはありません。アンチエイリアスとサブピクセルレンダリングアンチエイリアスを有効にするには次のようにします。</edit></match>サブピクセルレンダリングを有効にするには次のように設定します。</edit></match>指定しているのはレンダリングモードであり、液晶の光源の並びに合わせた設定を行います。定数noneを指定するとサブピクセルレンダリングは行われなくなります。これらの設定は条件付きマッチの中で指定できますから、特定のフォントに対して有効・無効を切り替えることもできます。サブピクセルレンダリングを行う場合、色縁を減らすLCDフィルタを使うことが推奨されています。lcdnone(無効)です。ほとんどのケースではlcddefaultを使い、にじみが強く感じる特定のフォントに対してlcdlightを使うのが良いでしょう。ヒンティング普通はフォントに含まれるバイトコードインタプリタヒンティングを利用するのが望ましいでしょう。</edit></match>故にautohinterは無効にしたいはずです。</edit></match>ヒントスタイルはヒンティングをどのように適用するかを制御します。hintslightはグリフ形状の維持を、hintfullはピクセルグリッドへの整列を優先し、hintmediumはその中間です。デフォルトはhintslightであり、現在はこの設定が好まれます。実際に私が使用している$XDG_CONFIG_HOME/fontconfig/conf.d以下の設定です。10-syslocal.confGitによる共有の対象外としている、マシン固有の設定。Pゴシックなどの置換え。</match></fontconfig>70-basicfonts.confsans-serifやserifに対する設定。serif体の正式な名称はsans-serifですが、一部sansを指定するアプリケーションもあります。Serifを指定した場合sansフォントを使用しようとします。そのため、sans-serifだけでなくsansも設定しています。</match></fontconfig>80-complete-kanaonly.confかなだけグリフを持つ和文フォントの補完用。</match></fontconfig>80-complete-latin-monospace.conf欧文等幅フォントのための和文設定。monospaceフォントはスペーシング100(monospace)になっていますが、和文フォントを使うことで常に単一幅であるとみなすことができなくなるため、spacingに90(dualspace)を設定しています。version='1.0'?>80-complete-latin-sans.conf欧文sans-serifフォントに和文フォントを補完するための設定。</match></fontconfig>80-complete-latin-serif.conf欧文serifフォントの和文フォントの補完。UIのメトリック互換設定です。</match></fontconfig>フォントのインストールシステムのフォントは/usr/share/fonts以下にインストールされます。再帰的に検索されるため、ディレクトリを作っても構いません。サイトローカルなフォントを全ユーザー向けにインストールしたい場合、/usr/local/share/fontsが標準で検索されるディレクトリとして含まれています。ユーザーのフォントディレクトリは$HOME/.fontsです。システムにない独自のフォントを使用する場合はこのディレクトリに放り込むことになります。フォントソフトウェアはWindowsやMacのTTF/TTC/OTFファイルが利用できます。JISで書かれている場合があるため、問題を避けるには可能であればMac向けフォントを利用したほうが良いでしょう。和田研フォント和田研漢字分科会が開発したフォントファミリーです。アウトラインの自動生成技術を用いたアウトラインフォントです。1995年と古くから存在するため、Linux以前のUnix環境では重用されてきました。東雲フォント古川泰之氏が開発したビットマップフォントです。ビットマップフォントが主流だった時代にWindowsにおけるMSフォントのように標準的にUnix環境で使用されていたフォントです。東風フォント古川泰之氏が開発し、2000年から2003年にかけて使われていたアウトラインフォントです。様々なフォントを基に開発されており、そのうちひとつである渡邊フォントがタイプバンク明朝のグリフを流用したことが発覚し、この問題から配布停止となりました。グリフに少し癖があり、あまり美しくないとされています。さざなみフォント東風フォントの公開停止に伴って、問題のあるグリフを差し替えたフォントです。一時期は東風代替フォント(kochi-subst)と呼ばれていました。Linuxで利用できるフリーなフォントを確保することが第一目的だったため、差し替えられたグリフの完成度はあまり高くありません。現在も標準日本語フォントとして使われる場合もありますが、日本語をネイティブにサポートするディストリビューションにおいてはグリフの美しさの問題から標準和文フォントとしてはそれほど採用されていません。Projectによって開発されている丸ゴシック体です。非常に人気が高く、海外ディストリビューションでも標準の和文フォントとして採用される傾向があります。等幅のVLゴシックはコーディングフォントとしても人気です。TakaoフォントIPAによってリリースされているフォントファミリーで、制作はタイプバンクが担当しています。日本語の文書を作成するために開発されたフリーなフォントであり、日本語の文書作成流儀に従ったexフォントや、名前や地名のための代替文字を含むmj明朝も含んでいます。Teamが派生・公開しているものです。M+フォント森下浩司氏が開発する丸ゴシック体フォントです。ビットマップフォント、カーソルフォント、アウトラインフォントが用意されています。ディストリビューションに標準で採用されることは稀ですが、VLゴシックのベースとなっていることから比較的見かける機会はあり、日本人のLinuxユーザーには人気もあります。MigMixitouhiro氏によって開発されている、M+フォントにIPAフォントを合成させたフォントです。Miguはより積極的に調整されており、「半濁点が大きい」「1cフォントは和文プロポーショナル」「グリフが非常によく似た和文グリフの区別」などがあります。1M/2MフォントはコーディングフォントとしてLinuxに限らず非常に人気が高く、オリジナルのM+より広く使われています。RictyM+フォントとInconsolataを合成したフォントです。コーディングフォントとして人気が高く、Windowsユーザーにも広く使われています。JPAdobeとGoogleが共同開発するフォントです。Fontフォントファミリーとして、AdobeはSourceフォントファミリーとして公開しています。Proフォントを採用しています。これまでLinuxの世界ではなかったほど商業フォント的な高品位フォントであり、急激にシェアを伸ばしています。Proフォントを公式に組み合わせたもので、「日本語2文字に対してアルファベット3文字」という幅設定と広い行間が特徴です。梅フォント蓬莱和多流氏が開発したフォントファミリーです。Windowsで標準採用されているMSフォントファミリーとメトリック互換になっています。オープンなライセンスを採用しているものの、標準採用されることは稀です。明朝体の漢字グリフは花園明朝のものを使用しており、極めて多くのグリフを保持しています。さわらびフォント戸越フォントの作者あるmshio氏が開発するフォントです。フリーな和文フォントは現在IPAフォントあるいはM+フォントをベースにしているフォントが多い中、完全にオリジナルのグリフとなっています。収録グリフ数はやや少なめです。ゴシックより明朝のほうがグリフ数が少なく、さわらび明朝の収録グリフは20180515で2759となっています。この欠点を補う派生フォントとしてみずき明朝(さわらび明朝とIPA明朝を合成)がありますが、こちらはあまり知られていません。Googlefontsで配布されている和文フォントでもあります。Licenseで提供したフォントです。モトヤが商用フォントとしてリリースするマルベリ及びシーダを基にしています。Googlefontsで「小杉ゴシック」及び「小杉丸ゴシック」として配布されています。アンチエイリアス設定が反映されません。-Dsun.java2d.opengl=trueを渡します。これを環境変数$_JAVA_OPTIONS_に設定するのが一般的です。Inch)といいます。Windowsでは96dpiという暗黙の了解がありましたが、現在は実際はそのような値からはかけ離れています。一般的なモニタのおおよそのDPIは次のようになっています。140Linuxシステムでは設定されていなければ96DPIであるとみなします。フォントサイズ「ポイント」は物理的な大きさであり、いくつ点があればその物理的な大きさに達するかはDPIを元に計算します。1ポイントは0.0138889インチです。10ポイントは0.138インチ、1インチで96の点を描くのですから、10ポイントの領域には13.248個の点、ピクセルは半端な数は書けないので13個のピクセルを描くことになります。この計算によって、DPIが設定されていない限り、物理的にどのようなモニターを使用していたとしても13ピクセルを描画します。XPS13の4kモデルを使用していたとします。「10ポイント」と思って描いた13ピクセルは、実際は0.04インチまで縮小してしまいます。0.04インチとは2.88ポイントです。10ポイントの文字ならば小さいものの読める文字ですが、2.88ポイントは虫眼鏡が必要かもしれません。これは、誤ったDPI設定の結果「10ポイント」と指定して描画した文字は2.88ポイントで描画されるということです。これを修正するために、最近のデスクトップ環境ではフォントのDPIを設定することができるようになっています。これは、FontConfigの設定に反映する形で行います。実のところ問題は決して文字だけではありません。実際のDPIが設定されたDPIの倍になれば、アイコンもボタンもその面積は1/4になるということです。これはとても不便です。120DPI程度までであればそれほど苦労しませんが、140DPIにもなると「明らかに小さい」と感じます。DPIの設定はX.Orgも保有しています。Channel)によって正しい画面サイズを自動検出しますが、できていない場合も多々あります。resolutionひとつの方法として、X.Orgの設定ファイルとしてディスプレイのサイズを記述するという方法があります。millimetersEndSectionあるいは、Xrandrツールを使用できる環境であれば、これを使う方法もあります。(永続化するためにはXProfileとして記載します。331GtkやQtなどにおいて物理的な寸法で記述されているパーツはこのDPI変更によって自動的にスケールされます。Qtにおいてはこれだけで問題を解決することができます。Gtk3は$GDK_SCALE及び$GDK_DPI_SCALE環境変数で調整できますが、あまりうまくいきません。UIコンポーネントを設定する$GDK_SCALEは2倍、3倍という単位でしか調節できません。デスクトップ環境によってはFontConfigで明示的にDPIを指定する必要がある場合もあります。このようなHiDPIサポートはWindowsよりMacより先にLinuxが行っているにも関わらず、あまり快適に動作しません。Plasmaを使用するという方法です。Plasmaを使用する場合は次の方法でほとんどの環境で良い動作を得られます。greeterのサイズは別問題となります。greeterの設定を変更してこの問題を改善できます。gtk-greeterを使用している場合は、/etc/lightdm/lightdm-gtk-greeter.confにxft-dpi=331のように記述を追加します。未来HarfBuzzはHarfBuzz-NGとして再構築を行っています。systemを廃止してWaylandに移行する動きがあります。Waylandはディスプレイへの描画を管理するものであり、ウィンドウの位置や重なりを管理し、適切に重って表示されるようにします。systemのようなものではなく、あくまでディスプレイ上での表示の管理しか行いません。ウィンドウマネージャがグラフィックスハードウェアとのやりとりや、アプリケーションとのやりとりをする際にXを介する構造ではなく直接やりとりをするようになります。キーボードなどの入力ハードウェアの管理もWaylandは行いません。systemのようなロスがなく、優れた応答性と低負荷が期待されています。その仕組み自体はWindowsに近いものです。まともに機能せず、設定も散らばってしまう可能性があります。systemの便利な機能は使えなくなります。Pangoという名前はギリシャ語で「全て」を表すPanに、日本語の「語(Go)」を組み合わせたものです。↩︎こちらはペルシャ語です。↩︎これはある程度正しい主張です。判別しやすさはアンチエイリアスがない方が良好であり、300ppiあるようなディスプレイではアンチエイリアスはないほうが読みやすく疲れにくいという主張があります。300ppiあってもアンチエイリアスは有効であるほうが美しく感じるということも分かっています。日本語のページであるにも関わらず、欧文フォントであるArialを指定しているのは、非常に「悪い」ことだと考えられます。“網膜の解像度は300DPIなので、300DPIに達するとドットを視認できなくなる”という説があります。実際はディスプレイと目の距離もありますし、そうはいきません。300DPI前後に到達すると非常になめらかに見えるのは事実です。Linuxにおいてフォントの取り扱いは鬼門とされてきました。現在は複雑さは緩和されていますが、Windowsなどと比べれば設定できる余地も大きく、学ぶべきものがたくさんあります。Yokohama別に表記のない場合、価格は全て税抜きです価格は各種キャンペーン適用の価格ですプライバシーポリシーサイトについてのお問い合わせ:webmaster@mimir.yokohama。