Re: (long) Re: Chromatic font research

From: William Overington (WOverington@ngo.globalnet.co.uk)
Date: Sat Jun 29 2002 - 05:47:17 EDT


><sigh /> OK, here are the details. I'm reluctant to admit having been
>part of this "experiment," since it is now being presented as evidence
>to support the proliferation of private-use ligatures.

Actually, no. What I am seeking to use it as evidence for is the addition
of ligatures such as ct to the U+FB.. block of regular Unicode. In the
recent post I used it as evidence that ideas about what should not be
included in Unicode can change over a period of time as new scientific
evidence is discovered.

My point in citing The Respectfully Experiment being that in an OpenType
font, which is the type of font which James Kass was using, the ct glyph is
accessible by c ZWJ t yet is not accessible directly using regular Unicode.
Adding U+FB07 as a ct ligature would mean that an OpenType font would still
normally use c ZWJ t to access the ct glyph, yet people with older
equipment, or some older software, could also access the same glyph directly
as U+FB07.

This use of two routes to the same glyph in an OpenType font, one newer
method together with one older method, seems to me to be a development,
which James Kass thought of, which would potentially be of benefit to end
users as it would mean that ligature glyphs provided in OpenType fonts could
be accessed by users of older equipment as well as by users of newer
equipment. Certainly it would not be leading edge use of technology for
document storage, yet it could be useful for people wishing to print stylish
pages of text locally or to prepare document transcriptions using older
equipment which transcriptions could then be sent or taken somewhere and
processed into the newer ZWJ style format. For example, suppose a team of
people working using open access computers in a library is transcribing
various old books using the older software on those older computers. Once
the files are on a floppy disc they can be taken or sent to a more modern
computer and the files converted to using a ZWJ format for ligatures, before
the files are added into the database of files of transcriptions. Bearing
in mind the way that research projects often have to get by as best they can
with the equipment that is already there, it just seems to me that some
extra ligature characters in the U+FB.. block would be useful.

Now, certainly this effect can be produced now using the Private Use Area
code points which I have suggested, as James Kass has demonstrated, yet I
feel that it would be better if it could be done with regular Unicode code
points.

My point in citing The Respectfully Experiment in the recent post is that
even though the reasons for not including any more ligatures in Unicode may
have seemed totally reasonable at the time that that decision was made, the
idea of James Kass that the glyphs for ligatures in an OpenType font could
also be accessed directly does add new evidence to the situation. In the
light of this new evidence, I am wondering whether the decision not to
encode any new ligatures in regular Unicode could possibly be looked at
again.

Now, I do not regard this adding of ligatures as a major issue. Certainly I
would like it to happen if it can be done as a fairly straightforward
exercise without any great problems or taking up of great amounts of
committee time, yet if it cannot be done or would cause great anguish and
arguments, well, that is that, forget it.

>I don't think William really meant "in conjunction with" in the sense
>that ZWJ would be applied directly to precomposed ligatures. He meant
>in the same document, or maybe not even that, maybe just that both types
>of ligation (precomposed and ZWJ) would be conformant to Unicode.

My intended meaning was that both types of ligation (precomposed and ZWJ)
could be in the same font.

>Nothing about "The Respectfully Experiment" -- and no appeals that users
>of 80386 PCs must be able to reproduce 18th-century ligatures in plain
>text -- will serve as the "evidence" that William is waiting for to
>overturn the decision not to encode any more precomposed ligatures.

Well, it is for far more recent machines than for 80386 PCs, such as for
many Pentium based machines running Windows 95 and Windows 98.

Also, it is not a matter of overturning a decision, it is a matter of the
decision being modified in the light of the new evidence, namely that both
methods may be used simultaneously in an OpenType font.

And I am not waiting for this to happen. This post makes the scientific
situation quite clear and if the committee chooses to encode some more
ligatures in the U+FB.. block then that is great, but it is not an event for
which I am waiting. Unless any other aspect arises, such as a need for some
more ligatures or some more ligatures being added into regular Unicode, I
have no intention of either adding to, changing or deleting the code point
documents for ligatures that are currently available in our family webspace.

http://www.users.globalnet.co.uk/~ngo/golden.htm

I produced the lists during a period of time and that project is, unless
something comes up, complete.

----

On the matter of markup I think that it is perhaps best that we agree to differ. I do have a special application area where using extra code points will hopefully be very beneficial as it saves the local program needing to parse the markup for meaning as the meaning is obtained directly from one Unicode character. This application area is for my telesoftware invention, which involves broadcasting software in television signals. Telesoftware produces the effect of a remote access computer system without the use of a telephone line or any return information link to the central broadcasting computer, by means of the unidirectional cyclic broadcasting of software and its selective use by a computer in a television receiver. Java is being used for the programs which are broadcast, and Java uses Unicode, so using Unicode code points for each item such as GREEN and 36 POINT will, for such a Java application reading from a text file, potentially be very beneficial.

Also, use of additional code points for loading data into a graphics processing program and manipulating that graphics data and drawing it on the television screen in conjunction with drawing text on the television screen is a potentially very powerful technique which will enable magnificent graphics effects to be included in text files, thus enabling people with no knowledge of Java programming to prepare graphics for learning material which is to be broadcast.

It would be nice to have regular Unicode code points for the various features, yet if that is not possible I can publish a set of Private Use Area code points myself for use within programs by any programmers who choose to use them, though it would help standardization of software and be a more rigorous solution if the code points were regular Unicode rather than just Private Use Area allocations.

In relation to this broadcasting system, users might like to have the following links.

http://www.mhp.org

http://www.mhp-forum.de

http://www.mhpdev.net

http://www.users.globalnet.co.uk/~ngo/ast00000.htm

http://www.users.globalnet.co.uk/~ngo

William Overington

29 June 2002



This archive was generated by hypermail 2.1.2 : Sat Jun 29 2002 - 04:33:32 EDT