From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Fri Oct 12 2007 - 17:35:43 CDT
James Kass wrote:
> Mark Davis wrote,
> >Your chart example means absolutely zilch.
>
> Chart example? What chart example? I suppose you mean the
> character map application example in which "zilch" is that
> which is gained.
The chart examples (including the charts in the Unicode standard) are not
plain text, simply because of their layout required to make them legible.
Don't assume that what the chart displays being meaningful in plaintext.
What is displayed in that case is not representative of the glyphs that will
be used in actual texts, just focusing what is the intended meaning so that
each cell can be distinguished.
Even if an application needs some font support to exhibit such VS boxes, it
is not required for fonts normally used to render plain text. Fonts and text
renderers are first built to display plain text correctly, you can do
whatever you want to display other things such as specific VS boxes for
building font charts, failing to display VS sequences as intended for plain
text will miss the point.
So BEFORE building some support for custom boxes (which is an optional
possibility) don't forget to support FIRST the standard behaviour which
should be the default behaviour of your rendering system. To display custom
glyphs make them available only in specific modes when they are specified by
the application needing it.
Notably, VS characters have NO standard behaviour in plaintext when they
don't follow one of the characters for which there's a defined sequence
defined in the standard. So when VS characters are appearing isolately, they
are creating DEFECTIVE sequences: that the place where your renderer could
display a specific visible glyph, and that will allow you to build charts,
and even to allow atext editor to work in "visible controls" mode (but such
editor will use a "feature" in fonts or in renderer to disable explicitly
the standard behaviour.
Soyes, I agree with Kenneth and others when they want invisible VS because
this is the way they were created since the beginning. Any attempt to change
this would change the VS characters into symbols (that may be part of some
ligatures), and would defeat the standard. VS characters are NOT spacing
symbols, they are even not combining characters.
One of the best way a font can view VS characters is as zero-width spaces
that may offer some ligatures for those VS sequences that are defined in the
standard. For every othercase, they remain invisible (that's why their
code-to-glyph binding in fonts should be to a zero width invisible glyph by
default, and a specific feature, disabled by default, should encode all
other bindings to visible glyphs; the standard only permits binding by
default some sequences of a character followed by a VS, every other
sequences should be disabled by default).
This archive was generated by hypermail 2.1.5 : Fri Oct 12 2007 - 17:38:39 CDT