ubuntuusers.de

So, ich habe es jetzt probiert:

nach der Modifikation stehen alle "behandelten" Schriften z.B. auch in gedit und sogar im X-term zur Verfügung. Wie das jetzt vorher war, habe das nie probiert???

Ich hänge jetzt mal den "Beipackzettel" hier an, bitte lies das mal selbst durch, um das zu beurteilen. So, wie ich das verstehe, wird hier eine inzwischen verkümmerte/vernachlässigte Form der Verwaltung von X11-Fonts vervollständigt. Danach sollte es dann hierher zu "Schriften allgemein" gehören?

BTW: den Befehl mkfontscale habe ich übrigens gegenüber der Anleitung um Pfad erweitert - so verstehe ich zumindest die man-page dazu (also Fehler in der Anleitung?):

mkfontscale /usr/share/fonts/type1/gsfonts
mkfontdir /usr/share/fonts/type1/gsfonts

Viele Grüße,
Ingo

EDIT: ich schätze mal, das kann man an Lucid garnicht so verifizieren. Bei neueren Distris gibt es ja praktisch keine xorg.conf mehr und deshalb wurde da viel umgebaut. Jedenfalls ist der beschriebene Weg einer, derabsolute Rückwärts-Kompatibilität gewährleistet. Hier bei Squeeze gibt es für X11-Fonts das Verzeichnis /usr/share/fonts/X11 und die Schriften darin sind alle in den entsprechenden fonts.scale und fonts.dir registriert.

Wie gesagt, da gibts sehr wenig Doku zu.

Gehört vielleicht auch das häufig gemeldete Problem mit Schriftart/Größe in GoogleEarth hierzu???

Ich kenne das Problem und die Lösung nicht. Müsstest du einmal überprüfen und abwägen ob es in diesen Artikel gehört.

march schrieb:

Ich kenne das Problem und die Lösung nicht. Müsstest du einmal überprüfen und abwägen ob es in diesen Artikel gehört.

Tja, so geht es mir auch, zumindest fehlt mir die Detail-Kenntnis wie der X-Server Schriften verwaltet - das ändert sich ja im Moment sehr schnell. Fazit und vermutlich der Hintergrund für diese Notwendigkeit ist:
Wir haben vor einiger Zeit ein Fotobuch mit der DPS-Version 4.8 gemacht. Das klappte unter 32-bit Lucid völlig problemlos und alle Systemschriftarten wurden korrekt eingebunden und verwendet. Die gleiche Fotobuch-Datei *.cpr unter Squeeze-amd64 geöffnet, bot nur ganz wenige Schriftarten (die benutzten wurden vermutlich substiuiert) - entsprechend schlecht war dann die Qualität des Fotobuchs. Farbglanz konnte das Problem nachvollziehen mit Maverick-amd64.

Ich vermute jetzt, daß mit der Version 4.9 das automatische einbinden von Systemschriften aus genanntem Grund komplett entfernt wurde und stattdessen die beschriebene Methode über X11-Fonts genutzt wird.

Es kann also sein, daß die wahre Ursache bei den 64-bit Fonts liegt? Bei 64-bit werden auch die meisten Probleme mit GoogleEarth gemeldet. Tatsache ist jedenfalls, daß dieser Weg funktioniert. Ich kann das auch selbst nicht 100% nachprüfen, da ich kein Maverick-amd64 hier habe - und ein Flag getestet in Squeeze gibt es ja hier nicht 😉

Und ich selbst schreibe ungern einen Beitrag über Sachen, die ich nicht selbst 100% verstehe.

Vielleicht findet sich ja hier Jemand, der sich damit besser auskennt und das ganze beurteilen kann?

Viele Grüße,
Ingo

Hallo,

Vielleicht findet sich ja hier Jemand, der sich damit besser auskennt und das ganze beurteilen kann?

Genau, das wäre gut. Weil der "Eingriff" geht ja schon ein Stück weit tief ins System - und von uns ist sich keiner sicher, ob er wirklich frei von Seiteneffekten ist.

Gruß, noisefloor

noisefloor schrieb:

Hallo,

Vielleicht findet sich ja hier Jemand, der sich damit besser auskennt und das ganze beurteilen kann?

Genau, das wäre gut. Weil der "Eingriff" geht ja schon ein Stück weit tief ins System - und von uns ist sich keiner sicher, ob er wirklich frei von Seiteneffekten ist.

Gruß, noisefloor

Was ich mich vor allem frage ist, ob man in die xorg.conf "Section "Files" jetzt auch alle (default)-Pfade wie sie xset q ausgibt, eintragen muß? Eventuell ist das ja cumulativ und es reicht, die nur die zusätzlichen Pfade anzugeben. Ich selbst habe nur die Fonts unter /usr/share/fonts/X11 + die neuen eingetragen.

Habe noch in einem alten "Kofler" von 2007 gestöbert und dort wird die Methode ebenfalls parallel zu "fontconfig" beschrieben für ältere Programme, welche "fontconfig" nicht kennen (wie hier Farbglanz).

Viele Grüße,
Ingo

Artikel sieht nach allgemeingültig aus, oder?

Hallo,

in dem Artikel fehlt meiner Meinung nach ein Hinweis auf ~/.local/share/fonts

Ich habe gerade sehr lange gebraucht, um auf diesen Order zu stoßen; bzw. um eine Möglichkeit zu finden eine Schrift wieder zu entfernen, die ich durch den Standard-Schriftartenbetrachter in meinem Ubuntu 14.04 installiert hatte.

Robopija schrieb:

in dem Artikel fehlt meiner Meinung nach ein Hinweis auf ~/.local/share/fonts

Der Standardordner fuer Benutzerschriften ist seit Jahren ~/.fonts. Welches Programm kommt auf die obskure Idee, einen anderen Ordner zu benutzen?

Kann es sein, dass ~/.fonts/ seit fontconfig 2.10.1 deprecated ist, und ~/.local/share/fonts neue Standardordner für Benutzerschriften? Siehe: http://cgit.freedesktop.org/fontconfig/commit/?id=8c255fb185d5651b57380b0a9443001e8051b29d

1
2
3
4
5

  <!--
Private font directory
-->
-<dir>~/.fonts</dir>
+<dir prefix="xdg">fonts</dir>

1
2

+ <!-- the following element will be removed in the future -->
<dir>~/.fonts</dir>

Bei mir ist fontconfig 2.11.0 istalliert.

Robopija schrieb:

Kann es sein, dass ~/.fonts/ seit fontconfig 2.10.1 deprecated ist, und ~/.local/share/fonts neue Standardordner für Benutzerschriften?

Ja, sieht so aus: Font configuration 🇬🇧. Aber ab welcher Ubuntu-Version der neue Pfad verwendet wird bzw. zwingend verwendet werden muss, entzieht sich meiner Kenntnis. Soweit ich das testen konnte, koennen bei 14.04 noch beide Ordner benutzt werden.

Der (Übersichts-) Artikel scheint mir teils etwas zu wenig strukturiert. Ich habe gerade versucht, relevante Teile von Schriftarten (dieser Artikel soll aufgelöst werden) nach Schriften zu verfrachten. Allerdings müsste man diesen wohl neu strukturieren und letztlich umschreiben. Was ist hier wirklich wichtig? (Die KDE-Teile erscheinen mir zum Beispiel etwas willkürlich.)

Bei diesem Artikel gibt es mehr zu machen, als ich zunächst gedacht habe. Vermutlich sollte der auch in eine Baustelle. Problem: Ich habe wenig Ahnung von der Materie.

Zwei dringende Anliegen:

1. Meiner Meinung nach (siehe oben) muss der Artikel neu strukturiert werden.

2. Das Beispiel, das Stand jetzt (Revision 973046) noch in Schriftarten (beziehungsweise der entsprechenden Baustelle) ist, sollte wohl noch nach Schriften importiert werden (vielleicht etwas gekürzt).

Zudem muss noch „Unfreie Schriftarten“ erstellt werden.

Hallo kutteldaddeld,

Links auf nicht existierende Wiki-Artikel sind im Live-Wiki nicht erlaubt. Es wäre besser gewesen, wenn du für deine Änderungen auf eine Baustelle gewartet hättest. Ich verschiebe den Artikel jetzt mal entsprechend.

Hallo,

Beforge schrieb:

Es wäre besser gewesen, wenn du für deine Änderungen auf eine Baustelle gewartet hättest.

Das ist richtig. Kann ja aber mal passieren. In dem Fall könnten wir die Änderungen auch einfach zurücksetzen und dann den diff in die Baustelle packen.

kutteldaddeldu schrieb:

Zudem muss noch „Unfreie Schriftarten“ erstellt werden.

Sowas kannst du auch einfach selbst machen: Wiki/Wikiartikel anlegen

Viele Grüße!