From: Kenneth Whistler (kenw@sybase.com)
Date: Fri Oct 12 2007 - 14:21:27 CDT
> >The VS is a *request* for a specific glyph variant, out of the many that
> >might be appropriate for a character. If that specific glyph variant is not
> >available, it is perfectly correct and desired to see another appropriate
> >variant instead. In that respect, it is like a joiner between characters
> >that can't join. You don't want to see a box.
>
> I know what I want to see.
>
> Now, if I understand your paragraph above correctly,
Apparently not.
> if a user
> enters (base) + (VS2) and the system displays (base) + (VS3),
> that's perfectly correct? *That* doesn't sound right, either.
If a document has <base, VS2>, and if <base, VS2> is a defined
variation sequence, and if the document is displayed using
a font (or more generally, by a specific combination of
rendering system and font resources) that has "support for"
(i.e., can display) the *particular* glyph specified for the
defined variation sequence by the standard, then the
expected behavior is:
Display that particular glyph for <base, VS2>
If a document has <base, VS2>, and if <base, VS2> is a defined
variation sequence, and if the document is displayed using
a font that does *not* have "support for" (i.e., can*not*
display) the *particular* glyph specified for the defined
variation sequence by the standard, then the expected
behavior is:
Display *a* glyph for <base> (whichever one is available
in the font, with no particular preference specified
other than that implicit in the choice of fonts), and
display *nothing* for <VS2>.
That is what the standard says about these variation
selectors, and it was the express intent of the UTC in
encoding them in the first place.
The standard does not *prevent* font developers from putting
visible display glyphs for variation selectors in their
fonts, any more than it prevents them from putting
visible display glyphs for CR or SPACE or ZWJ.
The standard does not *prevent* applications from having
Show Hidden modes, nor does it prevent applications
from specifying UI's that display unsupported variation
sequences as pink, blinking, or with numbered VS boxes,
if they want. However, doing so is building explicit
invisible-revelatory behavior on top of the basic display
requirements of the standard.
But heading down the path of doing all that fancy work to
visibly indicate the presence of invisible things "out of
place" needs to be balanced with the countervailing
need for displays not to provide too much hidden information
*WHEN IT IS NOT DESIRED*. As an end user, I might view
a Japanese web page that had been all meticulously
marked up with variation selectors to pick out specific
glyphs from the Adobe set -- but I've got some generic
font that doesn't have any support for all those
specific glyphs. Why should I then be treated to the
spectacle of a page full of VS glyph boxes that effectively
make the page illegible to me?
The standard spells out the basic legibility requirements
for character display -- that is part of what it means
to be a plain text character encoding standard, by the
way. Typographers can then go to town, doing whatever
fancy business they want to to support scripts well
and to make text display beautifully. What I expect,
however, is that when they *don't* support something
in particular, that they don't blow chunks all over the
page for certain classes of characters that are
intended to be invisible on display. That is, of
course, unless I've specifically chosen a BlowChunksOn
parameter somewhere indicating that I want to see the chunks.
--Ken
This archive was generated by hypermail 2.1.5 : Fri Oct 12 2007 - 14:23:58 CDT