From: James Kass (thunder-bird@earthlink.net)
Date: Tue Aug 28 2007 - 19:06:42 CDT
Mark Davis wrote,
> No. This is the core of the problem. If an application wants to Show Hidden,
> and reveal VS characters, it can have a special rendering mode to do so,
> where it replaces DI and whitespace by pictures. And it will have to manage
> the pictures because it can't depend on any fonts to do it.
Any font which supports control picture characters should be
able to do it; that's what those control picture characters are for.
If an application "shows hidden" and substitutes its own control
picture for U+0020 when the font already has a perfectly good
control picture mapped at U+2420, then the application is broken,
far as I'm concerned.
> The font should always have invisible CJKVS characters if it has CJK
> characters: otherwise it screws up normal rendering. The NORMAL rendering of
> a CJK character plus CJKVSn, if the pair is not supported by the font, is
> the CJK character alone. Period. No gummed up box after it.
There are no valid sequences involving CJK characters plus VS characters.
Any user getting an undesired display is free to choose a font
which matches the user's expectations.
Just as any user getting unexpected results, such as pictures
being swapped for a font's control pictures by an application,
is free to discard that application and get something which
matches *that* user's expectations.
Because of the size of CJK fonts, it's unrealistic to expect two
versions of each large font; one for editing/input and the other
for display.
VS control pictures are useful during editing/input and are already
supported by plain-text applications which have no "show hidden"
mode, like Notepad, when the font includes its own control pictures
and the author/editor inserts a space between the base character
and the combining mark.
If somebody sends me data which includes a CJK base character plus
a VS character, and that VS character is not officially registered in
an official sequence, I expect instant visibility of the fact that there's
a problem with the data. Other users may have different expectations,
that's OK. Likewise, if somebody sends a CJK base character plus a
valid VS character (for a valid sequence), and a control picture displays;
it is an immediate visual indication of a shortcoming in the font.
Once again, the NORMAL display doesn't get screwed with. The control
picture in a font which supports VS sequences would never be part of
the normal display, as long as the data includes only valid sequences.
Can you show me any problem with my fonts where my VS control
pictures screw-up a normal display? (I'm only talking about valid
sequences here, but not limited to CJK.)
CJK fonts are especially interesting, as they are often fixed-width
fonts. Unless I'm mistaken, fixed-width fonts can't include arbitrary
zero-width glyphs interspersed with positive advance width glyphs.
So, with any valid sequence of CJK base character plus VS character,
the user will either see:
1) The single variant glyph. (If the font supports VS characters and
has a look-up and glyph for that sequence.)
2) The original base glyph plus a control picture for the VS character.
(If the font includes control pictures for VS characters but does not
have glyph substitution enabled for that sequence.)
3) The original base glyph plus the font's missing glyph. (If the font
does not support VS characters at all.)
4) The original base glyph plus a full-width whitespace. (If the font
maps VS characters to no-contour glyphs.)
Of the above four, number one is optimal. In my opinion, number two
is better than either three or four.
If Adobe's proposal for a very large number of what are essentially
font-variant CJK glyphs is approved, then, depending on the font
selected for display, there may well be VS control pictures showing
up in the display. Unless an application has a user-controlled option
to strip VS characters from the display, the user is free to choose
another font if the user doesn't like those VS control pictures.
Besides, normal CJK display could not be affected at all as long
as normal CJK *text* doesn't use VS characters. In those rare
cases where a need to preserve glyph variant distinctions in
plain text for two variants which are unifiable under the rules
of Annex S *has been demonstrated*, then any CJK font supporting
VS characters should include appropriate glyph substitution data
for that sequence. If there is no need to distinguish a pair of
variants in plain text, then VS characters should not be used in
the first place. (And such sequences should not be approved, either.)
Best regards,
James Kass
with apologies for length.
This archive was generated by hypermail 2.1.5 : Tue Aug 28 2007 - 19:09:59 CDT