At 11:43 AM -0400 10/2/01, DougEwell2@cs.com wrote:
>
>You might start by checking existing fonts, especially those shipped with
>major operating systems, to see what PUA code points are commonly used
>internally for glyphs not associated with a standard Unicode character. I
>know that several Windows fonts have privately assigned glyphs, and I assume
>the same is true for Macintosh fonts.
The current generation of font tools does not generally allow the
creation of a glyph in a font without assigning it a code-point of
some sort. As a result, there are a number of fonts out there that
have PUA code points assigned to them, but *not* as a means of
promoting interchange of these glyphs in plain text, but as a means
of easing the font production process.
>Also, maybe the various font makers
>who haunt this list could contribute any guidelines they know of for
>quasi-standardizing these code points.
Adobe has a list somewhere at its site of how it uses the PUA. Apple
also pubishes its PUA use.
>Obviously, you are hoping that
>standardizing the code points could lead to some measure of interoperability;
>otherwise there would be no discussion. If all you want is to encode the ct
>ligature in a font, you can use any old PUA character you wish, conformantly.
>
>OTOH, private creation of quasi-standards on the part of vendors is not
>necessarily a good thing. It is the sort of thing that the public tends to
>vilify Microsoft for doing.
The purpose for both Adobe and Apple, at least, in making their PUA
use public is to avoid collision more than to promote interchange.
There is near-universal agreement that the way to get MS Word to
handle ligatures correctly is for it to beef up its OT/AAT support.
>If you want to interchange the ct ligature and the long-s ligatures, you can
>do that right now. Just encode <c, ZWJ, t> or <long-s, ZWJ, whatever>.
>Then, rendering engines that have a glyph for the desired ligature can render
>it, and those that don't will fall back to the individual characters
>(assuming they are conformant). This approach has at least three major
>advantages:
>
>(1) It is already supported by the Unicode Standard.
>(2) It provides a standard interchange mechanism without requiring font
>vendors to agree on the code point used for the precomposed glyph.
>(3) It provides a sensible fallback mechanism for the great majority of
>fonts that, let's admit it, will not have these specialized glyphs.
BTW, I'm not aware that anybody is revising their fonts to handle ZWJ this way.
Anyway, there is is a long-standing argument on this subject, and
unless I misremember the official position of the UTC, this approach
--specifying ligation control in plain text -- is not considered the
best mechanism in Latin typography.
The problem is that ligation control is *very* font-specific in Latin
type. Different fonts will have different sets of ligatures
available to them -- you can compare the set of ligatures in a font
like Courier (which has fi and fl only because MacRoman forced them
to be present and should, typographically, have no ligatures at all),
with the set in a font like Adobe Garamond Pro, with the set in
Hoefler Text, with the set in Zapfino.
On the whole, one cannot assume that the user can even anticipate the
set of ligatures that the type designer will consider appropriate for
their typeface. It's only when you have the typeface specified that
you can meaningfully begin to specify the set of ligatures to use.
The consistent approach of font vendors towards the problem if
ligation is not to include the request for them in plain text, and
definitely *not* to use distinct code points to represent them.
--John H. Jenkins jenkins@apple.com jenkins@mac.com http://homepage.mac.com/jenkins/
This archive was generated by hypermail 2.1.2 : Tue Oct 02 2001 - 11:16:01 EDT