LibreOffice (Writer): Falsche Schriftdarstellung bei deaktivierter Kantenglättung nach Update auf 7.4.5-1 in Manjaro KDE

Hallo,

bei der o.g. Version bin ich mir nicht ganz sicher, ob diese die erste nicht mehr funktionierende Version von LibreOffice Still war. Die letzte funktionierende Version war auf jeden Fall 7.3.7-3, auf der ich jetzt wieder bin nach Downgrade und anschließender Update-Sperre.

Vermutlich bin ich einer der ganz wenigen, der sein System mit deaktivierter Kantenglättung betreibt, so dass das Problem anscheinend noch niemandem aufgefallen ist!
Ich mag halt einfach eine schlanke Schriftdarstellung, bzw. tue mich anders herum mit diesen in meinen Augen fett wirkenden geglätteten Schriften schwer!

Apropos, mein System ist:
Manjaro KDE, Kernel 515 LTS (aber auch Kernel 61 LTS macht keinen Unterschied)

Die Kantenglättung habe ich wie folgt deaktiviert: Systemeinstellungen → Erscheinungsbild → Schriftarten

Wie sich das Problem äußert, zeige ich vielleicht am besten mal anhand von Schreenshots am Beispiel einer bereits vorinstallierten Schrift DejaVu Sans in 12 pt.

Schriftdarstellung bis Version 7.3.7-3:
DejaVu_Sans_LO_Flatpak

Schriftdarstellung danach:
DejaVu_Sans_LO_Still

Ach ja, in LO habe ich auch unter Extras → Optionen → Ansicht → die Kantenglättung deaktiviert, damit das zur Systemeinstellung passt:

Da ich mich nicht gut mit Linux auskenne, versuche ich das Problem durch möglichst einfache Ausschlussverfahren einzugrenzen.
So habe ich rausgefunden: Das Problem existiert auf drei unterschiedlichen Systemen (alle mit Manjaro KDE):

  1. Hauptrechner
  2. Laptop
  3. Virtuelle Maschine (VirtualBox), neu aufgesetzt und nur das nötigste installiert und konfiguriert, um das Szenario testen zu können.

Auf allen Systemen zeigt sich:

  • Aktuelle LO-Versionen (Fresh & Still) und aus den Offiziellen Repositories zeigen die falsche Schriftdarstellung.
  • Aktuelle Appimage-Version zeigt die Problematik ebenfalls.
    .
  • LO als Flatpak (z.Zt. 7.5.4.2, aber auch schon frühere Versionen; ich beobachte das Problem ja schon ein paar Monate) zeigt die Problematik NICHT! Stellt die Schrift korrekt dar, so wie das alte LO-Still 7.3.7-3!
  • OpenOffice (z.Zt. 4.1.14-1) aus dem AUR zeigt die Problematik ebenfalls nicht!

Was ich daraus schließe: Leider nicht viel! Nur, dass es eigentlich nicht an einem evtl. “verbastelten” Hauptrechner liegen kann, weil zwei komplett andere Systeme (eins auf anderer Hardware, eines virtuell) die Problematik auch aufzeigen.
Also kann man sich zumindest eine mühsame Fehlersuche auf meinem System sparen, und ich gehe stattdessen davon aus, dass alle, die ihr System so betreiben (würden), die gleiche Problematik haben müssten!?

Es müsste also irgendeine Änderung in LO sein (denn immerhin sind LO-Fresh, -Still und Appimage betroffen), die mit Manjaro KDE bei deaktivierter Kantenglättung diese Auswirkung produziert. Das könnte auch erklären, warum OpenOffice davon nicht betroffen ist: Wahrscheinlich, weil das update-technisch hinterher hinkt und auch nicht zwangsläufig die gleichen Änderungen einpflegt.

Aber warum tanzt dann LO als Flatpak aus der Reihe (und ist nicht betroffen)?

Hallo @Roger1 :wink:

Ich verwende kein KDE, aber wenn ich den Test unter Sway mit Flatpak, libreoffice-still und libreoffice-fresh mache, also Kattenglättung komplett ausstelle, dann komme ich nicht auf dein Ergebnis.

Bei mir sieht es dann so aus (ohne Kantenglättung und ohne Bildschirmschriftarten glätten):

Und so mit Kantenglättung und mit Bildschirmschriftarten glätten:

Augenscheinlich 100 % identisch und wenn man reinzoomt, erkennt man auch die Glättung. Das stelle ich bei allen verfügbaren Libreoffice Versionen fest. Kann aber auch sehr wohl sein, dass das Deaktivieren unter Wayland nicht verfügbar ist. :man_shrugging:

Empfindest du diese Schrift als störend?

Wenn ich das Gleiche mache, wie du in KDE, aber eine VM, dann bekomme ich das:

Sorry, aber ich kein Problem mit Antialiasing/Kantenglättung nicht verstehen. Vielleicht sieht es ja jemand anders.

Ja, bei dir funktioniert das Deaktivieren der Kantenglättung dann offenbar nicht.
Du kannst ja sehen, dass die Schrift in meinem obigen Beispiel (dem ersten von den beiden) deutlich schlanker ist.

Und, ja, wie schon erwähnt, empfinde ich die Schriften mit aktivierter Glättung als störend dick. Ich bilde mir auch tatsächlich ein, dass darunter die Lesbarkeit leidet.
Ich nehme das aber gerne als Spleen auf meine Kappe und möchte jetzt hier bitte keine Diskussion über Pro und Contra Schriftartenglättung lostreten.

Ich hab das schon unter Windows immer so genutzt, aber da wurde es einem zum Schluss hin ja auch immer schwerer bis hin zu unmöglich gemacht, dass systemweit, soz. “flächendeckend” durchzusetzen.

In Manjaro KDE habe ich mich gefreut, dass einem da relativ problemlos die Möglichkeit/Freiheit dazu gelassen wird!

Jetzt muss ich auch dazu sagen, dass DejaVu Sans nicht unbedingt die schönste Schrift bei deaktivierter Kantenglättung ist.

Aber ich hatte das Thema schon mal in einem anderen Forum angesprochen und mich da aber u.a. dann mit den Schriftarten verzettelt.
Dort hatte ich nämlich erwähnt, dass ich nachinstallierte Windows-Schriftarten nutze, und da kam dann die Frage auf, wie ich die denn überhaupt installiert hätte und wie diese korrekt zu installieren seien … bis sich dann nach einigen Beiträgen herausstellte, dass die ganze Diskussion um die Installationsart unnötig war, weil man das Ganze auch einfach mit einer vorinstallierten Schrift wie DejaVu Sans zeigen kann.

Tatsächlich nutze ich aber aktuell auf meinem Hauptsystem in LO als Standard-Schrift Arial und ansonsten systemweit und fürs Internet (Firefox) Verdana.
Diese Schriften sehen ohne Kantenglättung nochmal gleichmäßiger und schöner aus und sind für meinen Geschmack halt einfach super lesbar.
Aber wie gesagt, die Geschmäcker sind verschieden!

Ist nicht Kantenglättung (Anti-Aliasing), ist Hinting.

edit:

https://adamfontenot.com/post/libreoffice_7.4_has_a_new_approach_to_text_rendering

3 Likes

Ja sehe ich, aber wesentlich “klotziger”.

Alles gut, ich werde Deine Präferenzen nicht infrage stellen, nur anmerken, dass Antialiasing bei Schriften durch Aufkommen von LCDs/LEDs nötig wurde, was bei CRTs kein Problem war. Jetzt mal rein historisch gesehen. Ausschalten von Antialiasing würde ich heute schon als Legacy-Feature betrachten, dass irgendwann verschwindet.

Ah super. Da kennt sich jemand aus! Gleich mal geschaut und jetzt versteht man es auch:

Also braucht @Roger1 Hinting ohne Antialiasing. Hinting wird bei vielen Schriften automatisch gemacht und bei kommerziellen wird das händisch gemacht, was eine besser Qualität hat.

Anscheinend werden die automatisch “gehinteten” Schriftzeichen von Libreoffice nicht richtig interpretiert. Wenn man Antialiasing verwendet, sieht man das einfach nicht xD Gut, hab was dazu gelernt :wink:

1 Like

Kann sein, dass sich das nicht wie gewünscht ab/anstellen lässt. Dann hilft nur, eine Bitmap-Schrift in der passenden Grösse[*] zu finden die dem Geschmack nicht allzu sehr widerspricht.

[*] Kenne Kannte ich nur für winzige Schriften, so 5…8 pt, die anders nicht mehr lesbar sind.

Oh – da gibt’s mehr als ich dachte:

1 Like

Danke für deine ausführliche Recherche!

Puh, das ist aber auch kompliziert!

Also konkret habe ich meine oben gezeigten Ergebnisse mit folgenden Einstellungen erzielt:

Kantenglättung: Aktiviert
Bereich von der Kantenglättung ausschließen: 8 - 15 pt
Hinting: Leicht (oder z.B. auch Vollständig - macht keinen Unterschied; nur “keine” macht den Text fett)

Exakt das selbe Ergebnis erziele ich aber auch, wenn ich dann das Häkchen rausnehme bei Kantenglättung. Wohlgemerkt mit Version 7.3.x ODER LO Flatpak.
Dann werden die beiden anderen Sachen ausgegraut und sind nicht mehr anwählbar/verstellbar, weshalb ich dachte, dass sie dann auch keine Funktion/Auswirkung mehr haben.

Deshalb dachte ich: Primär ist das Ganze von der Funktion Kantenglättung abhängig.
Und deshalb dachte ich auch für mein Schreiben hier: Ich vereinfache das Ganze etwas und schreibe: “Kantenglättung deaktiviert”. Aber so einfach ist es im Detail dann wohl doch nicht!

So wie ich den ersten Beitrag in dem von dir verlinkten Thread Change in font hinting between LibreOffice 7.3 and 7.4 (Linux) - English - Ask LibreOffice verstanden habe, nutzt der User grundsätlich Hinting, also auch für den Bereich von 8 -15 pt. Das würde auch erklären, warum seine Beispiele (auch DejaVu Sans) anders aussehen, als meine. Nur bei ihm war es eben vor dem Update auf 7.4 trotzdem auch dünner (aber nicht so dünn wie in meinem BSP) und nachher ist es bei ihm dicker, während es bei mir irgendwie “zerfleddert” und nur vereinzelt dick aussieht.

In dem letzten von dir verlinkten Artikel steht was davon, dass LO, ab Vers. 7.4 jetzt die Subpixel-Positionierung geändert hätte (wenn ich das richtig verstanden habe; mein englisch ist schlecht, mein technisches Verständnis auch, und die Google-Übersetzung tut vermutlich noch ihr Übriges!). Jetzt weiß ich nicht, ob damit die Einstellmöglichkeiten in den Systemeinstellungen “Subpixel-Rendering” (Keine, RGB, BGR …) gemeint ist. Da habe ich vor Jahren zum letzten Mal dran rum gespielt und bin dann zu der Erkenntnis gelangt, dass ich das besser auf RGB stehen lasse und nicht mehr anfasse.

Aber wie auch immer, es lässt sich also festhalten: In LO ist was ab Version 7.4 bezüglich Schriftdarstellung verändert worden und das ist wohl ziemlich nahe liegender Weise genau das, weshalb ich nun die genannten Probleme habe.

Da lässt sich dann offenbar nichts machen. Außer, dass man vielleicht mal nach alternativen Schriften (Stichwort: Bitmap-Schriften) sucht, damit habe ich mich bis jetzt ehrlich gesagt noch nicht beschäftigt. U.a. auch deshalb, weil ich halt ganz viele schon existierende Dokumente habe, bei denen müsste ich ja dann überall die Schrift ändern! Und inwieweit andere Schriften dann zum Ausdrucken z.B. für einen Brief taugen, müsste man dann auch erst mal sehen. Da war z.B. Arial halt ein guter Kompromiss, für mich sowohl für die Ansicht am Bildschirm, als auch für den Ausdruck.

Komisch bleibt aber auch, dass die aktuelle LO Flatpak Version (auch jenseit 7.4) immer noch funktioniert wie die alte LO Version 7.3 aus den Repos.

Tja, ist die Frage, was mach ich dann jetzt?!

Also diese “zerfledderte” Darstellung geht gar nicht. Aber als Alternative dann jetzt systemweit die Kantenglättung zu aktivieren (bzw. den Bereich 8 - 15 pt nicht mehr davon ausnehmen) und überall fette Schriften haben, wäre auch ein herber Schlag für mich.

Im Moment tut es ja zum Glück die Flatpak Version, aber da man nicht weiß, wieso, weiß man auch nicht, wie lange noch!

Eine weitere Alternative wäre evtl. noch der Umstieg auf OpenOffice, da tritt das Problem ja auch (noch!) nicht auf.

Allerdings habe ich mit OpenOffice wieder andere Probleme:

  1. Werden meine Dokumente (odt) als nicht kompatibel angezeigt.
    Wie sich herausgestellt hat, hat das wohl etwas mit der “ODF-Formatversion” (Optionen → Laden/Speichern → Allgemein) zu tun.
    LibreOffice ist auf “1.3 erweitert (empfohlen)” eingestellt und das gibt es bei OpenOffice (noch) gar nicht. Wenn man etwas mit 1.2 nimmt, geht es! Das müsste ich dann halt bei jedem Dokument einmal ändern (und ich habe viele Dokumente!).
  2. habe ich die GUI nicht auf deutsch umgestellt gekriegt.

Auf welches Pferd würdet ihr setzen, LO als Flatpak oder OpenOffice? :slight_smile:

Ich persönlich konnte keinen Unterschied feststellen, aber es kann ja sein, dass es bei dir einen Effekt hat:

SAL_USE_VCLPLUGIN=gen SAL_SKIA=raster libreoffice

Das nutz die generische GUI, wie unter Windows (also kein GTK oder QT) und raster scheint hier der Software Renderer (keine GPU) für SKIA zu sein.

Habe ich hier herausgenommen: QA/Erste Schritte bevor Sie einen Fehler melden - The Document Foundation Wiki

Zwischen Flatpak und Native kann durchaus das Benutzerprofil ausschlaggebend sein. Da Flatpak in $HOME/.var/app/org.libreoffice.LibreOffice/config/libreoffice speichert und Native in $HOME/.config/libreoffice/

Starte mal im abgesicherten Modus:

libreoffice --safe-mode
flatpak run org.libreoffice.LibreOffice --safe-mode 

Oder einen “Schelltest”:

soffice -env:UserInstallation=file:///tmp/test

Die GUI wird dann anders (grob gesagt: Symbole und Schrift viel kleiner) dargestellt, aber auf die Textschrift an sich hat es keine Auswirkungen.

Witzig, genau da war ich gerade auch angekommen! :slight_smile:
Mal vorsichtig formuliert: Ich wollte gerade versuchen, mich darauf vorzubereiten, diesen Fehler evtl. zu melden! Aber da gibt es noch einiges zu tun … u.a. versuchen mehr Klarheit zu gewinnen, wie, bzw. von was der Fehler jetzt überhaupt genau kommt. Denn irgendwie ist das in den Systemeinstellungen unstimmig! Wenn ich z.B. zuerst “Hinting: keine” wähle und dann das Häkchen wegnehme bei Kantenglättung (und somit Hinting ausgegraut und nicht mehr anwählbar ist!) erziele ich ein anderes Ergebnis, als wenn ich z.B. “Hinting: Leicht” wähle und dann das Häkchen bei Kantenglättung wegnehme.
Oder anderes Beispiel:
Kantenglättung: Häkchen gesetzt
Bereich von der Kantenglättung ausschließen (8 - 15 pt): Häkchen gesetzt
Hinting: Leicht
Ist mit diesen Einstellungen jetzt der Bereich von 8 - 15 pt auch vom Hinting ausgeschlossen? Müsste ja eigentlich, denn beides (Bereich von der Kantenglättung ausschließen & Hinting) wird ausgegraut, wenn ich Kantenglättung deaktiviere, ist aber anscheinend doch nicht so!

Also ich schaffe es kaum, da durchzublicken!! Und dementsprechend war ich in der Vergangenheit froh, eine funktionierende Konfiguration gefunden zu haben, in der meine Schriften schön gleichmäßig schlank sind.

Das habe ich auch gerade mal versucht und dabei auch alles vollständig zurückgesetzt, hat aber nichts geändert. Hatte ich auch schon fast so erwartet, weil ich beides in der VM neu installiert hatte und bis auf die automatische Rechtschreibeprüfung (deaktiviert) nichts geändert hatte.
Das mit den unterschiedlichen Speicherorten der Benutzerprofile war mir bekannt, deshalb lassen sich ja auch die “normal” installierte Version und die Flatpak-Version parallel betreiben.

Auch der “Schnelltest” ergab keine Änderung.

Wenn ich nachher etwas mehr Zeit habe, wollte ich mich wie gesagt nochmal eingehender versuchen herauszufinden, in welcher (Systemeinstellung-) Konfiguration die Schrift wie aussieht, um das geg. bei einer Fehlermeldung an LibreOffice zu berücksichtigen …

Dauerhaft Flatpak oder OpenOffice – würde ich nicht drauf setzen. Die ziehen irgendwann nach, und Du stehst wieder vor demselben Problem. Es sei denn, es hätte im Repo-LO bis dahin eine Verbesserung in Deinem Sinne gegeben. Dann kannst Du auch bei Repo-LO 7.3.x bleiben, ausser Du hast Sicherheitsbedenken.

Ich sehe für Dich folgende Möglichkeiten

  • Lebe mit der neuen Darstellung. Unser visuelles System ist ungeheuer anpassungsfähig[*], es kann sein dass Dir das in wenigen Wochen nicht mehr auffällt[**]. (Ähnlich wie beim Umstellen auf anderes Tastaturlayout. Am ersten Tag fluchst Du bei jedem Buchstaben, am zweiten hakt’s ständig, am dritten geht’s schon besser… nach drei Wochen flutscht es und nach vier kannst Du zwischen Layouts hin-und-her-wechseln ohne dass es stört.) Nur Mut!

  • Wenn Du die Schriften global umstellen willst: Die .odt-Dateien sind komprimierte Bündel von Dateien, in denen Du (vermutlich! ich hab nicht probiert ob es ohne Nebenwirkungen geht – frag das WWW, und mach BACKUPS) die Schriftnamen global ersetzen kannst. Das wäre die Lösung wenn Du Schriften findest die für Druck und Bildschirm akzeptabel sind.[***]

  • Schreib’ (oder lass schreiben) zwei Makros. Eins dass alle Schriften im Dokument speichert und dann das Dokument auf Deine Bildschirmschrift umsetzt, und eins, dass die Schriften zurücksetzt wenn Du fertig bist. Wenn Du mit Dokumentvorlagen/Formatvorlagen arbeitest ist das noch einfacher.
    Formatvorlagen laden
    Dann für jedes Makro ein Button in die Toolbar. Ist zwar noch umständlich, aber Du siehst immer den aktuellen Zustand des Dokuments. Automatisches Umstellen beim Speichern oder Drucken ginge natürlich auch.

[*] Ende der 1800er haben Leute mit Prismenbrillen experimentiert, die Oben und Unten vertauschten. Tag 1 war katastrophal, Tag 2 ging schon so einiges, ab Tag 3 konnten Sie den Alltag bewältigen. Umstellung zurück ebenso, mglw. schneller (iirc, lange her dass ich das gelesen habe). Im Experiment mit Hühnern das gleiche Ergebnis. In den 1940ern hat jemand Rechts und Links vertauscht, so dass die Tiefeninformation invertiert war. Nach 4 Wochen ist er damit mit dem Motorrad durch Innsbruck gefahren.

[**] Allerdings gibt es Abweichungen vom neurotypischen Hirn, mit denen das nicht (so leicht) möglich ist. Musst Du probieren und eine Weile durchhalten.

[***] Persönlicher Tip: Ich nutze für Bildschirm und Druck die Charter (Charter ICT, XCharter, …; installiert habe ich otf-xcharter via pacman) (und im Browser die verwandte Charis SIL (ttf-charis-sil) mit mehr Durchschuss), die sieht gut aus und ist gut lesbar, und passt zu meinem… äh… ‘Stil’ wäre vielleicht zuviel gesagt…

======================

Zu Deinen Tests:
Hast Du mal versucht, die “DPI für Schriften erzwingen” Option zu setzten? K.A. was das bringt, aber Versuch macht kluch.

Jetzt ist mein Senf aufgebraucht. Lass’ wissen wie es ausgeht, und schreib ggf. die Lösung dazu! Schönen Sonntag!

Ein paar neue Erkenntnisse:

Jetzt habe ich mir gerade mal testweise MX Linux KDE in der virtuellen Maschine installiert und dort dann aber erst mal festgestellt, dass LibreOffice zwar schon vorinstalliert ist, aber (nach Update) in Version 7.0.4.4! Und das funktionierte mit deaktivierter Kantenglättung dann auch erwartungsgemäß einwandfrei (denn bis 7.3.x sollte es ja funktionieren).

Dann bin ich auf die Idee gekommen, mir dort mal die Appimage-Version (Fresh Standard 7.5.4.2) runterzuladen. Und um sicherzugehen, dass auch vom Benutzerprofil her nichts durcheinander geht, weil das Appimage nämlich den gleichen Profilordner wie die vorinstallierte Version nutzt, habe ich den bereits vorhandenen Ordner “4” umbenannt.
Dann habe ich die Appimage-Version gestartet und siehe da, sie stellt die Schrift auch richtig dar!

Also muss es doch ein Problem speziell mit Manjaro (KDE) sein!? :confused:

Ich war schon kurz davor bei LibreOffice einen Bug-Report zu erstellen, aber ich weiß nicht wie sinnvoll das ist, wenn das Problem ausschließlich bei Manjaro auftritt.
Die werden dann vielleicht sagen, ich soll mich an die Manjaro-Entwickler wenden …

Jetzt habe ich heute noch mal mit den Systemeinstellungen bezüglich Kantenglättung und Hinting rumgespielt, um meine Ergebnisse zu verifizieren - und kriege plötzlich andere Ergebnisse! Warum weiß ich nicht. Ich werde noch wahnsinnig, ich kriege da einfach keine Linie rein! :face_with_spiral_eyes: :frowning_face: :rage:
Zumindest einmal habe ich gemerkt, dass ein Speichervorgang offenbar nicht “gegriffen” hat, dieser funktionierte erst, nachdem ich zwischendurch noch etwas anderes vorübergehend verändert hatte, bspw. “Bereich von der Kantenglättung ausschließen”, Häkchen raus, speichern, Häkchen wieder rein, speichern, erst jetzt war die vorher geänderte Hinting-Einstellung offenbar mit übernommen worden!
Vielleicht funktionieren die Änderungen manchmal sogar erst 100% nach einem oder mehreren Neustarts - wer weiß das schon so genau!
Jedenfalls macht es das nahezu unmöglich rauszukriegen, was jetzt genau welche Auswirkungen hat, zumal es soviele Kombinationen gibt!
Die Bilderserie oben kann man dann jedenfalls zum Teil vergessen!

Natürlich ist mir bewusst (kriegt man ja sogar angezeigt), dass die getätigten Änderungen sich nicht auf laufende Programme auswirken. Oder anders ausgedrückt: Wenn ich überprüfen will, ob/wie sich eine Einstellung auf das Schriftbild in LO auswirkt, muss ich LO schließen und nochmal neu starten und ein geg. vorher gespeichertes Dokument wieder neu öffnen.

Also Stand ist jetzt: Es hat doch etwas mit dem Hinting zu tun.
Man kann entweder die Kantenglättung grundsätzlich aktiviert lassen, und dann aber einen gewünschten Bereich von der Kantenglättung ausnehmen oder man kann die Kantenglättung ganz abschalten.
Aber es MUSS IN JEDEM FALL irgendeine Art von Hinting ausgewählt sein, um das gewünschte schlanke gleichmäßige Schriftergebnis zu erzielen. Ob nun “Leicht”, “Mittel” oder “Vollständig” ist anscheinend egal (ich habe da noch keinen Unterschied festgestellt).
Das Problem ist, wenn man die Kantenglättung grundsätzlich deaktiviert, kommt man an die Hinting-Einstellung nicht mehr dran, weil diese dann ausgegraut ist. In diesem Fall muss man also VOR dem Deaktivieren der Kantenglättung darauf achten, dass irgendeine Art von Hinting ausgewählt ist.

Das alles habe ich getestet mit der aktuellen Flatpak-Version (die ja immer noch funktioniert und mit der richtigen Kantenglättung/Hinting-Kombination das gewünschte Schriftbild liefert) in der virtuellen Maschine.

So, und da vermutlich kein Mensch mehr weiß, worum es eigentlich geht: Mit einer der aktuellen LO-Versionen aus den offiziellen Repos (oder auch der Appimage-Version) kriegt nach den entsprechend getätigten Kantenglättungs und Hinting-Einstellungen nun nicht mehr das gewünschte Schriftbild, sondern wie eingangs gezeigt, diese zerfledderte, ausgefranzt und ungleichmäßig dick wirkende Schrift.

Nur damit wir die Informationen komplettieren. Was für einen Bildschirm hast du?

Das installieren

pamac build edid-decode-git

und dann das im Terminal ausführen:

 find -L /sys/class/drm/ -maxdepth 2 -type f -iname "*edid" -exec edid-decode "{}" \; 2>/dev/null 

Es sucht die EDID Datei (aus deinem Monitor) und decodiert es.

Bitte die Ausgabe mal hier posten. Danke.

Hmm, aus irgendeinem Grund klappt das nicht:

pamac build edid-decode-git 
Vorbereitung...
Überprüfe edid-decode-git Abhängigkeiten...
Abhängigkeiten werden aufgelöst...
Interne Konflikte werden überprüft...

Zu erstellen (1):
  edid-decode-git  r621.8a8d673-1    AUR


Build-Dateien bearbeiten : [e] 
Transaktion anwenden ? [e/j/N] j

Klone edid-decode-git Build-Dateien...
Generiere edid-decode-git Informationen...
==== AUTHENTICATING FOR org.manjaro.pamac.commit ====
Eine Authentifizierung ist erforderlich, um Pakete zu installieren, aktualisieren oder zu entfernen
Authenticating as: john
Password: 
==== AUTHENTICATION COMPLETE ====

Erstelle edid-decode-git...
==> Erstelle Paket: edid-decode-git r621.8a8d673-1 (Di 04 Jul 2023 23:24:52 CEST)
==> Prüfe Laufzeit-Abhängigkeiten...
==> Prüfe Buildtime-Abhängigkeiten...
==> Empfange Quellen...
  -> Klone das edid-decode git Repo...
Klone in Bare-Repository '/var/tmp/pamac-build-john/edid-decode-git/edid-decode' ...
remote: Enumerating objects: 2567, done.
remote: Counting objects: 100% (2567/2567), done.
remote: Compressing objects: 100% (837/837), done.
remote: Total 2567 (delta 1722), reused 2567 (delta 1722)
Empfange Objekte: 100% (2567/2567), 738.42 KiB | 5.68 MiB/s, fertig.
Löse Unterschiede auf: 100% (1722/1722), fertig.
==> Überprüfe source Dateien mit md5sums...
    edid-decode ... Übersprungen
==> Entferne existierendes $srcdir/ Verzeichnis...
==> Entpacke Quellen...
  -> Erstelle Arbeitskopie des edid-decode git Repos...
Klone nach 'edid-decode'...
Fertig.
==> Beginne pkgver()...
==> Aktualisierte Version: edid-decode-git r654.a31e680-1
==> Beginne build()...
/var/tmp/pamac-build-john/edid-decode-git/PKGBUILD: Zeile 23: make: Kommando nicht gefunden.
==> FEHLER: Ein Fehler geschah in build().
    Breche ab...
pamac install base-devel

Uups, ich hatte gedacht, base-devel hätte ich schon installiert! (Hatte ich aber wohl mit der VM verwechselt.)

   ~  find -L /sys/class/drm/ -maxdepth 2 -type f -iname "*edid" -exec edid-decode "{}" \; 2>/dev/null 
EDID of '/sys/class/drm/card0-HDMI-A-1/edid' was empty.
edid-decode (hex):

00 ff ff ff ff ff ff 00 26 cd 37 61 01 01 01 01
20 1c 01 03 80 34 1d 78 2a 49 95 a5 56 52 9f 27
0d 50 54 bf ef 80 d1 c0 b3 00 a9 40 a9 c0 95 00
95 0f 81 80 71 4f 02 3a 80 18 71 38 2d 40 58 2c
45 00 09 25 21 00 00 1e 00 00 00 ff 00 30 0a 20
20 20 20 20 20 20 20 20 20 20 00 00 00 fd 00 32
4c 0f 55 12 00 0a 20 20 20 20 20 20 00 00 00 fc
00 50 4c 32 34 37 34 48 0a 20 20 20 20 20 01 94

02 03 22 f2 4f 9f 14 13 12 11 16 15 90 05 04 03
02 07 06 01 23 09 07 01 83 01 00 00 65 03 0c 00
10 00 02 3a 80 d0 72 38 2d 40 10 2c 45 80 09 25
21 00 00 1f 01 1d 80 d0 72 1c 16 20 10 2c 25 80
09 25 21 00 00 9f 01 1d 00 bc 52 d0 1e 20 b8 28
55 40 09 25 21 00 00 1e 8c 0a d0 90 20 40 31 20
0c 40 55 00 09 25 21 00 00 18 2a 44 80 a0 70 38
27 40 30 20 35 00 09 25 21 00 00 1a 00 00 00 33

----------------

Block 0, Base EDID:
  EDID Structure Version & Revision: 1.3
  Vendor & Product Identification:
    Manufacturer: IVM
    Model: 24887
    Serial Number: 16483009
    Made in: week 32 of 2018
  Basic Display Parameters & Features:
    Digital display
    Maximum image size: 52 cm x 29 cm
    Gamma: 2.20
    DPMS levels: Off
    RGB color display
    First detailed timing is the preferred timing
  Color Characteristics:
    Red  : 0.6455, 0.3359
    Green: 0.3222, 0.6220
    Blue : 0.1542, 0.0517
    White: 0.3134, 0.3291
  Established Timings I & II:
    IBM     :   720x400    70.081663 Hz   9:5     31.467 kHz     28.320000 MHz
    DMT 0x04:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
    Apple   :   640x480    66.666667 Hz   4:3     35.000 kHz     30.240000 MHz
    DMT 0x05:   640x480    72.808802 Hz   4:3     37.861 kHz     31.500000 MHz
    DMT 0x06:   640x480    75.000000 Hz   4:3     37.500 kHz     31.500000 MHz
    DMT 0x08:   800x600    56.250000 Hz   4:3     35.156 kHz     36.000000 MHz
    DMT 0x09:   800x600    60.316541 Hz   4:3     37.879 kHz     40.000000 MHz
    DMT 0x0a:   800x600    72.187572 Hz   4:3     48.077 kHz     50.000000 MHz
    DMT 0x0b:   800x600    75.000000 Hz   4:3     46.875 kHz     49.500000 MHz
    Apple   :   832x624    74.551266 Hz   4:3     49.726 kHz     57.284000 MHz
    DMT 0x10:  1024x768    60.003840 Hz   4:3     48.363 kHz     65.000000 MHz
    DMT 0x11:  1024x768    70.069359 Hz   4:3     56.476 kHz     75.000000 MHz
    DMT 0x12:  1024x768    75.028582 Hz   4:3     60.023 kHz     78.750000 MHz
    DMT 0x24:  1280x1024   75.024675 Hz   5:4     79.976 kHz    135.000000 MHz
    Apple   :  1152x870    75.061550 Hz 192:145   68.681 kHz    100.000000 MHz
  Standard Timings:
    DMT 0x52:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
    DMT 0x3a:  1680x1050   59.954250 Hz  16:10    65.290 kHz    146.250000 MHz
    DMT 0x33:  1600x1200   60.000000 Hz   4:3     75.000 kHz    162.000000 MHz
    DMT 0x53:  1600x900    60.000000 Hz  16:9     60.000 kHz    108.000000 MHz (RB)
    DMT 0x2f:  1440x900    59.887445 Hz  16:10    55.935 kHz    106.500000 MHz
    DMT 0x30:  1440x900    74.984427 Hz  16:10    70.635 kHz    136.750000 MHz
    DMT 0x23:  1280x1024   60.019740 Hz   5:4     63.981 kHz    108.000000 MHz
    DMT 0x15:  1152x864    75.000000 Hz   4:3     67.500 kHz    108.000000 MHz
  Detailed Timing Descriptors:
    DTD 1:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (521 mm x 293 mm)
                 Hfront   88 Hsync  44 Hback  148 Hpol P
                 Vfront    4 Vsync   5 Vback   36 Vpol P
    Display Product Serial Number: '0'
    Display Range Limits:
      Monitor ranges (GTF): 50-76 Hz V, 15-85 kHz H, max dotclock 180 MHz
    Display Product Name: 'PL2474H'
  Extension blocks: 1
Checksum: 0x94

----------------

Block 1, CTA-861 Extension Block:
  Revision: 3
  Underscans IT Video Formats by default
  Basic audio support
  Supports YCbCr 4:4:4
  Supports YCbCr 4:2:2
  Native detailed modes: 2
  Video Data Block:
    VIC  31:  1920x1080   50.000000 Hz  16:9     56.250 kHz    148.500000 MHz (native)
    VIC  20:  1920x1080i  50.000000 Hz  16:9     28.125 kHz     74.250000 MHz
    VIC  19:  1280x720    50.000000 Hz  16:9     37.500 kHz     74.250000 MHz
    VIC  18:   720x576    50.000000 Hz  16:9     31.250 kHz     27.000000 MHz
    VIC  17:   720x576    50.000000 Hz   4:3     31.250 kHz     27.000000 MHz
    VIC  22:  1440x576i   50.000000 Hz  16:9     15.625 kHz     27.000000 MHz
    VIC  21:  1440x576i   50.000000 Hz   4:3     15.625 kHz     27.000000 MHz
    VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz (native)
    VIC   5:  1920x1080i  60.000000 Hz  16:9     33.750 kHz     74.250000 MHz
    VIC   4:  1280x720    60.000000 Hz  16:9     45.000 kHz     74.250000 MHz
    VIC   3:   720x480    59.940060 Hz  16:9     31.469 kHz     27.000000 MHz
    VIC   2:   720x480    59.940060 Hz   4:3     31.469 kHz     27.000000 MHz
    VIC   7:  1440x480i   59.940060 Hz  16:9     15.734 kHz     27.000000 MHz
    VIC   6:  1440x480i   59.940060 Hz   4:3     15.734 kHz     27.000000 MHz
    VIC   1:   640x480    59.940476 Hz   4:3     31.469 kHz     25.175000 MHz
  Audio Data Block:
    Linear PCM:
      Max channels: 2
      Supported sample rates (kHz): 48 44.1 32
      Supported sample sizes (bits): 16
  Speaker Allocation Data Block:
    FL/FR - Front Left/Right
  Vendor-Specific Data Block (HDMI), OUI 00-0C-03:
    Source physical address: 1.0.0.0
  Detailed Timing Descriptors:
    DTD 2:  1920x1080   50.000000 Hz  16:9     56.250 kHz    148.500000 MHz (521 mm x 293 mm)
                 Hfront  528 Hsync  44 Hback  148 Hpol P
                 Vfront    4 Vsync   5 Vback   36 Vpol P
    DTD 3:  1920x1080i  50.000000 Hz  16:9     28.125 kHz     74.250000 MHz (521 mm x 293 mm)
                 Hfront  528 Hsync  44 Hback  148 Hpol P
                 Vfront    2 Vsync   5 Vback   15 Vpol P Vfront +0.5 Odd Field
                 Vfront    2 Vsync   5 Vback   15 Vpol P Vback  +0.5 Even Field
    DTD 4:  1280x720    50.000000 Hz  16:9     37.500 kHz     74.250000 MHz (521 mm x 293 mm)
                 Hfront  440 Hsync  40 Hback  220 Hpol P
                 Vfront    5 Vsync   5 Vback   20 Vpol P
    DTD 5:   720x576    50.000000 Hz   5:4     31.250 kHz     27.000000 MHz (521 mm x 293 mm)
                 Hfront   12 Hsync  64 Hback   68 Hpol N
                 Vfront    5 Vsync   5 Vback   39 Vpol N
    DTD 6:  1920x1080   74.972503 Hz  16:9     83.894 kHz    174.500000 MHz (521 mm x 293 mm)
                 Hfront   48 Hsync  32 Hback   80 Hpol P
                 Vfront    3 Vsync   5 Vback   31 Vpol N
Checksum: 0x33  Unused space in Extension Block: 3 bytes
EDID of '/sys/class/drm/card0-HDMI-A-3/edid' was empty.
EDID of '/sys/class/drm/card0-DP-1/edid' was empty.

Nein, nicht notwendig. Bis 7.3 OK, 7.4 problematisch, 7.5 OK. Kann sein, dass das Problem nur in 7.4 vorliegt und in 7.5 korrigiert wurde. Dann ist es unabhängig vom “Vertriebsweg”.

Wenn Du Lust hast, kannst Du die Change History oder Version History daraufhin durchgehen, vielleicht ist das da aufgeführt.

Das stimmt so auch nicht.

LO Fresh (offizielle Repos), Version 7.5.3-2 → betroffen
LO Fresh Appimage, Version 7.5.4-2 → betroffen
LO Fresh Flatpak , Version 7.5.4-2 → nicht betroffen

Alles bezogen auf Manjaro KDE. In MX Linux KDE wie gesagt funktionierte die gleiche Appimage-Version!

Aber ich beobachte das Problem ja wie gesagt schon seit Monaten und kann daher sagen, dass ALLE Versionen größer 7.3.7-3 betroffen waren (in Manjaro KDE), mit Ausnahme eben des Flatpaks.

PS: Habe zwei meiner vorherigen Beiträge bearbeitet, bzw. den einen mit den ewig vielen Screenshots, die sich dann ja nach erneuter Prüfung z.T. als doch nicht aussagefähig herausgestellt haben, gelöscht. Das war zu verwirrend und unübersichtlich!

Das ist eine solide Grundlage für einen Bug-Report.

Respekt übrigens wie Du Dich da reinhängst.

Die Frage ist, wo ich das am besten melde?

Bei LO könnte man sagen: Da die aktuellen Versionen (Appimage bei MX Linux und Flatpak bei Manjaro) funktionieren, KANN es also grundsätzlich funktionieren. Daher liegt das Problem nicht bei uns.

Bei Manjaro könnte man sagen: Wenn es nur die Versionen aus unseren offiziellen Repos wären, dann läge das Problem bei uns, aber die Appimage-Version (die nicht vom Manjaro-Team gebaut wird) funktioniert ja auch nicht, also muss das Problem bei LO liegen.

Aber falls ich mich an Manjaro wenden würde, wäre das dann die richtige Anlaufstelle?:

Und dort dann vermutlich unter packages → extra?

Wobei damit dann eben nicht adressiert/angesprochen ist, dass das Appimage auch nicht funktioniert.

Aber man kann ja eben auch nicht sagen, dass ALLE Versionen größer 7.3.7.x nicht funktionieren, denn die Ausnahme davon ist wiederum die aktuelle Flatpak-Version, die in Manjaro KDE weiterhin funktioniert!

Eine andere Idee wäre, es an KDE zu melden, aber die könnten dann natürlich auch direkt abwinken, wenn es in MX Linux KDE nicht reproduzierbar ist.

Edit:
Andere Frage: Gibt es noch andere Manjaro Distributionen, bei denen man auch Kantenglättung und Hinting separat systemweit einstellen kann?
Dann könnte ich mir so eine Version mal runterladen und als Live-Image und/oder Installation in der VM ausprobieren, ob da das Problem auch besteht oder ob man das auf (Manjaro) KDE eingrenzen kann.
Ich will jetzt aber nicht unbedingt wahllos eine Manjaro Distri nach der anderen durchprobieren und mich da durch die Systemeinstellungen kämpfen …