From: Mark Davis (mark.davis@icu-project.org)
Date: Tue Aug 28 2007 - 20:13:58 CDT
To the extent that I can follow you, I don't think you follow me at all. So
I suspect any further discussion is pointless.
Mark
On 8/28/07, James Kass <thunder-bird@earthlink.net> wrote:
>
>
> 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.
>
>
>
>
-- Mark
This archive was generated by hypermail 2.1.5 : Tue Aug 28 2007 - 20:18:00 CDT