Suzanne M. Topping wrote as follows. >I see the need for perhaps two entries: one which states clearly what >Unicode is NOT, and another which lists a few examples of innapropriate >proposals and why they would not be considered. This section would >probably refer to the "what Unicode isn't" entry for support of the >"why"s. > >I have a few ideas for fictional proposals to use as examples (my room >layout idea, and Mark's 3-D Mr. Potato Head representation), but I could >use another one or two if anyone feels creative. The closer to being >believable, the better, I suppose. (An alternative would be to use >real-life proposals, and state why they were not accepted, but I thought >it more politic to keep it fictional...)
Well, having seen your furniture and room layout idea, presented in the Unicode list, I figured out the method to use to enable your room layout idea to be produced, using the technique, novel as far as I know, of allowing a glyph to contain some software which could be obeyed by the rendering system so as to rotate the points of the Bézier curves of the contours of the glyphs of the items of furniture. This seems to me to be something of a breakthrough in the possibilities for fonts, as including software inside a font which could be obeyed by the rendering system would allow a rendering system to be customized from within a font. It would seem a pity to restrict the future development of the concept by a Unicode Consortium issued FAQ document stating that Unicode will not encode such symbols when it seems that it would be relatively straightforward to implement such fonts. The font would need to contain the software that is to be obeyed. This could be organized so as to be accessed when a glyph is selected, with a central place within the font to store any subroutines called from within the software of the individual glyphs. If this software were in some appropriate portable software format, then the specification of the font format would perhaps not be that difficult, it could be part of an advanced font format that supports both chromatic font information and software in the fonts. For example, the software in the font could be specified to be written in 1456 object code. http://www.users.globalnet.co.uk/~ngo/14560000.htm 1456 object code already supports double precision floating point items, integers, characters, strings, complex numbers and quaternions as standard types. Groups are also supported as a type experimentally. Consideration of this concept of software within the font has lead to consideration of how the position and rotation angle of the individual items of furniture could be set to an initial position from within the document and also as to how they could be adjusted by the end user using facilities set up from within the document and this has lead to the idea of having the document be able to open and customize a control panel, which control panel could contain buttons and scrollbars and so on and also a polar scrollbar for continuous rotational adjustment. It would seem, given the fact that 1456 object code supports quaternions and also has some functions of a quaternion variable built in as standard that this could be extended to three-dimensional rotations quite straightforwardly for applications that could use three-dimensional rotations. This is the sort of computational power which I feel that multimedia should be able to utilize, by including Unicode codes directly in a text file, so that the rendering system produces the control panel as instructed by the Unicode codes. This seems to be directly permissible within the definition of character in Annex B of the ISO document which was discussed recently, though perhaps not within the definition of character used by the Unicode Consortium at the present time. I feel that such ideas should not be thrown out by the Unicode Consortium publishing a FAQ document which would prevent it considering for inclusion glyphs in regular Unicode which could make good use of such technological advances. For the avoidance of doubt I am not saying that the Unicode Technical Committee should necessarily accept such items as your furniture idea for encoding, I am simply saying that any decision as to what may be encoded and what shall and what shall not be encoded should be made by the Unicode Technical Committee on the basis of the scientific situation at the time that an encoding proposal is formally considered. I feel that it would be a major error for the Unicode Consortium to publish a FAQ document which prejudices the fair consideration of characters based upon new technologies which may arise in the future. William Overington 5 July 2002
