From keld@dkuug.dk Thu Jan  9 19:38:01 1992
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
	id AA05305; Thu, 9 Jan 92 19:38:01 +0100
Date: Thu, 9 Jan 92 19:38:01 +0100
From: Keld J|rn Simonsen <keld@dkuug.dk>
Message-Id: <9201091838.AA05305@dkuug.dk>
To: i18n@dkuug.dk, seki@sysrap.cs.fujitsu.co.jp, wg14@dkuug.dk
Subject: Re:  (SC22WG14.168) Re: support for symbolic character names
X-Charset: ASCII
X-Char-Esc: 29

discussion between Sekigushi-san and me:

> > It is a lowercase-o-with-stroke. If I want to write a portable
> > program, which tests for this letter, then it is very difficult.
> 
> O.K.  I agree with you on the point ``it is very difficult.''
> but, I don't agree the idea of ``a facility to do such a job
> easier will increase international portability of applications.''

I meant "international C programs" in the sense "programs not
written with the US market in mind". That is, a program maybe
written somewhere in Europe. but not nessecarily intended for
an international market. Say, in my environment I have PCs, UNIX boxes,
IBM mainframes, Macs  and some weird stuff, and I want a program to be
written for all these environments. A Danish program.
There this portability helps.
> 
> > It depends on the execution character set. In the one I am really
> > using now (IBM865) it is one value, in ISO8859-1 it is another,
> > and in MacIntosh it is yet another.
> 
> And, in my system, there is no such character.
> 
> My point is following: If an application *must* check whether a
> character is an o-with-stroke, it *cannot* be internationally
> portable.

I did not mean international in the sense internationalized (suitable
for localization) - as noted above.

> With your proposal, you could write a ``pseudo-portable'' program which
> tests against o-with-stroke like:
> 
> 	if (wc == L'\<o/>') ...
> 
> but it will cause an error like "character(s) specified by a symbolic
> name notation is not avalable."  Is this a portable program?

Well, yes it is: I can port it across a wide machine range with
different character sets. If the machine does not have the
character, then the condition will be false, and that is 
really the truth... it does not have the character.

> Or, with your function version, your could write:
> 
> 	if (wc == scntowc("<o/>")) ...
> 
> This version will be compiled successfully in all countries, but will
> or will not work appropriately...  On my system in Japanese locale,
> scntowc("<o/>") will return WEOF, and ``...'' part will never be
> executed.  If this code is used, for example, as a part of menu driver,
> I will not able to select an item represented by o-with-stroke.

It is hard to tell if a mchine has a particulary character.
I think your machine has that character, eg. in some font description
for X windows. And I would be able to connect to your machine,
load that font and run my danish application.

> My solution to menu drivers is using messaging facility.

Yes, that is a good thing for i18n applications.
Still you have the problem with different character sets,
where the notation can also be useful.

> >The mechanism is much in line with current documenter software
> >like TeX or SGML that has such symbolic names for "weird" characters.
> 
> Yes.  We can use such names safely in TeX, because TeX defines its own
> codeset (and because it supplies public domain fonts. :-)  The case is
> different from C applications.

You can say that C or POSIX applications also define their own
codeset, via the locale/charmap mechanisms. It is not that different.

Keld