[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: www/w3m: m17n flavor
- To: ports_(_at_)_openbsd_(_dot_)_org
- Subject: Re: www/w3m: m17n flavor
- From: Yozo TODA <yozo_(_at_)_imit_(_dot_)_chiba-u_(_dot_)_ac_(_dot_)_jp>
- Date: Tue, 10 Apr 2001 18:00:21 +0900
> env FLAVOR='kanji m17n' make package
> This will currently build w3m with
> 1. Japanese menus and documentation,
> 2. internal use of Unicode for character set conversion,
> 3. UTF-8 display by default.
aha, I see.
I found the description about FLAVOR only in bsd.port.mk(5) man page
("FLAVORS AND MULTI_PACKAGES" section).
how about adding some info about FLAVOR to ports(7) man page?
> The real alternative is replacing (2) with an ISO-2022-based scheme.
> Possibly it doesn't convert at all then, maybe it merely uses
> kterm's ISO 2022 character set switching abilities. I know too
> little about East Asian character set issues. I am fairly certain,
> though, that this doesn't affect monolingual Japanese texts at all.
> It may make some difference when you mix Japanese and Chinese.
ISO-2022 codings use escape sequences for each coding system;
it can differ japanese and chinese (and korean, and ...) codings
with escape sequence. it means
the application like kterm can use a font data
(glyph? I don't know the correct wording...),
which is designed for japanese characters, for japanese strings, whereas
use another font data, designed for chinese characters, for
(BTW, I don't know which "esc $ A" means,
traditional, or simplified chinese...)
I suppose Unicode use only one font data, so, it mayìconfuse users
(use japanese font data for chinese strings, or,
use chinese font data for japanese strings);
one of reasons Unicode is not so welcomed in east-asian region.
> BTW, I think that "kanji" is a misnomer for the flavor. I should
> probably just change it to "japanese". Opinions?
I suppose the word "kanji" come from the original w3m.
I think, too, "japanese" is more reasonable description.
Visit your host, monkey.org