Schriftrendering im Munin nach Systemupgrade

Dalai

Grand Admiral Special
★ Themenstarter ★
Mitglied seit
14.06.2004
Beiträge
7.372
Renomée
240
Standort
Meiningen, Thüringen
Hallo Leute,

ich wende mich mal wieder vertrauensvoll an euch, in der Hoffnung, dass hier jemand meine Wissenslücken füllen kann. Aktuell teste ich mit diversen Distros in verschiedenen Versionen rum, und bei allen gibt es dasselbe Problem: nach einem Systemupgrade ist das Rendering von Schriften in den Munin-Graphen verändert und unscharf, kurz gesagt grausam. Beispielhaft hab ich zwei Grafiken angehängt, eine von Ubuntu 16.04 und eine von Ubuntu 18.04. Es betrifft sowohl den Titel der Graphen als auch die Legende und Achsenbeschriftung, eben alle Teile, in denen Schriften zum Einsatz kommen.

Fakt ist, es liegt an keinem der folgenden Pakete:
Code:
munin munin-common munin-node rrdtool ttf-dejavu ttf-dejavu-core ttf-dejavu-extra fonts-dejavu fonts-dejavu-core fonts-dejavu-extra fonts-liberation fonts-ubuntu-font-family-console libfont-ttf-perl
weil diese alle gepinnt sind und damit am Upgrade gehindert werden. Warum ich Munin 1.4 verwende, spielt für das Problem keine Rolle, weil das Schriftbild auch in aktuellen Versionen grausam ist, wie der offizielle Munin-Demo-Server oder auch die Graphen vom Boot selbst zeigen.

Vor einigen Monaten hab ich auch mit diversen Einstellungen in /etc/fonts/conf.d/ rumgespielt, aber habe nicht das alte Schriftbild erreichen können.

Die Frage ist: Wo soll ich suchen, was soll/kann ich testen? Es hat irgendwas mit Hinting, Kantenglättung oder Subpixel-Rendering oder sowas zu tun, und muss entweder irgendwas im System an sich oder im Perl sein. Aber was?

Grüße
Dalai
 

Anhänge

  • memory-day_16.04.png
    memory-day_16.04.png
    21 KB · Aufrufe: 9
  • memory-day_18.04.png
    memory-day_18.04.png
    30,4 KB · Aufrufe: 9

Berniyh

Grand Admiral Special
Mitglied seit
29.11.2005
Beiträge
4.991
Renomée
150
Die Fonts selbst sind da irrelevant (bzw. stimmt das nicht ganz, aber ist hier jetzt nicht wichtig), sondern wenn dann freetype bzw. fontconfig. Das sind die Pakete die für das Font-Rendering und Management zuständig sind.
Gut möglich, dass sich da etwas geändert hat.
Es gibt bei freetype auch eine build Option für "harfbuzz" Support, was ein Modus für Font Hinting ist, welcher auf irgendeiner Technologie von Apple basiert.
iirc gab es da immer mal auch wieder Fragezeichen, ob das Probleme bzgl. Patente o.ä. geben könnte und könnte daher sein, dass die Distribution das in einem Update deaktiviert hat.
Nach einem Paket mit freetype-harfbuzz o.ä. zu suchen könnte durchaus auch helfen, ich bin mir gerade nicht sicher, ob man den Teil separat installieren kann.
bzw. harfbuzz als Paket gibt es sicherlich separat, aber ich meine den freetype Teil. ;)

Ansonsten würde ich mal .config/fontconfig/fonts.conf umbenennen um zu sehen ob es eine Usereinstellung ist die da Probleme macht.
Würde mich aber schon etwas wundern.

Edit: zu Ubuntu gibt es doch bestimmt auch eine Wikiseite die Fonts und Darstellung von Fonts thematisiert. Könnte hilfreich sein. ;)
 

Dalai

Grand Admiral Special
★ Themenstarter ★
Mitglied seit
14.06.2004
Beiträge
7.372
Renomée
240
Standort
Meiningen, Thüringen
Code:
$ aptitude search "freetype|harfbuzz"
p   freetype2-demos                         - FreeType 2 Demonstrationsprogramme
v   gir1.2-freetype2-2.0                    -
p   gir1.2-harfbuzz-0.0                     - OpenType text shaping engine (GObject introspection data)
p   libfont-freetype-perl                   - Modul zum Lesen von Schriftdateien und zur Darstellung von Glyphen mit FreeType2
i A libfreetype6                            - Schrift-Engine FreeType 2 - Laufzeitbibliothek
p   libfreetype6-dev                        - »FreeType 2«-Schrift-Engine, Entwicklungsdateien
p   libharfbuzz-bin                         - OpenType-Engine zur Formgebung von Text (Dienstprogramm)
p   libharfbuzz-dev                         - OpenType-Engine zur Formgebung von Text (Entwicklungsdateien)
p   libharfbuzz-doc                         - Documentation files for the HarfBuzz library
p   libharfbuzz-gobject0                    - OpenType text shaping engine ICU backend (GObject library)
p   libharfbuzz-icu0                        - OpenType text shaping engine ICU backend
i A libharfbuzz0b                           - OpenType text shaping engine (shared library)
p   libisfreetype-java                      - Java wrapper for FreeType font handling library
p   libisfreetype-java-doc                  - Javadoc API description for isFreeType
Die beiden installierten Pakete sind auch auf dem alten Ubuntu vorhanden.

Ein Umbenennen der /etc/fonts/fonts.conf hat nichts geändert (außer Meckerei vom Fontconfig "Cannot load default config file"). Auch ein Einspielen des Verzeichnisses /etc/fonts/conf.d (und /etc/fonts/fonts.con) aus einem Ubuntu 14.04 ändert nichts.

Klar gibt's im Ubuntuusers-Wiki Artikel über Schriften etc., aber die beziehen sich vor allem (wenn nicht gar ausschließlich) auf die Darstellung in Browsern, im Display-/Window-Manager usw. - nichts für einen Server relevantes. Aktuell ist mir völlig unklar, was alles betroffen ist bzw. ob noch andere Dinge außer Munin ein geändertes Schriftbild zeigen. Leider fällt mir keine (installierte) Komponente ein, die Text in Bilder druckt/schreibt wie Munin das bei den Graphen tut.

Grüße
Dalai
 

Berniyh

Grand Admiral Special
Mitglied seit
29.11.2005
Beiträge
4.991
Renomée
150
Ich meinte .config/fontconfig/fonts.conf in deinem Nutzerverzeichnis. ;)

Das Meiste sollte unabhängig von der Distribution funktionieren.
Leider ist die Seite auch ein bisschen überladen.
 

Dalai

Grand Admiral Special
★ Themenstarter ★
Mitglied seit
14.06.2004
Beiträge
7.372
Renomée
240
Standort
Meiningen, Thüringen
Es geht doch um Munin, das per Cron in Intervallen aufgerufen wird, und auch wenn das als Nutzer munin läuft, so hat der nur ein leeres Home. Mit anderen Worten: nur die globale Config spielt eine Rolle. Und wie ich schon sagte: selbst die aus einem älteren Ubuntu ändert am Schriftbild nichts.

Die Frage ist, ob es einen schnelleren Weg gibt, als alle Optionen nach und nach durchzutesten (und anschließend 5 Minuten zu warten)?

Grüße
Dalai
Doppelposting wurde automatisch zusammengeführt:

Kurze Zeit später weiß ich woran es liegt: FreeType 2.7 hat das Rendering geändert und dabei mehr oder weniger ClearType standardmäßig aktiviert. Im verlinkten Arch-Wiki und auf dieser Seite hab ich dann gesehen, dass man es wieder zurückdrehen kann. Ich hab die Ausführungen erst ignoriert, weil ich nicht wusste, wie man Angaben für (die bei mir nicht existierende) /etc/profile.d/freetype2.sh mit Munin zusammenbringen soll. Dann fiel mir aber ein, wie es doch geht, also hab ich kurzerhand einfach die Zuweisung der Variable
Code:
FREETYPE_PROPERTIES="truetype:interpreter-version=35 cff:no-stem-darkening=1 autofitter:warping=1"
in /etc/cron.d/munin vor die Ausführung des Befehls munin-cron gesetzt, und siehe da: ordentliches Schriftrendering! Siehe auch Bild im Anhang. Im direkten Vergleich mit den Graphen aus Ubuntu 16.04 sind zwar noch leichte Unterschiede in der Ausrichtung der Zeilen in Y-Richtung zu erkennen, aber Hauptsache endlich wieder scharfe Schriften auf den Graphen.

Kann man diese Zuweisung irgendwie global machen, so dass sie für alles gilt und nicht immer ins cron.log geschrieben wird? Ich hab keine Lust Beschwerden zu bekommen, weil die Schriften in PDFs auf einmal anders oder nicht mehr ordentlich aussehen (auf dem Server läuft täglich ein Job, der PDFs bearbeitet, also leere Seiten entfernt und die Dateien kleinrechnet).

[EDIT]
Bild angehängt und einige Ausführungen ergänzt
[/EDIT]

Grüße
Dalai
 

Anhänge

  • memory-day_18.04#4.png
    memory-day_18.04#4.png
    27,5 KB · Aufrufe: 5
Zuletzt bearbeitet:

Berniyh

Grand Admiral Special
Mitglied seit
29.11.2005
Beiträge
4.991
Renomée
150
Huh? Da muss man doch auch erst mal drauf kommen. Freetype 2.7 ist doch steinalt. *noahnung*
Wenn es in /etc/profile.de/freetype2.sh steht, dann ist es eigentlich global, zumindest für alle Nutzer deren login shell bash ist (was dann vermutlich bei dir der Fall ist, bei mir wäre es zsh und ich müsste das wo anders reinschreiben).
munin hat vermutlich nicht bash als login shell (wenn es denn überhaupt einen eigenen Nutzer hat) und liest diese Datei daher nicht.

Ich hab übrigens nichts dergleichen auf meinem System gesetzt, d.h. bei mir wird v40 von dem Interpreter genutzt (das ist der aktuelle Standard).
Ich finde das Rendering aber eigentlich überall super und deutlich besser als unter Windows 10 (was auf meinem Arbeitslaptop läuft und mich regelmäßig fast zum Kotzen verleitet).
Also evtl. gibt es doch auch einen anderen Weg die Schriften schöner zu machen?
 

Dalai

Grand Admiral Special
★ Themenstarter ★
Mitglied seit
14.06.2004
Beiträge
7.372
Renomée
240
Standort
Meiningen, Thüringen
Huh? Da muss man doch auch erst mal drauf kommen. Freetype 2.7 ist doch steinalt. *noahnung*
Es ging doch nur darum, zu erklären, welche Version die Änderung eingeführt hat. Ubuntu 18.04 hat FreeType 2.8.1 und Debian/Raspbian 10 hat 2.9.1. Vor dem Systemupgrade war's irgendwas vor 2.7.

munin hat vermutlich nicht bash als login shell (wenn es denn überhaupt einen eigenen Nutzer hat) und liest diese Datei daher nicht.
Munin nutzt den Nutzer munin und der hat als Shell /usr/sbin/nologin. Daher nutzen alle Orte nix, die irgendwas mit Shell oder Home zu tun haben. Am besten wäre es, wenn man die Einstellung irgendwo im /etc/fonts/conf.d unterbringen könnte. Aktuell hab ich sie in /etc/environment gepackt, und es funktioniert für Munin (über den Rest kann ich noch nichts sagen).

Ich hab übrigens nichts dergleichen auf meinem System gesetzt, d.h. bei mir wird v40 von dem Interpreter genutzt (das ist der aktuelle Standard).
Ich finde das Rendering aber eigentlich überall super [...]
Stimmst du mir denn zu, dass das Schriftrendering im zweiten Graphen des OP grausig aussieht, vor allem das matschige und verschwommene kleine M und die Nullen, die aussehen, als wären sie irgendwie durchgestrichen? Mir ist bewusst, dass Schriftrendering sowohl subjektiv als auch vom Monitor usw. abhängt, aber die Munin-Graphen sind ja bereits fertig erzeugt.

Also evtl. gibt es doch auch einen anderen Weg die Schriften schöner zu machen?
Ich bin offen, Dinge zu testen, aber ich bezweifle, dass etwas anderes als das Zurückschalten auf v35 hilft.

Grüße
Dalai
 

Berniyh

Grand Admiral Special
Mitglied seit
29.11.2005
Beiträge
4.991
Renomée
150
Es ging doch nur darum, zu erklären, welche Version die Änderung eingeführt hat. Ubuntu 18.04 hat FreeType 2.8.1 und Debian/Raspbian 10 hat 2.9.1. Vor dem Systemupgrade war's irgendwas vor 2.7.
Es war nur meine Verwunderung darüber, dass du so alte Versionen davon nutzt. ;)
Aber ok, Debian und Ubuntu sind auch komisches Zeug, da verwundert das nicht. :P
Munin nutzt den Nutzer munin und der hat als Shell /usr/sbin/nologin. Daher nutzen alle Orte nix, die irgendwas mit Shell oder Home zu tun haben. Am besten wäre es, wenn man die Einstellung irgendwo im /etc/fonts/conf.d unterbringen könnte. Aktuell hab ich sie in /etc/environment gepackt, und es funktioniert für Munin (über den Rest kann ich noch nichts sagen).
Wenn es systemweit läuft, dann wird es vermutlich über einen Dienst gestartet?
In dem Fall wäre es vermutlich am sinnvollsten das in die entsprechende systemd unit zu packen, zumindest wenn du munin spezifisch treffen willst.
Eine generelle, systemweite Einstellung ist schon eher schwierig. /etc/environment sollte zwar von den meisten shells etc. gelesen werden, aber eigentlich wird die Datei auch automatisch erstellt, insofern vermute ich, dass du die Einstellung wieder verlieren wirst.
Oft gibt es – distributionsspezifische – Mechanismen um darin Einträge erstellen zu lassen (so, dass sie dann auch da drin bleiben bzw. immer wieder da drin landen), aber wie das bei Ubuntu oder Debian ist kann ich dir leider nicht sagen.
In meine Distribution (Exherbo) packt man dafür Dateien in /etc/env.d aus denen ein Skript die environment generiert.
Stimmst du mir denn zu, dass das Schriftrendering im zweiten Graphen des OP grausig aussieht, vor allem das matschige und verschwommene kleine M und die Nullen, die aussehen, als wären sie irgendwie durchgestrichen? Mir ist bewusst, dass Schriftrendering sowohl subjektiv als auch vom Monitor usw. abhängt, aber die Munin-Graphen sind ja bereits fertig erzeugt.
Ist nicht nur vom Monitor etc. abhängig, sondern auch noch von der Schriftart. Aber ja, das ist sicher nicht optimal.
Ich bin offen, Dinge zu testen, aber ich bezweifle, dass etwas anderes als das Zurückschalten auf v35 hilft.
In dem Arch Wiki Artikel stand ja schon einiges, das eine oder andere könntest ja zumindest mal testen um zu sehen, ob es in die richtige Richtung geht. ;)
 

Dalai

Grand Admiral Special
★ Themenstarter ★
Mitglied seit
14.06.2004
Beiträge
7.372
Renomée
240
Standort
Meiningen, Thüringen
Es war nur meine Verwunderung darüber, dass du so alte Versionen davon nutzt. ;)
Ich nutze das, was die Distribution zur Verfügung stellt, und solange das so tut, wie es soll bzw. wie ich mir das vorstelle, ist es mir fast immer egal, welche Version das ist. Hier in diesem Fall war es so, dass die neuere Version nicht die bessere war/ist.

Wenn es systemweit läuft, dann wird es vermutlich über einen Dienst gestartet?
Nein, es sind an der Stelle keinerlei Dienste beteiligt. OK, ich erkläre doch mal grob, wie Munin funktioniert. Es gibt einen Munin-Master, der standardmäßig alle 5 Minuten die Daten von allen gewünschten Munin-Nodes einsammelt und daraus Graphen und HTML-Seiten generiert. Auf den Nodes läuft logischerweise je ein Dienst, der Master startet seine Aktionen per Cronjob, wie ich auch schon in Beitrag #5 schrieb. Hier mal der Auszug aus der Crontab vom Munin-Master
Code:
*/5 * * * *     munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi
Für das Schriftbild spielt logischerweise ausschließlich der Munin-Master eine Rolle.

Daher sind jegliche Überlegungen in Richtung Dienst, Systemd-Unit o.ä. sinnlos. Außerdem will ich das Schriftrendering systemweit wieder zurückdrehen, weil es sich systemweit geändert hat; ich will also die Änderung nicht nur im Munin haben sondern auch im GhostScript (sofern das auf FreeType zurückgreift) und allen anderen Programmen.

Eine generelle, systemweite Einstellung ist schon eher schwierig. /etc/environment sollte zwar von den meisten shells etc. gelesen werden, aber eigentlich wird die Datei auch automatisch erstellt, insofern vermute ich, dass du die Einstellung wieder verlieren wirst.
Das könnte passieren, wobei ich bisher in vielen Jahren noch nie erlebt habe, dass diese Datei abseits vom Systemupgrade angefasst wurde. Hast du eine bessere Idee, wo ich die Variable (systemweit) unterbringen kann?

Ist nicht nur vom Monitor etc. abhängig, sondern auch noch von der Schriftart.
Grundsätzlich stimmt das zwar, aber hier wird ja immer dieselbe Schrift in derselben Größe gerendert - DejaVu Sans (in normal und Mono) in Größe 7.

In dem Arch Wiki Artikel stand ja schon einiges, das eine oder andere könntest ja zumindest mal testen um zu sehen, ob es in die richtige Richtung geht. ;)
Wie ich schon schrieb, habe ich die Übernahme der Fontconfig vom Ubuntu 14.04 getestet. Aber auch mit anderen Dingen wie hinting, lcdfilter, antialiasing usw. hab ich rumprobiert, aber entweder haben die das Schriftbild gar nicht geändert, noch verschlimmert oder nur verändert (antialiasing), aber keine der Änderungen hat das alte Schriftbild zurückgebracht - bis auf das Zurückdrehen des truetype-interpreters auf v35.

Grüße
Dalai
 

Berniyh

Grand Admiral Special
Mitglied seit
29.11.2005
Beiträge
4.991
Renomée
150
Hier mal der Auszug aus der Crontab vom Munin-Master
Code:
*/5 * * * *     munin if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi
Für das Schriftbild spielt logischerweise ausschließlich der Munin-Master eine Rolle.
Ist schon eine ganze Weile her, dass ich mich damit beschäftigt habe, aber ggf. könnte man die FREETYPE Variable auch da reinschreiben, so dass munin-cron damit aufgerufen wird.
Schon klar, dass das jetzt nicht das ist was du willst, nur als Erklärung dazu. ;)
Daher sind jegliche Überlegungen in Richtung Dienst, Systemd-Unit o.ä. sinnlos.
Nicht unbedingt. Genau für sowas wurden ja auch systemd timer eingeführt, welche mehr Flexibilität als crontab bieten.
Siehe z.B.:
Da kann man dann natürlich auch wieder eine programm-spezifische Environment übergeben.

Generell könnte der Einsatz von systemd Funktionalität hier schon auch von Vorteil sein, so könnte man es so konfigurieren dass die Umwandlung nicht in regelmäßigen Zeitabständen getriggert wird, sondern dann wenn neuer Input auftaucht. Nur mal als Beispiel.
Wie dem auch sei, das ist jetzt nur als erklärende Ergänzung gemeint, musst jetzt nicht damit anfangen, dein Ansatz funktioniert ja.
Hast du eine bessere Idee, wo ich die Variable (systemweit) unterbringen kann?
Für Debian/Ubuntu leider nein. :(
Das muss dir jemand beantworten der die Distribution(en) nutzt.
 
Oben Unten