I downloaded a copy of Mr Miller's pdf format document and spent a short
while looking through it. I found on pages 29 and 30 a section entitled
"Arrow parentheses" which, if I may be permitted to say so, is excellent. I
began to think of the possibilities that the eight characters which Mr
Miller has invented could become widely used as a way to express powers,
subscripts, upper limits of definite integrals and summations and lower
limits of definite integrals and summations in unicode plain text files.
Perhaps Mr Miller might be encouraged and assisted to designate eight code
points of the unicode private use area for their definition as a practical
way to get them available for people to try out experimentally in text
editors and graphical processors, perhaps U+E300 through to U+E307 would be
a good choice, in the order that the glyphs appear on pages 29 and 30 of the
pdf document. I hope that, in due course, arrow parentheses might become
candidates for upgrading to become regular unicode characters, if such an
upgrading of characters that quite specifically would display one way in a
text editor and another way in a graphical display is compatible with the
underlying concepts of unicode. If I understand arrow parentheses
correctly, someone authoring a document that involves a definite integral
would, using the four arrow parentheses that have double arrows, be able to
write with pen upon paper exactly, precisely, his or her equation or
expression in one line of text. This hand written text could then be keyed
into a text editor where the arrow parentheses would appear on the screen as
symbols. However, upon processing through a suitable graphical display
processor, the limits of the definite integral would appear in the correct
place and the arrow parentheses would not show at all on the graphical
display. Thus, an author could write a handwritten manuscript and the
finished equation appear on screen in a professionally laid out standard
mathematical format in a straightforward sequence of events. This could
potentially reduce keying errors and save keying time.
On the wider issues of Bytext I began to wonder whether there may be some
other features that, upon careful consideration, might be usefully
implemented to work in conjunction with unicode. I do not know enough of
the issues involved and have not studied the Bytext document for sufficient
time to form an opinion. However, I did feel that as Bytext is a sequence
of eight bit characters that it would be possible for Mr Miller to designate
256 characters from the private use area of unicode so that Bytext could be
represented as a sequence of unicode characters in a unicode plain text
document. This would enable the possibility of any features of Bytext that
do find favour with a reviewing audience to be tested out and used sitting
upon the infrastructure of unicode handling software that already exists.
For example, such private use area codes could be passed into a Java applet
on a web page from a parameter string of the applet call or from a text box
and manipulated as unicode characters and some Java software within the
applet used to try out the new features. For example, if Mr Miller were to
choose, say U+E400 to U+E4FF to each represent one byte of Bytext code, so
that, for example, U+E421 would represent a Bytext code of hexadecimal 21,
then a Bytext sequence could be embedded in a unicode plain text file using
a sequence of such unicode private use area codes. Use in a param statement
of an applet call or in a text box of a running applet could be by inputting
'ue421 within a text string and then have the Java of the program use the
six character sequence to produce one 16 bit unicode character U+E421.
William Overington
26 January 2002
This archive was generated by hypermail 2.1.2 : Sat Jan 26 2002 - 08:40:56 EST