Fehlende Teile von utf-8-Zeichensatz in urxvt mit VcXsrv

968
Warepire

Ich verwende einen Arch Linux-Server, zu dem ich von einigen Windows-Computern mit VcXsrv eine Verbindung herstelle, so dass ich grafische Anwendungen ausführen kann (und mehr angepasste Terminals als ich mit PuTTY usw. bekommen kann). Ich habe jedoch einige Probleme mit urxvt- und UTF-8-Zeichen aus dem Abschnitt UTF-8-Dingbats, dh sie werden nicht gerendert. Ich verwende Dingbats, um den Git-Status in meiner Shell-Eingabeaufforderung anzuzeigen und auch den Exit-Status von Befehlen anzuzeigen.

locale.conf:

LANG=en_US.UTF-8

Gebietsschema-Ausgabe:

LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

Urxvt-Konfiguration (~ / .Xdefaults):

URxvt*scrollTtyOutput: false URxvt*scrollWithBuffer: true URxvt*scrollTtyKeypress: true URxvt*scrollBar: false URxvt*cursorBlink: true URxvt*background: black URxvt*foreground: green URxvt*font: xft:Hack:size=10, xft:Unifont:size=10 URxvt*locale: true URxvt*skipBuiltinGlyphs: true URxvt*xftAntialias: true URxvt*saveLines: 10000 URxvt*eightBitInput: false

Urxvt-Versionsinformationen:

rxvt-unicode (urxvt) v9.22 - released: 2016-01-23 options: perl,xft,styles,combining,blink,iso14755,unicode3,encodings=eu+vn+jp+jp-ext+kr+zh+zh-ext, fade,transparent,tint,XIM,frills,selectionscrolling,wheel,slipwheel,cursorBlink, pointerBlank,scrollbars=plain+rxvt+NeXT+xterm

Ich kann alle lateinischen, Katakana, Hiragana, Hangul, Chinesen (traditionell, vereinfacht), kyrillisch, persisch (meist), georgische Schriftzeichen usw. sehen. Aber Dingbats sehen so aus, wenn ich sie ausdrucken:

Dingbats werden nicht gerendert

Ich verwende zsh im vim-mode, wenn es darauf ankommt.
Bei Google ist der einzige Rat, den ich finden kann, sicherzustellen, dass das Gebietsschema auf UTF-8 eingestellt ist und die Zeichensätze über die erforderlichen Glyphen verfügen. Beides, glaube ich, habe ich sichergestellt.

Wo konnte ich falsch liegen?

0
Beachten Sie, dass die Zeichensätze * auf dem Client * und nicht auf dem Server verfügbar sein müssen. (es sei denn, Sie führen ein Terminal vom Server aus mit X-Server-Umleitung aus). Paul Stelian vor 7 Jahren 0
Verbinden mit `ssh -X` mit PuTTY. Ich habe die Schriftarten auf meinem Arch-Rechner installiert, dann kopiert und an den richtigen Stellen der VcXsrv-Installationen platziert. Vielleicht war das nicht der richtige Weg? Warepire vor 7 Jahren 0
Der Ort, an dem PuTTY ausgeführt wird, muss über die Schriftarten verfügen (d. H. Die Windows-Konsole). Und das ist normalerweise nicht der Fall. Sie können `gnome-terminal` jedoch über ssh -X ausführen, und das sollte korrekt mit den Server-Schriftarten (ich verwende eine solche Konfiguration!) Paul Stelian vor 7 Jahren 0
@ Paul Stelian Das Problem liegt bei meinen urxvt-Terminals, die das PuTTY-Terminal wie erwartet rendert. In der PuTTY-Sitzung zeige ich die urxvt-Terminals, und diese werden nicht richtig gerendert. Es tut mir leid, wenn mir das nicht klar war. (Ich wollte nur zeigen, wie ich X in meinem vorherigen Kommentar weitergeleitet habe.) Warepire vor 7 Jahren 0
Ich glaube, dass urxvt nicht alle Schriften berücksichtigt. Wissen Sie, wie Sie die verwendete Schriftart ändern können? (Dies geschieht jedoch nicht automatisch, das ist sicher.) Stellen Sie außerdem sicher, dass die gewählte Schriftart diese Zeichen enthält (möglicherweise eine Noto Mono oder eine ähnliche Schriftart?). Paul Stelian vor 7 Jahren 0
Ich habe meine urxvt-Konfiguration in die Frage aufgenommen, da ich nicht sicher bin, wo das eigentliche Problem liegt. Ich habe einige Online-Handbücher befolgt, als ich sie eingerichtet habe (mein erstes Mal mit urxvt), und beim visuellen Vergleichen von Zeichen mit den Glyph-Maps für jede Schriftart scheint die richtige Schriftart zu rendern. Ich habe die Fallback-Schriftart getestet, indem ich die erste Wahl vorübergehend entfernt habe. Ich habe auch den Ausdruck des Dingbat-Tests in eine Datei geschrieben und die Binärdaten mit den erwarteten Byte-Sequenzen für die Dingbat-Zeichen verglichen, und sie stimmen überein. Warepire vor 7 Jahren 0
Und ... sind Sie sicher, dass die Hack-Schrift Dingbats enthält? Paul Stelian vor 7 Jahren 0
Es sollte und der Rückfall tut es definitiv. Warepire vor 7 Jahren 0
Vielleicht hat Hack es nicht. Beachten Sie, dass der Fallback nur geladen wird, wenn die * gesamte Schriftart * fehlt, nicht jedoch einige Zeichen. Vielleicht Reihenfolge ändern? Paul Stelian vor 7 Jahren 0
So habe ich nicht die Informationen interpretiert, die ich bei google gefunden habe. Das ist sehr gut zu wissen. Vielen Dank. Ich habe gerade den Dingbat-Test ausgeführt, nachdem ich die Schriftart von der Liste entfernt und `xrdb -load .Xdefaults` ausgeführt habe. Gleiches Ergebnis, es werden keine Dingbats gedruckt. (Diesmal habe ich nur Unifont verwendet). Warepire vor 7 Jahren 0
Hmm, versuchen Sie, ein paar Noto Mono-Schriftarten zu bekommen, da bekannt ist, dass Noto Boxen (sie nennen Tofu) so viel wie möglich vermeiden. Paul Stelian vor 7 Jahren 0
Hm, GNU Unifont hat das gleiche Ziel. Ich habe Noto Mono einen Schuss gegeben (`URxvt * font: xft: Noto \ Mono: size = 10`), aber die Dingbats fehlen noch. Warepire vor 7 Jahren 0
Nun, das ist interessant ... Paul Stelian vor 7 Jahren 0
Ich habe die Zeichen auf meinem Windows-System ausprobiert und * einige * werden nur mit speziellen Schriftarten gerendert, während andere überhaupt nicht gerendert werden. Paul Stelian vor 7 Jahren 0
Ab https://www.w3schools.com/charsets/ref_utf_dingbats.asp sind Sie nicht einmal in der richtigen Unicode-Region (es sei denn, es gibt auch Dingbats dort). Paul Stelian vor 7 Jahren 0
Ah, ich verstehe ... Zeichen 61440 und weiter (u + F000 und weiter) sind die * private use * -Ebene, wobei Zeichen auf verschiedenen Systemen verschiedene Bedeutungen haben. Paul Stelian vor 7 Jahren 0

1 Antwort auf die Frage

0
Paul Stelian

Das Problem entsteht durch die Verwendung von Zeichen, die sich in der Private Use-Ebene von Unicode befinden, wobei dies nicht garantiert ist. Windows XP-Systeme könnten eudceditdie Zeichensätze dort explizit mit dem Befehl bearbeiten. Macs haben ein Apple-Logo in einem der 6400 Zeichen in dieser Ebene. Sie verwenden einfach die falschen Dingbats.

Die korrekten Dingbats sind von 9985 bis 10175 Dezimalzahlen (2701 bis 27bf hex).

Das war ein wirklich dummer Fehler in meinem Test, aber es konnte mein Problem nicht ganz zu 100% lösen. Ergebnisse mit Noto Mono und Unifont (in dieser Reihenfolge): [Imgur: results] (http://i.imgur.com /Kw9QXUV.png) Warepire vor 7 Jahren 1
Hmm, jetzt wird das Problem interessant ... Paul Stelian vor 7 Jahren 0
Auf meiner Windows-Konsole funktionierten nur 3 Schriftarten: NSimSun, MS Gothic, SimSun-ExtB Paul Stelian vor 7 Jahren 0
Wäre es nicht an meinem X-Server (VcXsrv), die Schriftarten durchzugeben? Da ist es eine urxvt-Konsole. Warepire vor 7 Jahren 1
In der Tat ist der X-Server für die Wiedergabe von Schriftarten verantwortlich. Allerdings ist es eine nette Sache, die üblichen Schriftarten zu haben, bei denen einige sie tatsächlich abdecken (versuchen Sie es erneut mit Noto Mono). Es ist auch möglich, dass Schriften von der App in den Server verschoben werden. Paul Stelian vor 7 Jahren 0
Sie haben mich dort auf den richtigen Weg gebracht. Ich fing an, tiefer in meinem X-Server (VcXsrv) nach Code und Protokoll zu suchen, und es gelang mir, diese Zeile während des Startvorgangs herauszuholen. Warepire vor 7 Jahren 2

Verwandte Probleme