| … | |
… | |
| 426 | <p> |
426 | <p> |
| 427 | </p> |
427 | </p> |
| 428 | <h3><a name="why_do_italic_characters_look_as_if_clipped">Why do italic characters look as if clipped?</a></h3> |
428 | <h3><a name="why_do_italic_characters_look_as_if_clipped">Why do italic characters look as if clipped?</a></h3> |
| 429 | <p>Many fonts have difficulties with italic characters and hinting. For |
429 | <p>Many fonts have difficulties with italic characters and hinting. For |
| 430 | example, the otherwise very nicely hinted font <code>xft:Bitstream Vera Sans |
430 | example, the otherwise very nicely hinted font <code>xft:Bitstream Vera Sans |
| 431 | Mono</code> completely fails in it's italic face. A workaround might be to |
431 | Mono</code> completely fails in its italic face. A workaround might be to |
| 432 | enable freetype autohinting, i.e. like this:</p> |
432 | enable freetype autohinting, i.e. like this:</p> |
| 433 | <pre> |
433 | <pre> |
| 434 | URxvt.italicFont: xft:Bitstream Vera Sans Mono:italic:autohint=true |
434 | URxvt.italicFont: xft:Bitstream Vera Sans Mono:italic:autohint=true |
| 435 | URxvt.boldItalicFont: xft:Bitstream Vera Sans Mono:bold:italic:autohint=true</pre> |
435 | URxvt.boldItalicFont: xft:Bitstream Vera Sans Mono:bold:italic:autohint=true</pre> |
| 436 | <p> |
436 | <p> |
| … | |
… | |
| 442 | memory and also speeds up rendering considerably.</p> |
442 | memory and also speeds up rendering considerably.</p> |
| 443 | <p> |
443 | <p> |
| 444 | </p> |
444 | </p> |
| 445 | <h3><a name="rxvtunicode_doesn_t_seem_to_antialias_its_fonts__what_is_wrong">Rxvt-unicode doesn't seem to anti-alias its fonts, what is wrong?</a></h3> |
445 | <h3><a name="rxvtunicode_doesn_t_seem_to_antialias_its_fonts__what_is_wrong">Rxvt-unicode doesn't seem to anti-alias its fonts, what is wrong?</a></h3> |
| 446 | <p>Rxvt-unicode will use whatever you specify as a font. If it needs to |
446 | <p>Rxvt-unicode will use whatever you specify as a font. If it needs to |
| 447 | fall back to it's default font search list it will prefer X11 core |
447 | fall back to its default font search list it will prefer X11 core |
| 448 | fonts, because they are small and fast, and then use Xft fonts. It has |
448 | fonts, because they are small and fast, and then use Xft fonts. It has |
| 449 | antialiasing disabled for most of them, because the author thinks they |
449 | antialiasing disabled for most of them, because the author thinks they |
| 450 | look best that way.</p> |
450 | look best that way.</p> |
| 451 | <p>If you want antialiasing, you have to specify the fonts manually.</p> |
451 | <p>If you want antialiasing, you have to specify the fonts manually.</p> |
| 452 | <p> |
452 | <p> |
| … | |
… | |
| 955 | :vs=\E[?25h:</pre> |
955 | :vs=\E[?25h:</pre> |
| 956 | <p> |
956 | <p> |
| 957 | </p> |
957 | </p> |
| 958 | <h3><a name="why_does_ls_no_longer_have_coloured_output">Why does <code>ls</code> no longer have coloured output?</a></h3> |
958 | <h3><a name="why_does_ls_no_longer_have_coloured_output">Why does <code>ls</code> no longer have coloured output?</a></h3> |
| 959 | <p>The <code>ls</code> in the GNU coreutils unfortunately doesn't use terminfo to |
959 | <p>The <code>ls</code> in the GNU coreutils unfortunately doesn't use terminfo to |
| 960 | decide wether a terminal has colour, but uses it's own configuration |
960 | decide wether a terminal has colour, but uses its own configuration |
| 961 | file. Needless to say, <code>rxvt-unicode</code> is not in it's default file (among |
961 | file. Needless to say, <code>rxvt-unicode</code> is not in its default file (among |
| 962 | with most other terminals supporting colour). Either add:</p> |
962 | with most other terminals supporting colour). Either add:</p> |
| 963 | <pre> |
963 | <pre> |
| 964 | TERM rxvt-unicode</pre> |
964 | TERM rxvt-unicode</pre> |
| 965 | <p>to <code>/etc/DIR_COLORS</code> or simply add:</p> |
965 | <p>to <code>/etc/DIR_COLORS</code> or simply add:</p> |
| 966 | <pre> |
966 | <pre> |
| … | |
… | |
| 1030 | <p>The reasons is that there exists a perfectly fine mechanism for selecting |
1030 | <p>The reasons is that there exists a perfectly fine mechanism for selecting |
| 1031 | the encoding, doing I/O and (most important) communicating this to all |
1031 | the encoding, doing I/O and (most important) communicating this to all |
| 1032 | applications so everybody agrees on character properties such as width |
1032 | applications so everybody agrees on character properties such as width |
| 1033 | and code number. This mechanism is the <em>locale</em>. Applications not using |
1033 | and code number. This mechanism is the <em>locale</em>. Applications not using |
| 1034 | that info will have problems (for example, <code>xterm</code> gets the width of |
1034 | that info will have problems (for example, <code>xterm</code> gets the width of |
| 1035 | characters wrong as it uses it's own, locale-independent table under all |
1035 | characters wrong as it uses its own, locale-independent table under all |
| 1036 | locales).</p> |
1036 | locales).</p> |
| 1037 | <p>Rxvt-unicode uses the <code>LC_CTYPE</code> locale category to select encoding. All |
1037 | <p>Rxvt-unicode uses the <code>LC_CTYPE</code> locale category to select encoding. All |
| 1038 | programs doing the same (that is, most) will automatically agree in the |
1038 | programs doing the same (that is, most) will automatically agree in the |
| 1039 | interpretation of characters.</p> |
1039 | interpretation of characters.</p> |
| 1040 | <p>Unfortunately, there is no system-independent way to select locales, nor |
1040 | <p>Unfortunately, there is no system-independent way to select locales, nor |
| … | |
… | |
| 1190 | <p>Rxvt-unicode requires the symbol <code>__STDC_ISO_10646__</code> to be defined |
1190 | <p>Rxvt-unicode requires the symbol <code>__STDC_ISO_10646__</code> to be defined |
| 1191 | in your compile environment, or an implementation that implements it, |
1191 | in your compile environment, or an implementation that implements it, |
| 1192 | wether it defines the symbol or not. <code>__STDC_ISO_10646__</code> requires that |
1192 | wether it defines the symbol or not. <code>__STDC_ISO_10646__</code> requires that |
| 1193 | <strong>wchar_t</strong> is represented as unicode.</p> |
1193 | <strong>wchar_t</strong> is represented as unicode.</p> |
| 1194 | <p>As you might have guessed, FreeBSD does neither define this symobl nor |
1194 | <p>As you might have guessed, FreeBSD does neither define this symobl nor |
| 1195 | does it support it. Instead, it uses it's own internal representation of |
1195 | does it support it. Instead, it uses its own internal representation of |
| 1196 | <strong>wchar_t</strong>. This is, of course, completely fine with respect to standards.</p> |
1196 | <strong>wchar_t</strong>. This is, of course, completely fine with respect to standards.</p> |
| 1197 | <p>However, that means rxvt-unicode only works in <code>POSIX</code>, <code>ISO-8859-1</code> and |
1197 | <p>However, that means rxvt-unicode only works in <code>POSIX</code>, <code>ISO-8859-1</code> and |
| 1198 | <code>UTF-8</code> locales under FreeBSD (which all use Unicode as <strong>wchar_t</strong>.</p> |
1198 | <code>UTF-8</code> locales under FreeBSD (which all use Unicode as <strong>wchar_t</strong>.</p> |
| 1199 | <p><code>__STDC_ISO_10646__</code> is the only sane way to support multi-language |
1199 | <p><code>__STDC_ISO_10646__</code> is the only sane way to support multi-language |
| 1200 | apps in an OS, as using a locale-dependent (and non-standardized) |
1200 | apps in an OS, as using a locale-dependent (and non-standardized) |
