Re: Special Type Sorts Tray 2001 (derives from Egyptian Transliteration Characters)

From: Peter_Constable@sil.org
Date: Tue Oct 02 2001 - 16:58:30 EDT


>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: <peter_constable@sil.org>



This archive was generated by hypermail 2.1.2 : Tue Oct 02 2001 - 15:54:16 EDT