Suzanne M. Topping responded to one of my postings.
>> -----Original Message-----
>> From: William Overington [mailto:WOverington@ngo.globalnet.co.uk]
>
>> It would seem that it would be entirely within the letter and
>> the spirit of
>> that definition to use code points in regular Unicode to
>> denote all manner
>> of items for human and computer communication.
>
>Given the frequency that these types of issues come up, I wonder if it
>would be useful to list a few examples in the FAQ of what would -not- be
>considered for inclusion in future releases of the standard?
If such examples were included it would be very important to ensure that
future progress and invention were not being curtailed by an agreement
amongst companies that some types of characters are not to be encoded in the
future. For example, a recent experiment, documented in the archives of
this list as The Respectfully Experiment, shows that there is now new
evidence about the facts regarding the encoding of code points for
ligatures, because it has now been realized that such code points can now be
used in conjunction with ZWJ type mechanisms of advanced font technology
formats as an alternative method of coding to assist people with less than
the latest equipment, such code points for ligatures working in conjunction
with advanced font technology rather than as an alternative to it which is
the way that such code points were regarded when a decision not to encode
any more of them without a strong case was taken, though even for that
decision there was provision for the general thrust of that decision to be
overridden in the light of future evidence.
There is at present a barrier, which I feel might be called the markup
barrier, which is acting as a barrier to progress. I wonder whether the
markup barrier is some absolute barrier or whether it is just a temporary
thing which exists in people's minds because in ASCII there were only 128
code points and so the character < was used as a clever way to allow greater
meaning to be incorporated into plain text files because the few direct
markup characters in ASCII were not sufficient for emerging needs. I find
that I am thinking of the rete of an astrolabe, which would ideally have
been made of a piece of strong transparent plastic, yet, since strong
transparent plastic was not available in medieval times, an ingenious
technique of using a piece of brass with a fretwork design cut out of it was
used so as to give as good an effect as possible as close to a piece of
transparent plastic as the technology of the time would permit. There was
the sound barrier in aviation which was seen as a major, possibly
impassable, barrier until it was passed. So, the concept of a markup
barrier seems a reasonable concept to discuss.
Is the markup barrier absolute or is it just that the markup barrier is
regarded as being an absolute barrier because of a fallacy of reasoning in
that whereas
1. markup is useful in some circumstances,
2. markup provides the opportunity to encode a system without a need to have
additional code points,
3. markup does not have a requirement to have meanings assigned to code
points by a standards committee,
that those reasons, set against a historical background, have led to a view
that code points cannot be used for things for which markup is presently
used, notwithstanding that there seems to be nothing in the definition of
character that is being used that would seem to go against using code points
directly for such meanings as 36 POINT and GREEN.
I am quite prepared to accept that I may have got it wrong and that there
may be some entirely logical reason for the markup barrier to be an absolute
barrier. However, I do wonder about whether the markup barrier is really
just a fallacy and that it really comes down to a notion that if something
could be done using markup that it should be done using markup,
notwithstanding that it might perhaps be done better in some situations
using code points than using markup.
For the avoidance of doubt I am not saying that markup should not be used in
the future and I am not saying that all uses of markup should also be
encoded as code points. Aviation still uses subsonic flight, yet also uses
supersonic flight in appropriate circumstances. A counterbalance is that,
for example, the famous Anglo-French Concorde aircraft fly supersonically
across the Atlantic ocean but are not allowed to travel at supersonic speeds
over the United Kingdom mainland (and possibly not over other land areas as
well, but I do not know the details).
>
>For example, I'm guessing that my idea for encoding furniture icons and
>room positioning indicators so that I could create floor layouts using a
>text editor, would probably not be accepted. (No doubt because corporate
>giants are trying to prevent the incredible financial success I would
>realize if they allowed it.)
>
The important thing is not to guess too strongly. A well thought out and
documented idea might well be considered seriously by the committee.
You raise an interesting idea of an application. Many items of furniture
are built to standardized sizes. However there are exceptions. Also,
furniture items can be placed at various angles to the wall and to each
other. This raises an interesting idea. Suppose that there were a font
technology where the glyph for a particular code point sequence is drawn as
a result of inputting a ZWJ sequence where the second character of the ZWJ
sequence is a data value representing a rotation angle and that the font
contains a software subroutine so as to allow the rendering engine to use
that software subroutine and the angle provided by the second character so
as to draw an on-the-fly generated glyph. As glyphs are expressed using
points in order to produce Bézier curves, the processing for the rotations
is not too computationally intensive. Indeed, such a general method could
use a sequence of ZWJ spaced data items to encode position as well as
rotation if desired, or to customize the size of an armchair as necessary.
>Perhaps if there were a few (more?) places on the site which explained
>what Unicode is NOT, it would be easier for people to realize they
>should build an app to accomplish their goal instead. Examples of
>inappropriate submissions and explanations of why might help reduce the
>problem.
It would be a very interesting exercise for people to discuss exactly,
precisely what Unicode is not, giving detailed reasoning for each such claim
rather than simply saying that that is how it is, because if suggested
formal limitations of the scope of what could be encoded start to be
suggested then it may be that with its usual vigour that this discussion
forum would result in counter examples which would make many of the
suggested limitations obsolete. Maybe the markup barrier would be passed or
maybe the markup barrier would be proved to be a logical scientific barrier
which can never be passed.
William Overington
28 June 2002
This archive was generated by hypermail 2.1.2 : Fri Jun 28 2002 - 05:06:07 EDT