L2/02-081
February 11, 2002
Comments on proposed “invisible” property
----- Original Message -----
From: "Kenneth Whistler" <kenw@sybase.com>
To: <mark@macchiato.com>
Cc: <unicore@unicode.org>; <kenw@sybase.com>
Sent: Friday, February 08, 2002 15:16
Subject: Invisibility (was: Re: Agenda items from Apple)
Mark said:
> I want to clarify a bit.
> By "invisible" one could mean a lot of different things. For example:
I agree, but...
> a) has (normally) no visible glyph, and contributes no advance width (DICP)
> b) has (normally) no visible glyph (DICP + Whitespace).
this is not quite complete.
> There are edge cases such as soft-hyphens, which normally are (a), but
> are visible at the end of a line.
>
> John suggests another: is zero width. This would be (DICP + Nonspacing
> Mark + Enclosing Mark). I wouldn't call this invisible, although it
> may be a useful set depending on the application Deborah has in mind.
Default_Ignorable_Code_Point
This includes all the format controls, the ISO controls (except
0009..000D, 0085), the variation selectors, ranges of unassigned
code points we have designated for format controls, and surrogate
code points.
All of these should have no visible glyph, and should not contribute
to advance width.
200B ZERO WIDTH SPACE
Neither Default_Ignorable_Code_Point nor White_Space
This has no visible glyph, and does not contribute to advance width.
Hangul fillers
115F HANGUL CHOSEONG FILLER
1160 HANGUL JUNGSEONG FILLER
3164 HANGUL FILLER
FFA0 HALFWIDTH HANGUL FILLER
These have no visible glyphs, and do not contribute to advance width.
White space layout controls (White_Space - Zs)
0009..000D, 0085, 2028, 2029
These have no visible glyph, but affect layout, may contribute to
advance width, break lines, and so on.
Spaces (White_Space - Cc - Zl - Zp)
These have no visible glyph, but have positive advance widths.
00AD SOFT HYPHEN
This has no visible glyph, except at line end, where it has a visible
glyph and has a positive advance width.
Taking the Hangul filler characters into account, I'd say that
Deborah has a reasonable case for "Invisible" not being an easily
derived property from what is already defined.
--Ken
[Please see L2/02-080 for proposal by Deborah and more comments by Mark Davis]