Peter Constable wrote as follows. >Well, only that it would make it easier for us to avoid proliferation of >fonts while also providing fonts that our users can use with current >software that does not yet provide means of selecting glyph alternates.
Would the encoding that would be intended to be used in the long term use of Unicode be to use one of the characters from the range U+FE00 to U+FE0F following the main character code so as to indicate the glyph alternate? >But, I've been vocal about not encoding presentation forms more than once >on this list, so I guess I need to swallow the same medicine I dish out. Well, if you are referring to ligatures such as ct and the like, the situation here is surely different. For example, suppose that, in relation to the stroked characters, someone is wishing to write a scholarly text explaining the various encoding characters which have been used, then the use of different encodings for the glyph variations would seem reasonable. It seems to me that this discussion however does have the same form as the discussions about precomposed ligature characters such as ct and the like in the following respect. It seems to be regarded as that there are two possible solutions. 1. Define regular Unicode or Private Use Area code point allocations for the presentation forms and produce a display now, though losing such features as spellchecking and sorting. 2. Stick closely to a "tools and gadgets" encoding which is well engineered and elegant, preserving such features as spellchecking and sorting, yet either unusable on any available platform or, for some features, only usable on "the very latest equipment". Upon considering the matter I am wondering whether there should become mainstream a third approach whereby documents are encoded in the "tools and gadgets" manner, and used in that format for spellchecking and sorting, together with software facilities, which can run on all platforms, which produce temporary documents "on the fly" for display using such fonts as ordinary TrueType fonts where the necessary presentation forms are encoded so as to be accessible from individual code points, such as code points in the Private Use Area. Certainly, the fonts could be advanced format fonts which have the glyphs accessible by two routes, a direct "tools and gadgets" sequence of code points and also a direct code point access route. I feel that if software packages were developed, whether as stand alone packages or as plug-ins, which could have a Unicode file with "tools and gadgets" encoded content as input and produce as output a Unicode file with "direct code point" encoding, then maybe the elegant "tools and gadgets" encodings could become more widely used sooner than would be otherwise the case and that the desired displays could be used on other than the very latest equipment. I feel that this third approach might well be extremely useful. I am aware that this approach does need tables of code points in the Private Use Area to be widely used. I am fully aware that the Unicode Consortium is unable by its rules to provide any code point allocation tables for Private Use Area usage in this or any other manner and that, even if it were able might well not wish to do so. However, I am also aware that publication of such tables by end users is permissible. Now, I am aware, from my own publication of code point allocations in the Private Use Area for ligatures, that not everyone approves of such publication of code point allocations in the Private Use Area where those code points are being suggested for use in interchanged documents. A variety of views exists. However, what I am suggesting here is not the same qualitatively. Here I am suggesting for this "third approach" that documents be interchanged in a regular Unicode "tools and gadgets" encoding and that the documents produced using Private Use Area code points are only local temporary documents produced and used locally for presentation, then discarded, yet that the Private Use Area code point allocations are published so that there can be portability and interworking between software and plug-ins and fonts from a variety of suppliers, be the suppliers commercial organizations, academic organizations or individuals. The idea is that eventually such Private Use Area code tables would be used by fewer and fewer end user systems as the availability of software and platforms which will directly decode and display all "tools and gadgets" Unicode encodings increases. However, eventually might be a very long time in view of the number of older computers deployed around the world. For the avoidance of doubt I am not suggesting that the Unicode Consortium itself should produce those Private Use Area code tables as the necessary software packages and the code point tables need to be produced by end users of the Unicode system. An internet browser using this third approach would be a good project as would a word processor. Could existing products be easily adapted or would new products be needed? A good benchmark test might be to send c ZWJ t in a document and, using U+E707 to access a precomposed ct ligature glyph, display the ligature on the screen of a computer which cannot use an advanced format font by means of the receiving software automatically producing a temporary local document wherein the U+E707 code is used instead of the c ZWJ t sequence of the transmitted document. How difficult is that benchmark to achieve please? Is it a major software development or could it be written into a macro by a knowledgeable person within a few hours? William Overington 6 September 2002
