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
