web-dev-qa-db-ja.com

XTermは*一部の* Unicode文字を正しく表示しませんか？

XTermとUnicodeに一般的な問題はありません。ほとんどの場合、物事は機能しています。これはうまく機能します：

$ echo "¿dónde está la llama?"
¿dónde está la llama?

これがするように：

$ echo -e "\xE2\x98\xA0"
☠

しかし、thisは失敗します：

$ echo -e "\xE2\xA4\xB7"

期待される出力ではなく（⤷、別名 矢印を下に向けてから右に曲がる ）恐ろしいボックスが表示されます。私は現在使用しています：

xterm*faceName: Hack Regular:size=12:antialias=true

これは、私がgnome-terminalで使用しているのと同じフォントで、同じ文字を正しく表示します。他のさまざまなモノスペースフォント（Droid Sans Mono、DejaVu Sans Mono、Liberation Mono）でも同じことを試しましたが、これらはすべてXTermで同じ動作をします（ただし、他の場所では正常に機能します）。実際、正しく表示される\u2620とそうでない\u2937の間の文字を見ると、XTermで正しく表示されていないように見える文字がいくつかあります。

$ python
>>> for x in range(0x2620, 0x2938):
...    print(unichr(x))

ここで何が起こっているのか理解したいのですが。 XTermがこれらの文字の一部を表示するのに問題があるのに、他の文字は表示できないのはなぜですか？

fontsxtermunicode
6
larsks

短い：xtermはsingleフォントを使用します（倍幅文字の特殊な場合を除く）、他の端末は追加のフォントを使用します（そして、要求されたフォントにない文字にはそれらのフォントを使用します）。

long：興味のある文字はnotフォントの一部であり、何かのように見えますDebianの fonts-hack-tty のように。欠落しているコードは0x2937であり、xfd -fa hackを使用して確認できますが、フォントによって提供されていません（ヒント：ページの最初は0x2987）：

enter image description here

フォントの簡単な説明は、その使用目的を示しています。

フリルがない。ヒダが無い。仕掛けはありません。ハックは手作業で手入れされ、光学的にバランスが取れており、コードの主力製品になります。

これは（「コード」は一般にPOSIX文字セットであり、それに加えて、人々が良いコメントをすると思うものは何でも）小さい可能性があります。この例には、通常よりも多くの非POSIX文字が含まれています。 ASCII + Latin1から開始：

enter image description here

フォントには数百のグリフがあります（これらを表示するには、さらに12のスクリーンショットが必要ですが、半分以上は少数のグリフを表示します）。たとえば、2番目のページは部分的にサポートされています。

enter image description here

コメントに促されて、gnome-terminalをトレースして、次のフォントファイルが読み込まれることを確認しました。

/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBd.ttf
/usr/share/fonts/truetype/ttf-bitstream-vera/VeraSeBd.ttf
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf

そしてその0x2937は最後のものによって供給されます。実際の詳細は、構成によって異なる場合があります。

5
Thomas Dickey