> > > This is not merely a question of backwards compatiblity. In many cases,
> > > wide alphabetic characters are desirable in a CJK context. There is a
> > > common Japanese habit of writing abbreviations like NATO and short even
> > > words like FAX untranslated in wide capital letters in the text.
> ISO 6429 = ECMA 48 define a range of private ESC control sequences, and
> we could very well define such private ESC sequences for switching
> between the following modes
> - always use the narrow font
> - always use the wide font
> - use wide font for EastAsian W/F characters and narrow for all others
Assuming that the above are single shifts, not brackets pairs, then
in addition two bracket pairs are needed
<narrowfont>to code or not to code, that is the question</narrowfont>
because often whether wide or narrow is used will not be left to the
context (set by one of the three shifts sequences) but people will want
to determine it explicitely.
> - [ perhaps also: use the narrow/wide font in a way compatible with
> some national standard (e.g., EUC).]
The last could mean an algorithm that will use wide fonts for capital
latin character words of <=4 characters surrounded by CJK text. Or maybe
one from a set of user implementable algorithms. Probably this would be
rarely used, because the decision may depend on factors that can't be
handled by algorithms. Nor by contexts, which is why I proposed
the above explicit bracket pairs.
Is extending ISO 6429 the right path?
Can such an extended set of escape sequences be implemented in our
terminals (xterm/linux/kermit) ?
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:51 EDT