Re: Control picture glyphs

From: Mark Davis (mark.davis@icu-project.org)
Date: Tue Aug 28 2007 - 20:13:58 CDT

  • Next message: Asmus Freytag: "Re: Control picture glyphs"

    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