ubuntuusers.de

Hallo liebe Ubuntu-Gemeinschaft,

ich vermute bei meinem Problem handelt es sich um einen Bug, ich brauche aber Hilfe, herauszufinden an welcher Komponente es liegen könnte.

Folgende Situation: Ich habe Dateien im Svg-Format. Darin ist die Schriftart Linux Biolinum in Verwendung. Über viele Jahre wurden diese Dateien einwandfrei dargestellt. Sicher bin ich mir, dass es zumindest vor einem Jahr im März 2020 noch in Ordnung war. Damals habe ich über Inkscape pdf-Dateien daraus erstellt, die nach wie vor so dargestellt werden, wie sie sollen (eingebettete Schriften). Wenn ich die svg-Dateien heute in Linux öffne, dann werden die Unicode-Zeichen für die Sternzeichen (die nur in sehr wenigen Schriftarten enthalten sind) ersetzt durch sehr unpassende Zeichen aus einer anderen Schrift (in meinem Fall: Noto Color Emoji), obwohl die Zeichen in der Linux Biolinum schon immer enthalten waren und nach wie vor sind.

Meine bisherigen Beobachtungen zeigen, es betrifft viele Programme gleichzeitig und nicht nur in Ubuntu, sondern in meinem Fall habe ich die selbe Situation in Arch Linux und zum Teil in Windows 10, im Detail:

• Linux (getestet Ubuntu Live-System 20.04 und ein aktuelles Arch Linux mit Gnome 3): die betroffenen Svg-Dateien in Firefox geöffnet zeigen die fälschlich ersetzten Symbole für die Sternzeichen; Inkscape versucht die fälschlich ersetzten Symbole anzuzeigen, kann aber die bunten Emoji der Noto Color Emoji nicht anzeigen und fällt auf die Anzeige von normalen Buchstaben zurück (auch aktuelle Pdf-Exporte zeigen dieses Verhalten); verwende ich die Linux Biolinum in LibreOffice, dann ist aber alles in Ordnung.

• Windows 10: Firefox und Inkscape zeigen auch in Windows die falschen Zeichen, nur ist es aufgrund anderer installierter Schrften auch eine andere Schrift, der die Zeichen entnommen werden, diesmal eine Schrift, die auch Inkscape anzeigen kann, damit ist die Erscheinung in beiden Programmen identisch aber falsch. Google Chrome und Microsoft Edge zeigen dagegen die Svgs nach wie vor sauber mit allen Zeichen der Linux Biolinum an.

Es liegt nicht an der Schrift, denn es sind auch alle anderen Schriften betroffen, die die fraglichen Zeichen enthalten (in meinem Fall Linux Libertine, Linux Biolinum, DejaVu Sans, FreeSerif, FreeMono) – immer werden die Zeichen in Linux ersetzt durch Noto Color Emoji.

Auch im Terminal und im Gedit-Texteditor tauchten nun die bunten Symbole der Noto Color Emoji auf und nicht wie früher ganz normale schwarze Zeichen (ich glaube es waren die Zeichen der FreeMono).

Ich habe als Beispiel eine betroffene SVG angehängt und zusätzlich die daraus hergestellten PDFs – die alte Version vom Vorjahr mit der richtigen Darstellung und einen aktuellen Export aus Inkscape mit falscher Darstellung.

Welche Komponente könnte dafür verantwortlich sein, gibt es da eine config in der ich selbst das Verhalten korrigieren kann bzw. wo soll ich einen Bug melden? Ich bin für jeden Hinweis dankbar und hoffe es gibt eine einfache Lösung!

Mit herzlichem Dank im Voraus, Stefan

Jetzt habe ich auch noch Ubuntu 18.04.5 ausprobiert als Live-System. Eigentlich hatte ich die feste Erwartung, hier das Problem nicht vorzufinden – falsche Annahme. Obwohl ich in Arch Linux noch vor einem Jahr die richtige Anzeige hatte, ist die Anzeige im 3 Jahre alten Ubuntu 18.04.5 fehlerhaft – wie kann ich das verstehen.

Es wird noch seltsamer – es gibt einen Unterschied zwischen Ubuntu 20.04 und 18.04: Im Live-System von 18.04 stand die Firefox-Version 79 zur Verfügung und diese zeigte die korrekten Zeichen während Inkscape 0.92 und der Bildbetrachter beide eine falsche Darstellung hatten. Ehrlich gesagt, ich hätte es umgekehrt erwartet, da ja Firefox viel aktueller gehalten wird als die anderen Programme.

Ich hatte bisher pango in Verdacht der Verursacher zu sein, aber in Ubuntu 18.04 ist eine Version von 2017 am laufen, da hatte ich in Arch Linux vor einem Jahr schon eine viel neuere Version in Betrieb.

Leute wie kann ich dem auf den Grund gehen, mir gehen die Ideen aus!

Ich finde das sehr merkwürdig. Nach meinen bisherigen Erfahrungen werden Zeichen, die nicht im Zeichensatz enthalten sind, als Quadrat mit Hex Code dargestellt.

... ist die Anzeige im 3 Jahre alten Ubuntu 18.04.5 fehlerhaft – wie kann ich das verstehen.

Das verstehe ich auch nicht. Ich habe das mal kurz anhand des Zeichens für Widder überprüft. In meinem Ubuntu Mate 18.04 wird es in EOM und in Mosepad richtig dargestellt. Und bei meinem Debian 10 mit Xfce kann Gimp es auch richtig rendern.

Ich habe mir die SVG Datei mal mit mc im Hex-Modus angesehen. Die Tierkreiszeichen sind die einzigen die bunt sind und sie sind UTF-8 codiert. Für die Planetenzeichen konnte ich zwar den Text finden, nicht jedoch die Codierung.

Vielleicht ist das ein Anhaltspunkt.

Super, danke, dass du mir hilfst Schmutzfink,

das unerklärliche ist ja die Tatsache, dass sowohl der Zeichensatz (UTF-8) als auch die verwendete Schrift (Linux Biolinum) alle als Text in der SVG enthaltenen Zeichen abdecken. Seit mehr als einem haben Jahrzehnt erzeuge ich einmal im Jahr die 12 Monatsblätter als SVG und mache mit Inkscape daraus PDFs. Dieses Jahr habe ich zum ersten mal Probleme dabei. Zum ersten mal kann Inkscape die Sternzeichen-Symbole in all den jemals erzeugten SVGs nicht mehr richtig darstellen und mit ihm auch Firefox und der Bildbetrachter.

Die gesamte SVG ist UTF-8 codiert. Die Symbole für die Planeten sind Pfade und kein Text, darum haben sie auch keine Codierung, daran sollte es eigentlich nicht liegen.

Ich befürchte es liegt irgendwo im Zusammenspiel von fontconfig, pango, harfbuzz und was da sonst noch im Hintergrund mitmischt bis ein Schriftzeichen fertig gerendert am Bildschirm erscheint.

Es ist nur ein Verdacht, aber ich könnte mir vorstellen es gibt da irgendwo eine grobe, nicht bis zum Schluss durchdachte oder einfach versehentlich fehlerhafte Ersetzungsregel, die einen speziellen Bereich von Unicode standardmäßig durch eine „hübsche“ farbige Alternative aus der »Noto Color Emoji« ersetzt, ohne abzuklären ob die entsprechenden Symbole in der eigentlich verwendeten Schriftart vorhanden sind – um z.B. sicher zu stellen dass knallige Emojis im Chat & Co. dargestellt werden. Zumindest taucht bei Arch Linux die »Noto Color Emoji« als Abhängigkeit von pango auf… aber vielleicht verrenne ich mich auch in die völlig falsche Richtung…

Ich bin mir aber ziemlich sicher, dass es nicht an den SVGs selbst liegt, denn:

• Sie wurden über mehr als 5 Jahre fehlerfrei dargestellt, zumindest von Inkscape.

• Wenn ich ein neues Dokument mit Inkscape erstelle und darin die Linux Biolinum (oder auch eine der anderen Schriften, die Symbole für die Sternzeichen bereit stellen) verwende. Dann kommt Schrott dabei raus. Das war früher auch nicht so: In der Textvorschau bei den Einstellungen zur Schrift wird unverständlicher Weise das Stenzeichensymbol der »Noto Color Emoji« angezeigt und in der SVG-Zeichnung selbst einer der Buchstaben zwischen »o« und »z« (es werden also die letzten 12 Buchstaben des Alphabetes verwendet) aus einer anderen Schrift, viel zu groß, zu dick und mit einem großen Leerraum dahinter.

Ich glaube nicht, dass ich Dir wirklich helfen kann, jedenfalls nicht direkt. Aber vielleicht klingelt es bei jemand anderen, wenn er die zusammengetragenen Fakten sieht.

Die gesamte SVG ist UTF-8 codiert. Die Symbole für die Planeten sind Pfade und kein Text, darum haben sie auch keine Codierung, daran sollte es eigentlich nicht liegen.

Das ist aber im Moment der einzige Unterschied, den ich erkennen kann. Und die Symbole sind in der SVG Datei (ist ja auch nur Text) nicht gedreht. Vielleicht ist das auch ein Punkt, der zu beachten ist.

Mit Fonts und deren Geheimnisse kenne ich mich leider nicht aus. Wenn ich da mal etwas einstellen muss, begnüge ich mich mit Helvetica und Courier, und hoffe das das Ergebnis lesbar ist 😉

Es ist nur ein Verdacht, aber ich könnte mir vorstellen es gibt da irgendwo eine grobe, nicht bis zum Schluss durchdachte oder einfach versehentlich fehlerhafte Ersetzungsregel, die einen speziellen Bereich von Unicode standardmäßig durch eine „hübsche“ farbige Alternative aus der »Noto Color Emoji« ersetzt, ohne abzuklären ob die entsprechenden Symbole in der eigentlich verwendeten Schriftart vorhanden sind ...

Das müsste dann aber schon sehr "hinterlistig" codiert sein. Ich habe mir mal die Unicode Codierung für Mars (0x2642) und Widder (0x2648) angesehen. Die liegen so dicht zusammen, dass ich keinen logischen Grund für eine Trennung dazwischen erkennen kann. Und wie gesagt, unbekannte Zeichen werden normalerweise durch ein Quadrat dargestellt.

Ich fürchte, da ist bei einigen Programmen, die das rendern sollen, einfach etwas "weg gespart" worden.

Möglicherweise ist das tatsächlich ein Bug (irgendwo). Du solltest vielleicht mal versuchen, ein Minimaldokument mit nur einem der Fehlerhaften Zeichen zu erzeugen. Wenn das immer noch fehlerhaft ist, kannst du es als Bug melden. Wobei das leider fast so kompliziert ist, wie eine Steuererklärung. Bei beiden habe ich aufgegeben ...

Hallo!

Ursachen kann das viele haben. Aktuell bin ich mit KDE Neon unterwegs, daher kann ich zu Arch nichts sagen: Ich habe mir den Biolinum Font nach ~/.local/share/fonts/ geladen und bekomme in Gwenview die Symbole einwandfrei angezeigt, in Emacs per imagemagick allerdings die falschen wie im Beispiel. Mit gthumb und phototonic wird es auch richtig angezeigt.

Ansonsten habe ich versucht den Quellcode etwas zu sichten, der ist mir aber ein wenig zu durcheinander für „mal eben“, weswegen ich meine SVG gerne „von Hand“ schreibe.

So, jetzt habe ich etwas Licht ins Dunkel bekommen können, aber eine Lösung sehe ich noch nicht. Aber alles der Reihe nach:

Das müsste dann aber schon sehr "hinterlistig" codiert sein. Ich habe mir mal die Unicode Codierung für Mars (0x2642) und Widder (0x2648) angesehen. Die liegen so dicht zusammen, dass ich keinen logischen Grund für eine Trennung dazwischen erkennen kann. Und wie gesagt, unbekannte Zeichen werden normalerweise durch ein Quadrat dargestellt.

Schmutzfink, da irrst du dich. Wenn der Zeichensatz stimmt und nur die Zeichen in der Schrift fehlen, dann wird im Hintergrund so gut wie immer Himmel und Hölle in Bewegung gesetzt um die fehlenden Schriftzeichen irgendwo her zu bekommen und die Fehlstellen der Schrift zu kaschieren. Es wird nach Möglichkeit immer versucht die angefragten Informationen darzustellen, notfalls auch mit nicht gut zusammen passenden Schriftzeichen. Damit es aber fast immer »nicht auffällt« gibt es fontconfig & Co. mit umfangreichen Regelsätzen.

Und ich bin mir inzwischen fast sicher, dass es sich genau so verhält, wie ich vermutet hatte. Diese »hinterlistige« Regel scheint es zu geben. Ich habe sie noch nicht gefunden, das ganze ist furchtbar unübersichtlich für mein Empfinden aber ich habe fontconfig sehr schwer in Verdacht. Alle Indizien deuten darauf hin:

Schmutzfink ich habe deinen Hinweis auf ein Minimaldokument beherzigt. Die Ergebnisse waren sehr erhellend! Die Datei ist im Anhang (Sternzeichen.svg). Sie enthält 4 mal den selben Text mit einem Sternzeichen- und einem Planetensymbol jeweils in einer anderen Schrift. Die ersten 3 Schriften (DejaVu Sans, Linux Biolinum, Free Mono) besitzen alle verwendeten Zeichen und es sollte nichts ersetzt werden. Das Letzte Beispiel ist in »Source Code Pro« gesetzt, diese Schrift enthält weder Planeten- noch Sternzeichensymbole, hier muss das System versuchen einen Ersatz anzubieten.

Ich habe eine ganze Reihe von Ubuntu-Varianten per Live-USB durchprobiert und gleichzeitig auch mit den Ergebnissen aus meinem Arch Linux verglichen. Die Kandidaten waren Xubuntu 18.04.5, Kubuntu 18.04.5 und 20.04.2, Ubuntu 18.04.5 und 20.04.2 und mein aktuelles Arch Linux. Die Ergebnisse:

• In Ubuntu und Xubuntu in Version 18.04.5 ist Firefox der einzige, der die SVG so anzeigt wie ich es erwarte (vgl. Firefox_79.png). In Kubuntu 18.04.5 sind es zusätzlich Gwenview und Phototonic (vgl. Gwenview_18.04.png). In den anderen getesteten Programmen geschieht ein „Zwangsaustausch“ der Sternzeichensymbole (Inkscape, Gimp, gThumb, die Bildbetrachter ristretto und Eye of Gnome). Dabei unterscheidet sich die Art des Austausches, abhängig von den standardmäßig vorhandenen Schriften. Xubuntu und Kubuntu haben die »Noto Color Emoji« nicht standardmäßig vorinstalliert. Hier geschieht ein „unauffälliger Zwangsaustausch“ durch die Zeichen der DejaVu Schriften (vgl. Inkscape_Emoji-Font_nicht_installiert.png). Ich selbst habe diese dezente Änderung über Jahre nicht bemerkt, denn auch das als »korrekt« gedachte Beispiel aus meinem ersten Beitrag ist bereits ein Opfer des „Zwangsaustausches“ durch die DejaVu Sans unter Arch Linux. Wann dieser Austausch begonnen hat, das kann ich nicht mehr nachvollziehen. Ich habe aber noch PDF-Dateien aus dem Frühjahr 2016, die von Inkscape mit den richtigen Zeichen der Linux Biolinum exportiert wurden. Zu diesem Zeitpunkt war zumindest Arch Linux noch nicht von diesem Vorgehen betroffen. Sobald eine Emoji-Schrift (standardmäßig überall die »Noto Color Emoji«) installiert ist, verändert sich der „Zwangsaustausch“ hin zu bunten Emojis (vgl. ristretto_Emoji-Font_installiert.png). Da die »Noto Color Emoji« ein Bitmap-Font ist haben einige Programme generell ein Problem mit der Darstellung, wenn sie mit Bitmap-Fonts nicht umgehen können. Das äußert sich beim vorbildlich korrekt arbeitenden Gwenview im Verschwinden der betroffenen Zeichen. In meinem Beispiel ist das bei der »Source Code Pro« der Fall, da die Schrift keine astrologischen Symbole enthält sorgt das System für Ersatz – das Zeichen für Widder kommt aus der »Noto Color Emoji« und ist nicht zu sehen, das Symbol für Merkur (ich habe fälschlich Mars geschrieben) ist im Emoji-Font nicht enthalten und wird aus der DejaVu herbeigeschafft und korrekt angezeigt. Bei Inkscape führt es zu einer Art „Not-Ersatz“ durch die Kleinbuchstaben von »o« bis »z« aus der DejaVu (vgl. Inkscape_Emoji-Font_installiert.png).

• Beim Sprung zu den 20.04-Versionen verschlimmert sich die Lage insofern, dass die »Noto Color Emoji« neben Ubuntu auch in Kubuntu (Xubuntu habe ich nicht getestet) standardmäßig installiert ist, was zwangsläufig zu den genannten Problemen mit Inkscape und Gwenview führt. Aber auch Firefox hat sich in seinem Verhalten dem aggressiven vorgehen des Betriebssystems angepasst und führt jetzt ebenfalls eine komplette „Zwangsersetzung“ durch die Sternzeichen-Symbole in seiner hauseigenen Emoji-Schrift durch (vgl. Firefox_85.png).

• Die ganze Sache muss relativ komplex umgesetzt sein, denn in der »Noto Color Emoji« sind auch ein paar von allen Schriften unterstützte Zeichen enthalten (# * und die Zahlen 0 - 9…), diese Zeichen werden definitiv nicht zwangsersetzt.

Agrrrr, ich krieg den Übeltäter nicht zu fassen:

Dieser Abschnitt im fontconfig Beitrag im Arch Linux Wiki zeigt, dass fontconfig viel mit der Emoji-Unterstützung zu tun hat. Der Beitrag will das genaue Gegenteil von dem was ich will. Es sollen Anwendungen dazu gebracht werden Emojis passend anzuzeigen, mir geht die Emoji-Bevorzugung viel zu weit und will das eben nicht:

https://wiki.archlinux.org/index.php/Font_configuration#Force_emoji_font

Dieser Bug-Report zu fontconfig zeigt jedoch, dass die zur-Verfügung-Stellung zwar fontconfig Sache ist, die Details aber nicht mehr. Besonders wenn es darum geht was mit einzelnen Zeichen passiert. Es wird auf die einzelnen Anwendungen oder auf pango, cairo & Co. verwiesen. Auch hier ist es wieder genau umgekehrt. Ich will ganz genau das Gegenteil vom Bug-Report.

https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/111

Sind jetzt die ganzen Anwendungen nicht reif fürs »Emoji Zeitalter« und stellen zu ungenaue Anfragen/geben sich ungeprüft mit unbrauchbaren Angeboten zufrieden? Oder sind im Bereich Rendering die Regeln zu wenig durchdacht bzw. nicht eindeutig zu formulieren? Da z.B ein Chat-Programm sicher auch für die Sternzeichen hübsche Emojis haben will, für die Anzeige und Bearbeitung von SVGs, wie in meinem Fall, ist das völlig deplatziert.