Re: Inappropriate Proposals FAQ

From: William Overington (WOverington@ngo.globalnet.co.uk)
Date: Fri Jul 05 2002 - 10:21:49 EDT


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



This archive was generated by hypermail 2.1.2 : Fri Jul 05 2002 - 08:45:50 EDT