Name: clC74495			Date: 06/04/98


I submitted bug/proposal 4072406.  The evaluator
misunderstood the 2nd part of my proposal.
I proposed adding support for HTML/SGML/XML-type
character entity names (&name;) so that non-ASCII
characters can easily be entered into:

1) Java source code - This is a mere convenience
for me.  This is what the evaluator evaluated.
Forget it.  I don't really care about it.
I can use \uxxxx format.

2) TextFields in a running Java program -
This is the important issue: How do users
enter Unicode characters into a running
Java program?

Sample Uses:

* A user wants to put a Chinese character
into a Java text editor.
* A user wants to put a Greek character
or math symbol into
the axis label for a graph in a graphing
program.

* Java has made great effort to support
Unicode: reading/writing Unicode in
various character encodings in files
and internal support for 32 bit char
and Strings.  But there is no standard
way for a user to enter characters beyond
255 into a textField.

* In Windows 95, I can enter some (not all!)
of characters 160 - 255 with the Alt+0xxx
technique.  But there is no support for other
characters (beyond 255).

* In Windows 95, I can call up the system
character map.  But this just generates a
character number 0 - 255 in a Windows font.
(Users are then supposed to paste the character
into their word processor document and manually
change the font to some other Windows font,
e.g., Map Symbols. But Java programs can't
access many system fonts.)
The character map does not generate the
Unicode character, which is what the Java
program needs to receive.

* Users in other countries often have easy
access to some of characters 160-255 from their
keyboard, but I (in the U.S.) don't.

* Yes, I have in fact made my own translator
so that users can enter character entity names
in my programs and
my programs can translate them to/from
Unicode characters.  I got some SGML/XML names
from Rick Jelliffe (###@###.###)
(file: xml-ISOents.txt at
www.sil.org/sgml) but it is incomplete and
I made up some myself.  Most I just support
via &number; But shouldn't
there be a standard way to do this?

* I think it is important that there be
standard names.  Users
shouldn't have to know my companies'
names and some other companies' names.
The names should be consistent across
all programs (hopefully, across XML, too).
The standard needs to be set by Java.

* Quick: how would you enter a Greek alpha
into a textField in a Java program?

Alternative:

Character entity names are nice, but it would
be a big system and a big job.  Perhaps
there could be some other (standard!) way
to enter characters based on their numbers.
For example, an extension of the Windows
system of Alt0xxxx that supported Unicode
numbers.  I could provide my users with
online tables of character numbers and
symbols.

Character numbers wouldn't be as easy
for users: I think
alpha is easier to remember as &agr;
(say "a Greek") than
as Altx3b01 (actually, I would prefer
α, but I'm not in charge of SGML).
And if you know &agr;, you can guess
that mu is &mgr;.
But Alt0xxxx numbers would be a system to
get those characters in to TextFields.

Final plea:

I think it is important that there be
a standard way to do this.  So that
a user on Windows, Mac or Unix systems
do it the same way.  The operating
systems aren't helpful here; Java
needs to lead the way.


Thank you.
(Review ID: 25924)

* Java has made great effort to support
Unicode: reading/writing Unicode in
various character encodings in files
and internal support for 32 bit char
and Strings.  But there is no standard
way for a user to enter characters beyond
255 into a textField.

* In Windows 95, I can enter some (not all!)
of characters 160 - 255 with the Alt+0xxx
technique.  But there is no support for other
characters (beyond 255).

* In Windows 95, I can call up the system
character map.  But this just generates a
character number 0 - 255 in a Windows font.
(Users are then supposed to paste the character
into their word processor document and manually
change the font to some other Windows font,
e.g., Map Symbols. But Java programs can't
access many system fonts.)
The character map does not generate the
Unicode character, which is what the Java
program needs to receive.

* Users in other countries often have easy
access to some of characters 160-255 from their
keyboard, but I (in the U.S.) don't.

* Yes, I have in fact made my own translator
so that users can enter character entity names
in my programs and
my programs can translate them to/from
Unicode characters.  I got some SGML/XML names
from Rick Jelliffe (###@###.###)
(file: xml-ISOents.txt at
www.sil.org/sgml) but it is incomplete and
I made up some myself.  Most I just support
via &number; But shouldn't
there be a standard way to do this?

* I think it is important that there be
standard names.  Users
shouldn't have to know my companies'
names and some other companies' names.
The names should be consistent across
all programs (hopefully, across XML, too).
The standard needs to be set by Java.

* Quick: how would you enter a Greek alpha
into a textField in a Java program?

Alternative:

Character entity names are nice, but it would
be a big system and a big job.  Perhaps
there could be some other (standard!) way
to enter characters based on their numbers.
For example, an extension of the Windows
system of Alt0xxxx that supported Unicode
numbers.  I could provide my users with
online tables of character numbers and
symbols.

Character numbers wouldn't be as easy
for users: I think
alpha is easier to remember as &agr;
(say "a Greek") than
as Altx3b01 (actually, I would prefer
α, but I'm not in charge of SGML).
And if you know &agr;, you can guess
that mu is &mgr;.
But Alt0xxxx numbers would be a system to
get those characters in to TextFields.

Final plea:

I think it is important that there be
a standard way to do this.  So that
a user on Windows, Mac or Unix systems
do it the same way.  The operating
systems aren't helpful here; Java
needs to lead the way.


Thank you.




(company - CoHort Software , email - ###@###.###)
======================================================================