18 Das X Window-System #

SUSE Linux Enterprise Server umfasst eine sysconfig-Schicht oberhalb von Fontconfig. Dies ist ein guter Ausgangspunkt, um mit der Schriftkonfiguration zu experimentieren. Zum Ändern der Standardeinstellungen bearbeiten Sie die Konfigurationsdatei /etc/sysconfig/fonts-config. (Alternativ verwenden Sie das YaST-Modul sysconfig.) Führen nach dem Bearbeiten der Datei fonts-config aus:

sudo /usr/sbin/fonts-config

Starten Sie die Anwendung neu, damit der Effekt sichtbar wird. Beachten Sie Folgendes:

Es können verschiedene sysconfig-Variablen geändert werden. Weitere Informationen finden Sie auf der man-Seite man 1 fonts-config oder auf der Hilfeseite des YaST-Moduls sysconfig. Beispiele für Variablen:

In der nachfolgenden Liste finden Sie einige Konfigurationsbeispiele, sortiert von den „am leichtesten lesbaren“ Schriften (stärkerer Kontrast) zu den „ansprechendsten“ Schriften (stärker geglättet).

Bei Fontconfig wird das Konfigurationsformat eXtensible Markup Language (XML) genutzt. Diese wenigen Beispiele sollen keine erschöpfende Referenz darstellen, sondern lediglich einen kurzen Überblick bieten. Weitere Informationen und Anregungen finden Sie in man 5 fonts-conf oder /etc/fonts/conf.d/.

Die zentrale Fontconfig-Konfigurationsdatei ist /etc/fonts/fonts.conf und umfasst unter anderem das gesamte Verzeichnis /etc/fonts/conf.d/. Änderungen an Fontconfig können an zwei Stellen vorgenommen werden:

Benutzerspezifische Änderungen überschreiben die systemweiten Einstellungen.

Anmerkung: Veraltete Benutzerkonfigurationsdatei

Die Datei ~/.fonts.conf ist als veraltet gekennzeichnet und darf nicht mehr verwendet werden. Verwenden Sie stattdessen die Datei ~/.config/fontconfig/fonts.conf.

Jede Konfigurationsdatei muss ein fontconfig-Element enthalten. Die minimale Datei sieht daher wie folgt aus:

<?xml version="1.0"?>
   <!DOCTYPE fontconfig SYSTEM "fonts.dtd">
   <fontconfig>
   <!-- Insert your changes here -->
   </fontconfig>

Falls die Standardverzeichnisse nicht ausreichen, fügen Sie das dir-Element mit dem gewünschten Verzeichnis ein:

<dir>/usr/share/fonts2</dir>

Fontconfig sucht rekursiv nach den Schriften.

Mit dem folgenden Fontconfig-Snippet können Sie die Algorithmen für das Schriftrendering auswählen (siehe Beispiel 18.1, „Festlegen von Rendering-Algorithmen“):

<match target="font">
 <test name="family">
  <string>FAMILY_NAME</string>
 </test>
 <edit name="antialias" mode="assign">
  <bool>true</bool>
 </edit>
 <edit name="hinting" mode="assign">
  <bool>true</bool>
 </edit>
 <edit name="autohint" mode="assign">
  <bool>false</bool>
 </edit>
 <edit name="hintstyle" mode="assign">
  <const>hintfull</const>
 </edit>
</match>

Sie können verschiedene Eigenschaften der Schriften zunächst ausprobieren. Mit dem <test>-Element können Sie beispielsweise die Schriftfamilie (siehe Beispiel), das Größenintervall, den Zeichenabstand, das Schriftformat und andere Eigenschaften testen. Wenn Sie <test> vollständig löschen, werden alle <edit>-Elemente auf sämtliche Schriften angewendet (globale Änderung).

Mit den Regeln in Beispiel 18.2, „Aliase und Ersetzungen von Familiennamen“ wird eine priorisierte Familienliste (PFL) erzeugt. Je nach Element werden verschiedene Aktionen ausgeführt:

Wenn alle Snippets in der Reihenfolge Regel 1 - Regel 2 - Regel 3 ausgeführt werden und der Benutzer „Alegreya SC“ anfordert, wird die PFL wie in Tabelle 18.1, „Erzeugen einer PFL aus Fontconfig-Regeln“ dargestellt erzeugt.

In den Fontconfig-Metriken hat der Familienname die höchste Priorität vor anderen Mustern wie Schriftschnitt, Größe usw. Fontconfig prüft, welche Familie derzeit auf dem System installiert ist. Wenn „Alegreya SC“ installiert ist, gibt Fontconfig diese Schrift zurück. Ansonsten wird „Droid Serif“ angefordert usw.

Gehen Sie vorsichtig vor. Wenn die Reihenfolge der Fontconfig-Snippets geändert wird, gibt Fontconfig unter Umständen andere Ergebnisse zurück (siehe Tabelle 18.2, „Ergebnisse beim Erzeugen der PFL aus Fontconfig-Regeln mit anderer Reihenfolge“).

Anmerkung: Implikation

Betrachten Sie das Alias <default> als Klassifizierung oder Einbeziehung dieser Gruppe (sofern nicht installiert). Wie das Beispiel zeigt, muss <default> stets vor den Aliasen <prefer> und <accept> dieser Gruppe stehen.

Die Klassifizierung <default> ist nicht auf die generischen Aliase serif, sans-serif und monospace beschränkt. Ein ausführlicheres Beispiel finden Sie in /usr/share/fontconfig/conf.avail/30-metric-aliases.conf.

Mit dem nachfolgenden Fontconfig-Snippet in Beispiel 18.3, „Aliase und Ersetzungen von Familiennamen“ wird eine serif-Gruppe erstellt. Jede Familie in dieser Gruppe kann andere Familien ersetzen, wenn eine vorangehende Schrift nicht installiert ist.

<alias>
 <family>Alegreya SC</family>
 <default>
  <family>serif</family>
 </default>
</alias>
<alias>
 <family>Droid Serif</family>
 <default>
  <family>serif</family>
 </default>
</alias>
<alias>
 <family>STIXGeneral</family>
 <default>
  <family>serif</family>
 </default>
</alias>
<alias>
 <family>serif</family>
 <accept>
  <family>Droid Serif</family>
  <family>STIXGeneral</family>
  <family>Alegreya SC</family>
 </accept>
</alias>

Die Priorität ergibt sich aus der Reihenfolge im Alias <accept>. Ebenso können stärkere Aliase <prefer> verwendet werden.

Beispiel 18.2, „Aliase und Ersetzungen von Familiennamen“ wird durch Beispiel 18.4, „Aliase und Ersetzungen von Familiennamen“ ergänzt.

Die erweiterte Konfiguration aus Beispiel 18.4, „Aliase und Ersetzungen von Familiennamen“ würde die folgende PFL-Entwicklung bewirken:

Anmerkung: Auswirkungen.

• Wenn mehrere <accept>-Deklarationen für denselben generischen Namen vorhanden sind, hat die zuletzt geparste Deklaration „Vorrang“. Beim Erstellen einer systemweiten Konfiguration sollten Sie <accept> nach Möglichkeit nicht nach dem Benutzer(/etc/fonts/conf.d/*-user.conf) angeben.

• Wenn mehrere <prefer>-Deklarationen für denselben generischen Namen vorhanden sind, hat die zuletzt geparste Deklaration „Vorrang“. In der systemweiten Konfiguration sollten Sie <prefer> nicht vor dem Benutzer angeben.

• Jede <prefer>-Deklaration überschreibt die <accept>-Deklarationen für denselben generischen Namen. Wenn der Administrator dem Benutzer die Möglichkeit geben möchte, <accept> zu verwenden (nicht nur <prefer>), sollte der Administrator <prefer> nicht in der systemweiten Konfiguration angeben. Die meisten Benutzer beschränken sich jedoch lediglich auf <prefer>, sodass dies keine negativen Auswirkungen haben sollte. <prefer> kommt auch in systemweiten Konfigurationen zum Einsatz.