From: Asmus Freytag (firstname.lastname@example.org)
Date: Tue Aug 28 2007 - 20:57:33 CDT
On 8/28/2007 5:06 PM, James Kass 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.
No, it's not. Since the application can't rely on the glyph at U+2420 to
be "perfectly good", even if it is present. There's no way the
application writer can rely on the font in that situation, short of
there being an additional agreement with *all* font vendors what a
"perfectly good" glyph is. Many applications have an interest in being
able to show SPACE w/o change of linebreak. So the glyph at U+2420 would
need to be equally compressible/expandable for starters.
>> 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.
Isn't that what UTS#37 is all about?
> Any user getting an undesired display is free to choose a font
> which matches the user's expectations.
No, the font may be acceptable in the non, show-hidden mode. Users
expect to be able to toggle that mode w/o font change.
We disagree about what is desirable behavior on fundamental level, I
believe, so it's not useful for me to comment on the remainder of your
This archive was generated by hypermail 2.1.5 : Tue Aug 28 2007 - 20:59:36 CDT