>I feel that this is a matter that needs to be formally resolved one way or
>the other, so that, if such a refusal has been declared then people who wish
>to have these characters encoded may act knowing that the Unicode Consortium
>will have legally estopped itself from making any future complaint that it
>has some right to set the standards in such a matter and that those people
>who would like to see the problem solved and ligatured characters encoded as
>single characters so that a font can be produced may proceed accordingly...
>perhaps approaching the international standards body directly if the Unicode
>Consortium refuses to do so without a process of even considering individual
>submissions on their individual merits...
This is all based on false assumptions and reflects a lack of understanding of Unicode and the technologies it is designed to work together with. The problem *has* been solved and does not require ligated *glyphs* to be encoded as distinct characters. You can see implementations working very nicely, for example, with Arabic or Devanagari ligatures in Notepad (or MS Word 2000) on any Windows 2000 system. Not only *can* production of fonts proceed accordingly, but such fonts already exist and are distributed in shipping products. MS products do not yet support Latin ligatures, but that is not an encoding problem -- it is a problem with the particular products in question (and MS is working to address it -- expect to see support for Latin ligatures in the next version of Office due out next year). There are other software products that do support Latin ligatures today without requiring them to be encoded as distinct characters.
Moreover, the Unicode Consortium does not have to concern itself with legal rights regarding what does or does not get encoded -- it owns the Unicode standard, and can decide to encode or not to encode as it sees fit. The Consortium has entrusted those decisions to its Technical Committee, and that committee has decided to work with implementation principles that do not in general require ligature glyphs to be encoded as distinct characters.
Furthermore, the Unicode Technical Committee will always, and does, consider *any* submission on their individual merits. Submitters do not always end up satisfied with the conclusions reached by the Committee, but that is another issue. Also, trying to by-pass UTC by going directly to ISO is not going to change anything since the corresponding ISO committee uses the same implementation principles (they are the ones that wrote the character-glyph model document, ISO/IEC TR15285 -- can be obtained for free from http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/ITTF.htm), and by mutual agreement nothing gets encoded by one committee unless ratified by the other.
If you're needing to see something in print, try section 2.2 "Unicode Design Principles" of TUS3.0, specifically the sub-section entitled "Characters, Not Glyphs".
>I feel that it would be quite wrong to pull up the ladder on the possibility
>of adding characters such as the ct ligature as U+FB07 without the
>possibility of consideration of each case on its merits at the time that a
>possibility arises.
The merits have been considered, weighed in the balance and found wanting. The fact that a ct ligature at FB07 is *not* needed is illustrated by the fact that you can produce that ligature from an encoded sequence of < c, t > in (for example) Adobe InDesign using appropriate fonts (such as Adobe Minion Pro).
>If the possibility of fair consideration is, however, still open, then the
>ct ligature could be defined as U+E707 within the private use area and
>published as part of an independent private initiative amongst those members
>of the unicode user community that would like to be able to use that
>character in a document by the character being encoded as a character in an
>ordinary font file. That would enable font makers to add in the ct
>character if they so choose.
You can look for others with which to make a private agreement if you so choose, but don't expect the major type foundaries to encode a ct-ligature glyph at e707: they already know that they don't need to, and a number of fonts already include it without having resorted to direct encoding.
>My point is that the specification purports to lay down the rules, yet there
>seems to be many other pieces of information that seem to be "understood" on
>a nudge nudge basis
Not at all. If you were to attend a conference, you would find sessions discussing some of these implementation issues. If you were a professional font developer, then you would find these issues discussed at professional conferences such as ATypI, and you would probably already know of resources that explain them on the web. This is not secretive stuff; the VOLT user community, for example, has over 1700 members -- these are people interested in development of OpenType fonts that handle exactly the kind of problem you're talking about without encoding ligatures as distinct characters.
As far as the Unicode Standard is concerned, you don't see technologies like OpenType discussed since the Standard states clearly that those issues are outside of its domain (see TUS3.0 section 2.2).
>It is unfortunate that an attempt to quite
>happily seek to use the private use area as set out in the specification,
>where the word "published" is used, seems to become controversialized.
It is not the desire the use the PUA as set out in the Standard that is controversial; it is the claim that direct encoding of ligature glyphs is necessary that is most controversial (and simply false), as well as the suggestion that there should be a broad consensus among users and 3rd party developers (font vendors) regarding PUA assignments.
- Peter
---------------------------------------------------------------------------
Peter Constable
Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
E-mail: <[EMAIL PROTECTED]>
