From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Fri Mar 26 2004 - 18:00:25 EST
At 02:03 PM 3/26/2004, Ernest Cline wrote:
> > [Original Message]
> > From: Asmus Freytag <asmusf@ix.netcom.com>
> >
> > There are millions of fonts out there with variations of the zodiac. Font
> > shifting would seem to be the correct answer to implement glyph
>variations
> > there. (A wrong font will ruin the mood, but not change the identity of
>the
> > symbol). Math, and some linguistic notations are the opposite: a wrong
> > font, and you lose the
> > meaning of the text.
>
>It would be nice tho, if there was something like a Private Variation
>Selector.
>
>Consider for example, a font that offered both of the common glyph
>variants of PLUTO. At present, one would be have to be encoded as
>U+2647 and the other as a private use character, say U+E647. If a
>Private Variation Selector were available, then one could encode
>for that font, one form as U+2647 PVS1 and the other as U+2647 PVS2.
>Thus, even if the document was then rendered using a different font,
>the connection to PLUTO would still be kept no matter which glyph
>for PLUTO was used by the author, altho the desired glyph might not
>be shown. One could perhaps use the existing Variation Selectors
>to do this unofficially, but that is not sanctioned by Unicode. Indeed,
>a conforming implementation would have to render them the same
>as if no variation selector was present. Perhaps the added variation
>selectors on Plane 14 could be turned over to this usage, as it
>seems doubtful that they will ever be used for official variations,
>or a row of Private Variation Selectors could be added
>as U+E01F0 to U+E01FF.
There are discussions about variation selector schemes for use with
ideogaphs, where the problems are well-established. It is conveivable
that symbols do have similar issues. At the moment, we have only a
few *standardized* variation selectors for mathematical symbols.
There are situations where it's not clear whether the whole range of
core glyphs for a symbol really can be substituted for one another without
doing some violence to the text. For example, there are forms for
2114 (the lb or pound symbol). Unicode 2.0 showed a ligature of l b in
a Times like style with a cross bar, while Unicode 4.0 shows a flowing
form that looks more handwritten. It is incontestable that both mean
the same thing. It is less clear that both are equally well recognized,
so that an argument could be made that users should be allowed to make
a distinction between them. (Creating a separate font for an isolated symbol
like that is awkward, so unlike the choice between the forms of the letter
'a' (with and with out handle) it's not something that's tied to a
general design approach for a particular font style (and also, the
two forms of 'a' are much more definitely able to be substituted --
as long as one does not write IPA ;-).
For symbols, unlike scripts, it's not a-priori clear whether, when and
how to unify such variations. Unicode has proceeded with caution in
this area. That's only proper, since 'characters are forever'(tm).
However, that doesn't mean that it's not legitimate to re-think, and
possibly re-evaluate some of these unificattions. [I'm not arguing
for two versions of 2114 - I'm just taking it as an example].
Your argument, essentially, is that there is a gray area where it
would behoove the UTC to not get involved, so leaving the distinction
to private use - except using variation selectors so as to recover
the character semantics (and fallback glyph range). I think this is
a valid thing to consider.
The downside, to mention this right here, is that private use of any
form degrades interchangeability, but so does markup relying on the
availability of specialty fonts. Another drawback is the fact that
too few systems handle any variation selectors gracefully. The cost
to low level routines (like comparison) can be substantial. But, as
we have a foot in the door with some of our standardized variations,
we might as well figure out what we want to do with this concept.
In that spirit I appreciate your contribution as an impetus for
further discussion.
A./
This archive was generated by hypermail 2.1.5 : Fri Mar 26 2004 - 18:29:52 EST