diff options
author | Kristaps Dzonsons <kristaps@bsd.lv> | 2011-05-17 22:32:45 +0000 |
---|---|---|
committer | Kristaps Dzonsons <kristaps@bsd.lv> | 2011-05-17 22:32:45 +0000 |
commit | 9fbd9ce5cadeb91ed28f18559e80d0bb5a2e1d54 (patch) | |
tree | 29d663369951c30cefc0d594ac559ef72b0bf666 /regress/man/UC/UC.in | |
parent | 0587ad80d46d89f36315c37bbd67cf8899708b8d (diff) | |
download | mandoc-9fbd9ce5cadeb91ed28f18559e80d0bb5a2e1d54.tar.gz mandoc-9fbd9ce5cadeb91ed28f18559e80d0bb5a2e1d54.tar.zst mandoc-9fbd9ce5cadeb91ed28f18559e80d0bb5a2e1d54.zip |
Locale support. I'm checking this in to clean up fall-out in-tree, but
it looks pretty good. Basically, the -Tlocale option propogates into
term_ascii.c, where we set locale-specific console call-backs IFF (1)
setlocale() works; (2) locale support is compiled in (see Makefile for
-DUSE_WCHAR); (3) the internal structure of wchar_t maps directly to
Unicode codepoints as defined by __STDC_ISO_10646__; and (4) the console
supports multi-byte characters.
To date, this configuration only supports GNU/Linux. OpenBSD doesn't
export __STDC_ISO_10646__ although I'm told by stsp@openbsd.org that it
should (it has the correct map). Apparently FreeBSD is the same way.
NetBSD? Don't know. Apple also supports this, but doesn't define the
macro. Special-casing!
Benchmark: -Tlocale incurs less than 0.2 factor overhead when run
through several thousand manuals when UTF8 output is enabled. Native
mode (whether directly -Tascii or through no locale or whatever) is
UNCHANGED: the function callbacks are the same as before.
Note. If the underlying system does NOT support STDC_ISO_10646, there
is a "slow" version possible with iconv or other means of flipping from
a Unicode codepoint to a wchar_t.
Diffstat (limited to 'regress/man/UC/UC.in')
0 files changed, 0 insertions, 0 deletions