HP-UX Plug

[Wayne Krone]

> I had mentioned problems with International language support with HP-UX.
> I've been corrected by the folks at HP, who say that they are in fact
> X/OPEN compatible.  I accept this as true.  I should have been clearer
> in saying that my concerns lay mostly in the Japanese/Chinese arena.

> The new question is, is HP-UX in full conformance with all of the Japanese
> JIS standards ?? Compatible with the AT&T Sys V NLS, which seems to have
> many vendors supplying conformant products ??  
>
>  rja at edison.GE.COM or ...!uunet!virginia!edison!rja

and

> Unfortunately we don't conform to JIS.  HP merged support of Katakana
> (phonetic language) with a "subset" of JIS characters to produce
> a monster known as "HP-15".  HP may get its butt kicked for it later.
> 
> -- Mike Light  (HP: Industrial Applications Center)
> hpda!hpiacla!mlight

This is not correct.  HP-15 is a superset of Shift-JIS which supports
all the characters defined by JIS C-6220 and JIS C-6226.  Shift-JIS
has become the de facto standard on personal computers in Japan and
is used by a number of suppliers of UNIX(*) operating systems as can
be seen in the following list:

-------------------
Kanji UNIX in Japan  (as of ~Jan 87)
-------------------

Yokogawa Hewlett Packard	- HP15 (superset of Shift JIS)
Sony				- Shift JIS
Toshiba				- JIS C-6226
AT&T Pacific			- JAE EUC (JIS C-6226 + JIS C-6220)
Data General Japan		- original
DEC Japan			- Dec Kanji code (similar to AT&T Pacific)
Sharp				- JIS C-6226
NCR Japan			- Shift JIS
Hitachi				- Shift JIS
NEC				- JIS C-6226
Mitsubishi			- EBCDIC
Panafacom (Matushita + Fujitsu)	- original (similar to JIS C-6226)
ASCII				- Shift JIS


Both HP's and AT&T's NLS products have two sides: a set of proprietary
features and a set of standard (X/Open, ANSI, etc.) features.  HP, AT&T
and others are devoting significant resources to the task of making
many of the proprietary features part of standards which we can all
then support in our implementations.  Through X/Open and /usr/group
internationalization efforts, quite a lot of progress has been made in
the area of supporting Western-European based languages.  We are just
beginning to address the needs of Asian languages (see, for example,
the multibyte support in the latest ANSI-C draft).

The problem with code sets, however, is that there is an over abundance
of standards to choose from.  Each has their advantages and disadvantages
for a particular implementation and set of users.  HP-15, for example,
can support a larger number of kanji characters than AT&T's JAE EUC.
Whether or not this is significant depends upon the needs of each
company's set of customers.  On the other hand, EUC requires less
modification of UNIX commands because the code set values for ASCII
characters are never used as part of a multibyte kanji character.
Whether or not this is significant depends upon the resources available
to internationalize the commands.

Looking ahead, my personal opinion is that vendors will probably come to
support several of the currently competing code sets as a means of
expanding their pool of potential customers.  The ultimate solution may
be a global code set that simultaneously supports all world's languages.
Joe Becker of XEROX presented the basis of such a code set at a recent
/usr/group Internationalization meeting.

Wayne Krone
Hewlett-Packard NLS Project

* UNIX is a registered trademark of AT&T