| … | |
… | |
| 314 | |
314 | |
| 315 | =head3 Why do italic characters look as if clipped? |
315 | =head3 Why do italic characters look as if clipped? |
| 316 | |
316 | |
| 317 | Many fonts have difficulties with italic characters and hinting. For |
317 | Many fonts have difficulties with italic characters and hinting. For |
| 318 | example, the otherwise very nicely hinted font C<xft:Bitstream Vera Sans |
318 | example, the otherwise very nicely hinted font C<xft:Bitstream Vera Sans |
| 319 | Mono> completely fails in it's italic face. A workaround might be to |
319 | Mono> completely fails in its italic face. A workaround might be to |
| 320 | enable freetype autohinting, i.e. like this: |
320 | enable freetype autohinting, i.e. like this: |
| 321 | |
321 | |
| 322 | URxvt.italicFont: xft:Bitstream Vera Sans Mono:italic:autohint=true |
322 | URxvt.italicFont: xft:Bitstream Vera Sans Mono:italic:autohint=true |
| 323 | URxvt.boldItalicFont: xft:Bitstream Vera Sans Mono:bold:italic:autohint=true |
323 | URxvt.boldItalicFont: xft:Bitstream Vera Sans Mono:bold:italic:autohint=true |
| 324 | |
324 | |
| … | |
… | |
| 330 | memory and also speeds up rendering considerably. |
330 | memory and also speeds up rendering considerably. |
| 331 | |
331 | |
| 332 | =head3 Rxvt-unicode doesn't seem to anti-alias its fonts, what is wrong? |
332 | =head3 Rxvt-unicode doesn't seem to anti-alias its fonts, what is wrong? |
| 333 | |
333 | |
| 334 | Rxvt-unicode will use whatever you specify as a font. If it needs to |
334 | Rxvt-unicode will use whatever you specify as a font. If it needs to |
| 335 | fall back to it's default font search list it will prefer X11 core |
335 | fall back to its default font search list it will prefer X11 core |
| 336 | fonts, because they are small and fast, and then use Xft fonts. It has |
336 | fonts, because they are small and fast, and then use Xft fonts. It has |
| 337 | antialiasing disabled for most of them, because the author thinks they |
337 | antialiasing disabled for most of them, because the author thinks they |
| 338 | look best that way. |
338 | look best that way. |
| 339 | |
339 | |
| 340 | If you want antialiasing, you have to specify the fonts manually. |
340 | If you want antialiasing, you have to specify the fonts manually. |
| … | |
… | |
| 908 | :vs=\E[?25h: |
908 | :vs=\E[?25h: |
| 909 | |
909 | |
| 910 | =head3 Why does C<ls> no longer have coloured output? |
910 | =head3 Why does C<ls> no longer have coloured output? |
| 911 | |
911 | |
| 912 | The C<ls> in the GNU coreutils unfortunately doesn't use terminfo to |
912 | The C<ls> in the GNU coreutils unfortunately doesn't use terminfo to |
| 913 | decide wether a terminal has colour, but uses it's own configuration |
913 | decide wether a terminal has colour, but uses its own configuration |
| 914 | file. Needless to say, C<rxvt-unicode> is not in it's default file (among |
914 | file. Needless to say, C<rxvt-unicode> is not in its default file (among |
| 915 | with most other terminals supporting colour). Either add: |
915 | with most other terminals supporting colour). Either add: |
| 916 | |
916 | |
| 917 | TERM rxvt-unicode |
917 | TERM rxvt-unicode |
| 918 | |
918 | |
| 919 | to C</etc/DIR_COLORS> or simply add: |
919 | to C</etc/DIR_COLORS> or simply add: |
| … | |
… | |
| 991 | The reasons is that there exists a perfectly fine mechanism for selecting |
991 | The reasons is that there exists a perfectly fine mechanism for selecting |
| 992 | the encoding, doing I/O and (most important) communicating this to all |
992 | the encoding, doing I/O and (most important) communicating this to all |
| 993 | applications so everybody agrees on character properties such as width |
993 | applications so everybody agrees on character properties such as width |
| 994 | and code number. This mechanism is the I<locale>. Applications not using |
994 | and code number. This mechanism is the I<locale>. Applications not using |
| 995 | that info will have problems (for example, C<xterm> gets the width of |
995 | that info will have problems (for example, C<xterm> gets the width of |
| 996 | characters wrong as it uses it's own, locale-independent table under all |
996 | characters wrong as it uses its own, locale-independent table under all |
| 997 | locales). |
997 | locales). |
| 998 | |
998 | |
| 999 | Rxvt-unicode uses the C<LC_CTYPE> locale category to select encoding. All |
999 | Rxvt-unicode uses the C<LC_CTYPE> locale category to select encoding. All |
| 1000 | programs doing the same (that is, most) will automatically agree in the |
1000 | programs doing the same (that is, most) will automatically agree in the |
| 1001 | interpretation of characters. |
1001 | interpretation of characters. |
| … | |
… | |
| 1163 | in your compile environment, or an implementation that implements it, |
1163 | in your compile environment, or an implementation that implements it, |
| 1164 | wether it defines the symbol or not. C<__STDC_ISO_10646__> requires that |
1164 | wether it defines the symbol or not. C<__STDC_ISO_10646__> requires that |
| 1165 | B<wchar_t> is represented as unicode. |
1165 | B<wchar_t> is represented as unicode. |
| 1166 | |
1166 | |
| 1167 | As you might have guessed, FreeBSD does neither define this symobl nor |
1167 | As you might have guessed, FreeBSD does neither define this symobl nor |
| 1168 | does it support it. Instead, it uses it's own internal representation of |
1168 | does it support it. Instead, it uses its own internal representation of |
| 1169 | B<wchar_t>. This is, of course, completely fine with respect to standards. |
1169 | B<wchar_t>. This is, of course, completely fine with respect to standards. |
| 1170 | |
1170 | |
| 1171 | However, that means rxvt-unicode only works in C<POSIX>, C<ISO-8859-1> and |
1171 | However, that means rxvt-unicode only works in C<POSIX>, C<ISO-8859-1> and |
| 1172 | C<UTF-8> locales under FreeBSD (which all use Unicode as B<wchar_t>. |
1172 | C<UTF-8> locales under FreeBSD (which all use Unicode as B<wchar_t>. |
| 1173 | |
1173 | |
