At 12:33 AM 1/27/02 -0800, Mark Davis \(jtcsv\) wrote:
>>I find it fairly pointless to say that a font "supports" the variation
>>selection sequence <U+03B8, U+FE00> if it does not provide a visual
>>distinction from <U+03B8>; and such a distinction should be based on the
>>entry description. Thus, of the following four fonts, only number 4
>>correctly supports the sequence <U+03B8, U+FE00>. (Of course, any real
>>font would have designs for the two glyphs that were a bit more harmonious!)
I couldn't view your examples, but guessing at what they might have been,
I'll risk an answer.
The problem is that some of the distinctions for which variant selectors
are used, are *needed only by a minority of users*. Some of the math
variants (not PHI, or THETA, but the ones in StandardizedVariants) may only
be needed by *some* math authors.
Any requirement that by supporting VS1, one must restrict the glyph range
of the unmarked symbol forces either
a) the tail to wag the dog
or
b) many dogs to do without tail
Case a is where fonts assume the most restrictive glyph choice for the
unmarked symbol, so that they can be used by all users. This is bad since
the restricted glyph range for the unmarked symbol may be a somewhat
unnatural one. Given the expense of creating a math font, it may not make
sense to do one that is not usable by all math authors.
Case b is where fonts assert their choice of unmarked glyph and (because of
the required contrast) choose not to support the VS1 form, since that's the
form they want to use as the unmarked default. Given the expense of
creating a math font, the sub-set of math authors may not have the
werewithal to source a font for their needs, since most of the market can
be covered by something that is 'good enough'.
By explicitly defining a way to restrict the glyph range (via coding
another character, or another VS sequence) it becomes easier to support
groups with related needs, but different requirements in the face of variants.
A./
This archive was generated by hypermail 2.1.2 : Sun Jan 27 2002 - 04:03:16 EST